Ah, so Code is the same as Vim if… I go out of my way to either disable things on one or install things on the other.

Or… Or… Code is an IDE (that you can strip down) and Vim is a text editor (that you can strip up).

We don’t stop calling a computer one just because it can still boot without most of its modules. The default presentation matters.

deleted by creator

So… Network issue. I’m not falling for those ever again.

deleted by creator

Having no comments doesn’t force code to be self-documenting. I understand the cult of code extremist, but No-Commenters are just WEAK and PATHETIC wannabes trying to immitate the true, functional extremists, such as the 16-Space-Tabbers

deleted by creator

deleted by creator

This counts as discussion of self-hosting.

This post got the issue exactly. To use either React or Vue, the first thing you (should) learn from them is about the render mechanisms, which are introduced under the concept of component lifecycles, which only exist because both render things using a Virtual DOM. This is NOT hard, not even close, but it’s also non-trivial and it’s not immediately learnable with just hands-on code experience. It’s also boring to go through it first, so “first thing” has a ton of quotation marks most of the ways you learn it. It’s the kind of stuff that explains why the code is the way it is, and it makes sense of the thing, but can be new and weird.

I think a better way to relate to the issue is to ask people to recall how they learned git, specially those who tried to learn by doing. I’ve known SVN before I learned git, so when I had to sit down and actually understand it, some of the concepts were transferrable. But I’ve seen many, many people try to learn it and completely fumble to understand what the hell they were doing until they were presented with some visual representation such as https://user-images.githubusercontent.com/1256329/117236177-33599100-adf6-11eb-967c-5ef7898b55dc.png A diagram such as that is basically a shorthand to learning the mechanics of git, a sense-maker.

The problem with some of the comments here is that even “properly” written React CAN hit a performance bump, and optimization is a rather rare skill no matter the programming context (kinda due to little time given to it, so everyone is out of practice).

But I don’t know which ones are the ones talking about that, and which ones are just people annoyed at anything Node in general.

If there’s a parent component that has some data that it expects to always receive from its children, then that data should be in the parent’s state and the children should receive it and maybe some relevant methods as props. Even if it’s an unknown number of children. Don’t muck with useContext for basic inheritance stuff, you’ll mess with the render cycle for no good reason.

Now, if we’re talking about a very distant “top” component, that’s fine, it’s what it was made for. Although many people end up using stores if it’s some data with broad impact (like user data)

It’s not steadily. They only have two data points. All lines are straight. You can pretty much ignore what happens between the two years at the start and end, and you can also ignore any apparent trend because, hell, the last year might be an outlier, or maybe bars has been higher and is now trending down.