> See most of the ecosystem around React, for reference.
I've never used React myself, but what I've heard about it makes me question my own sanity. So are you going to tell me that instead of just updating the DOM tree directly I'm going to apply the changes to my data, then pass the entire model to the framework, which would then diff it with the previous version to get the changes back out, it would then call my functions that return components, and it would then diff the virtual DOM to find out what changed, and only then would it update the actual page? Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
Oh and now Google and Apple are insisting that this is the way to do UIs in native apps as well, with Compose and SwiftUI respectively.
The way the front end developer community seems to largely encourage learning top-down isn't helping either. I'll forever remember that one guy we made a small project with. He learned React but had no clue what "send a request" and "pass a parameter" means, and I had to explain him how to use XHR.
The DOM is the slowest part of the browser. It's not Javascript, it's the DOM. React is an attempt to manage the slowness of the DOM. One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page.
With thousands of DOM elements on a page, the DOM becomes a bottleneck. This isn't the fault of front-end developers, and it's not really the fault of browser developers. HTML/CSS/JS is a very powerful system, but it's also complex and can cost a lot of compute. When you understand this, then the reasons for React and other front-end frameworks become easier to accept.
> One seemingly small change to a page (like setting innerText) can have many ripple effects with reflow on mamy parts of a page.
I haven't looked into how browsers actually do it, but my mental model for it is that if something changes, this merely sets a flag on that element or its parent that its layout is not valid any more. Then, on next vsync, all the elements that have this flag set have their layout recalculated, potentially going up the tree as necessary. The only exception is if your script tries to get any layout-related property, e.g. offsetWidth. Then, as if as part of the getter of such a property, the layout recalculation will run immediately.
That is to say, if you need to make a lot of changes to the DOM, you should make them within one JS invocation so only one layout pass happens sometime after you're done.
OP here. The steel-man argument for React is not that it is faster at rendering. It cannot be, because it ultimately relies on the same DOM that everyone else does to do the job, and it has to set up a massive JS data structure to do what it does, which uses a lot of memory and has big GC costs. Arguments that assert that the React virtual DOM are faster than the native/shadow DOM are simply wrong [1]. Even the React team admits this [2] (though back in the day, they made a number of puffed-up claims about speed that never made sense).
The principle argument in favor of React today are developer ergonomics. People don't have to manually alter individual elements anymore -- they just describe state, and React takes care of the UI change set. On top of that, you have components, etc., that are debatably more pleasant to work with, and at the least create an ecosystem advantage for users of the framework. One can certainly see the argument for something like facebook, where there are probably dozens of different things changing independently at any given time.
But that said, one really has to question whether React makes sense anymore, given LLMs. Back when the alternative was that someone had to bespoke code every UI component, it might have been worth taking the hit of having to adopt the entire React ecosystem. But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.
[1] Though sadly, many front-end devs don't know this.
Well, I'm an old-school guy. I'm all for developer ergonomics, as long as they don't affect the runtime. I use PostCSS and TypeScript in my own projects precisely for this reason, because they both make things more convenient for me yet leave no trace in the finished product that the users see.
> But now that LLMs are writing the code
Hopefully that's a temporary state of affairs and everyone will eventually go back to writing code by hand. I've never even considered using an LLM to get my job done, the whole idea is as alien to me as are these types of UI frameworks. To me, the best language to describe what you want from a computer isn't English, it's a programming language.
>But now that LLMs are writing the code, there's really no argument for developer ergonomics, and suddenly, things like "rewriting URL handling in JS" are pure liabilities.
The popular coding AIs go down all the time. Last week all of them were down at the same time. If there's a bug causing losses of thousands or millions of dollars per minute, do we really want to let the LLM write incomprehensible code?
You may not need react. If you want to make the smallest possible change to the dom to reduce latency, then make the smallest possible change to the dom. Choose solidjs. (Not a sponsored post).
> Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
It's so that you have the page reflecting your data at all times.
The browsers should have been written this way, instead of having byzantine update functions with all forms and a pair of *Text to rule them all. But creating it in Javascript is a really bad idea.
I've never used React myself, but what I've heard about it makes me question my own sanity. So are you going to tell me that instead of just updating the DOM tree directly I'm going to apply the changes to my data, then pass the entire model to the framework, which would then diff it with the previous version to get the changes back out, it would then call my functions that return components, and it would then diff the virtual DOM to find out what changed, and only then would it update the actual page? Why the fuck would anyone ever want that? What's so hard about simply changing the innerText or inserting elements or whatever?
Oh and now Google and Apple are insisting that this is the way to do UIs in native apps as well, with Compose and SwiftUI respectively.
The way the front end developer community seems to largely encourage learning top-down isn't helping either. I'll forever remember that one guy we made a small project with. He learned React but had no clue what "send a request" and "pass a parameter" means, and I had to explain him how to use XHR.