>The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning.
Svelte's main point is that the performance claims of frameworks like React are just bullshit marketing-speak. That I agree with it. The value of JS UI frameworks in general, isn't in performance, but rather to provide a "declarative, state-driven UI development" because raw JS/HTML/CSS development is terrible and makes it easy to make terrible architectural decisions and write unmaintainable spaghetti code. In this way, whether you go with Vue or React or Angular, it makes no effin difference to performance.
But yes, there is overhead in managing the virtual DOM and yes, you can get yourself in trouble if you don't structure your application in line with how the framework expects you too.
>React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day.
React made a stronger claim. It wasn't just about React vs some Templating framework. React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim.
>Their alternative is to add more complex compiler steps, which I’m sure could work great. However it’s awfully dogmatic to suggest that this is better simply because it eliminates one kind of not-strictly-necessary overhead.
And it's not a bad argument. The DOM is an abstraction and the underlying implementation is highly optimized. DOM mutations are not the expensive thing, it's the final render, and that part has had an enormous amount of work done to make it smart and fast. By the way, Flash had a great built-in rendering model. The Flash display list hierarchy was very well architected and it wouldn't re-render the entire page if only a part of it changed.
>But this isn’t how you sell a framework to programmers, in my opinion.
Claiming your framework is faster than the other guys IS how you sell a framework to programmers. That's how React and Vue were/are being sold.
> React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim.
My impression is that it's the kind of claim that's actually true in general, despite being false in all the particulars.
Like, every step of the way, yes, virtual DOM adds extra steps to the process, and they have a cost. But, in the big picture, if you're manually manipulating the DOM then you're liable to just swap out entire chunks of the tree rather than making surgical manipulations. Because manually managing all those surgical manipulations would quickly become a fiddly, unmaintainable mess. But, if you do it that way, you're asking the browser to do a lot more re-rendering, and that would be costly.
I worry that this conversation falls into the same trap that most performance discussions fall into, where we quickly become focused on what things would be like if people had unlimited time to chase the best-case scenario, rather than what things are like for the 99% of us who are just trying to get something that works acceptably by the next deadline.
no its not wrong to criticize the culture in web development of salivating over every new framework. And rebuilding company code in hyped up framework X without pausing to understand the problem you're trying to solve and why the current glob of code is so damn buggy. I see experienced web devs, if not fall for this mistake themselves, happily prop it up to management every damn day across many companies. I've read too much damn code where a dev wants to do something straightforward but either because of ignorance or some cultural pressure reaches for a complicated library way to do it, finds that said library doesn't solve the problem well, and then misuses that library or exploits one of its escape hatches in the solving of the problem just to say that their code used the new shiny library. As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.
This feels like a tangential point about JS dev culture or engineering skill level rather than a point about the technical merits of React vs Svelte or whatever.
> As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.
I'm not sure I agree with this. Basically, it requires a much higher degree of experience and skill to write DOM manip well. There aren't really great resources that I've seen, because it's all very context dependent and something you learn over time. We used to send people straight into the DOM when they wanted to make a simple app, and the result was a lot of huge unmaintainable messes, security nightmares, and poor performance.
The value of React is that you can just follow the docs on reactjs.org that will give you a mediocre default. If your needs go beyond that, you can get a more skilled person to come in and improve the critical parts. The world's need for web apps outstrips the supply of highly-skilled, highly-experienced developers, so it makes sense to have libraries that lower the bar.
For my part, I actually wonder if there's also a certain gatekeeping element that also fuels the popularity of frameworks like React?
Turning things into JavaScript-heavy single-page applications has, I would assume, an effect of shutting out people who are good at HTML+CSS, but less so at JavaScript. I don't know how likely a profile that is nowadays because I'm buried deep deep deep in backend-type work, but it used to be fairly common to have front-end people like that who were stronger on design than programming.
Is this a form of unwitting rent-seeking behavior? Has the profession created an artificial supply-and-demand problem by convincing the managers of the world that they need expensive single-page applications built by Software Engineers™, when a (less expensive, I'm assuming) Wordpress site developed by a web designer would have sufficed?
For context on where I'm coming from: I've mostly been a back-end developer for a couple decades. I've known HTML and CSS since the '90s, of course, I'm just now starting to learn Web development in earnest, mostly as a hobby. I'm finding React's learning curve to be just incredibly steep. For the stuff I've been doing, I've had a much easier time getting acceptable (to me) results out of a more oldschool-flavored tech stack, with server-side templating and a moderate sprinkle of vanilla JS. No, it's not fancy, but I'm not looking to flex; I'm just looking to whack together a website that looks nice.
I'm not sure I'd go down that road. I totally agree that for websites, Wordpress, SquareSpace, Gatsby, Hugo, and a host of other static sites work just fine. Where I find it hard to make the stretch is, these are not the type of sites your average JavaScript app developer wants to work on. They'd probably be just fine NOT touching that. I know the past few places I've worked, I've never touched the slick "brochure/marketing sites". I think that type of thing is better left to someone who has really honed their HTML/CSS skills. I don't see a whole lot of reason why anyone would want to turn that type of site into an SPA.
I'm not saying developers don't have an attitude problem. We often do. I just think you might be assuming malice where there might be none.
> As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.
As a bootcamper who came from a philosophy background to frontend, you will be surprised how many 15 year "veterans" in web dev can't write coherent code without a framework, couldn't tell you how designing data one way or another impacts their code design, and when you confront them on this, bring it to their attention, they find any which way to dismiss the problem with "do we really need that"/"why do we need that" as if their's virtue in pretending to be the Product team in the face of shoddy engineering. Enterprise agile largely enable this fairly low floor. Engineers can handwaive anything in the name of the holy right now.
> but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.
I agree with you in general, but I can’t agree with this statement. Web development needs fewer gatekeepers.
Adding and removing nodes from a tree doesn't require a phd.
I don't particularly like React and I never used it, but I can see how it improves performance over naive use of browser APIs, because you can easily do things that are really bad for performance and require needless layout calculations when updating DOM manually, while tools like React will sort the updates in more optimal way without too much thinking.
This is neither here nor there. Some people write awful React code too.
> having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer
I mean, knowing how to do it is good and all, but knowing how to do it well is a rare skill. There's a ton of random performance gotchas to be aware of (like, reading a property in the middle of a bunch of writes causing double repaints) and frameworks do consistently apply optimizations that you as a regular dev would probably not ever think of (sorting optimizations being some of the least trivial ones).
> But, in the big picture, if you're manually manipulating the DOM then you're liable to just swap out entire chunks of the tree rather than making surgical manipulations
"Swapping out entire chunks of the tree" is in fact a very sensible choice given that the browser rendering pipeline is highly optimized and can run in parallel, whereas any v-diffing step has to be done in single-threaded, non-native JS. You also save on the overhead of storing the vDOM itself, which will be quite significant.
I wrote a react application and VDOM overhead was so high that I had to cut down what parts of the UI were rendered to just what was on-screen at any given time. Performance was just barely okay on a desktop and completely unusable on an Android phone.
Not using react made everything work amazingly fine. Granted this was an application with fairly low amounts of DOM manipulation (popup things when the user clicks on stuff, some lists that elements can be added/removed to/from), but those sorts of things seem fairly typical.
I wanted to use React because the code was so much cleaner and concise, but it was just way too slow.
>I wanted to use React because the code was so much cleaner and concise, but it was just way too slow.
I've been hard on React in other places in this thread because I agree with the premise of the article that VDOM is not free and that the value of React is not in performance over raw DOM manipulations, but rather in code organization.
Having said that, React isn't bad either. That it was too slow for you, I suspect, comes down how you wrote and structured your application and not necessarily React. It's been a few years since I did any meaningful React development, but back when I did, React code was simple enough that it wasn't hard to understand and trace trough, or profile. I guess I'm curious, what the bottleneck was.
> React code was simple enough that it wasn't hard to understand and trace trough, or profile
Interestingly enough, this was the opposite of my experience. For my next project I used Mithril because it was far easier for me to debug, trace, and profile through.
> That it was too slow for you, I suspect, comes down how you wrote and structured your application and not necessarily React.
I had on the order of 100 inputs with two-way binding. My code was structured along the lines of the existing react tutorial of the day (maybe 10ish years ago?). Per suggestions of members of the react community, I restructured it to use ImmutableJS to allow for faster VDOM diffing, which did cause a noticeable speedup, but was still dog slow.
It's hard to say for certain, but it sounds as if you may have been doing things that caused lots unnecessary re-renders. React has some pitfalls for beginners, but I've built highly complex frequently updating webapps without the degree of slowness you're speaking of.
Vivaldi browser is made using React. Frantic pointless UI DOM manipulations (deleting nodes just to recreate them back etc) are one of the main sources of performance degradation. https://news.ycombinator.com/item?id=27449736
I seem to remember that when React was first introduced, DOM mutations _were_ very expensive. I was under the impression that a lot of optimization was done in reaction to, err, React and similar frameworks?
One DOM mutation is faster than one VDOM-to-DOM flow, though, of course, since the latter's doing the same thing plus more. The latter also uses a lot more memory, and keeps it around indefinitely unless you want to risk performance-killing deallocs and allocs later (I'm making some assumptions there—I'd expect a typical VDOM implementation's memory is rarely released, since re-building that data structure would be high cost if you need it again and largely defeat the purpose).
VDOM's also pure JS in the typical implementation, which is going to tend to be slower and (much) less memory efficient than getting the fuck out of JS and into the browser's C++ or Rust or whatever, ASAP (React's, for instance, is a big ol' tree of JS objects, AFAIK).
If you're often modifying or inserting 10,000 elements per update and can't be bothered to somehow batch those yourself, virtual DOM is probably a performance win. If the count is typically more like 1-10, it's probably overhead. In between, shit, I dunno, benchmark it.
There's some nuance. DOM mutations are still expensive if you interpolate reading and writing operations. The declarative paradigm allows frameworks to batch same-type operations to prevent double repaints. This is the upsell of virtual DOM vs jQuery, but it's not a benefit that is exclusive to virtual DOM.
Virtual DOM comes with a different set of trade-offs in terms of needles and haystacks. If you have lots of mutations relative to the size of the DOM, then virtual DOM overhead per mutation is relatively low. But if you're only updating a single element in a very large tree, then you are incurring a lot of overhead per mutation.
Another modern confounding factor to be aware of is that some browsers (notably Chrome) have made it so that mutations through the DOM API no longer cause a repaint to block the main thread (which is how every UI system ever should work, really). What this means is that any performance benchmark that uses JS APIs to measure UI responsiveness is going to be problematic (either by not measuring repaints correctly, or by adding a ton of confounding factors by shoving the macrotime queue of setTimeout/friends into the measurement)
Also, qualitatively, there's different levels of overhead. A repaint takes in the order of hundreds of milliseconds (i.e. it can be noticeably expensive). DOM API calls are also "expensive", but only in the order of a millisecond or so; you do want to touching the DOM unnecessarily if possible and virtual dom helps avoid silly mistakes like re-querying the DOM on every event like in the `$('.foo').on('mousemove', () => $('.bar'))` anti-pattern. Virtual DOM is "overhead" in the sense that allocating memory for a virtual DOM node is "expensive" (compared to not allocating any memory). But we're in microsecond-per-instance territory at this point. You need large haystacks with very small needles at high frequencies in a slow device to experience human-noticeable performance degradation from virtual DOM object allocation overhead.
>I seem to remember that when React was first introduced, DOM mutations _were_ very expensive.
Not really. Rendering was always a heavily optimized area. The DOM, by the way, is also an in-memory data-structure, and can also be clever on how it batches draw commands to the hardware (GPU or otherwise). I was always skeptical of the performance benefits of frameworks like React for that reason.
The big benefit of UI frameworks (React or Angular) is that it organizes your code into a defined, maintainable pattern. Traditionally JavaScript has been a mess of a programming language so with raw JS/HTML development it was easy to shoot yourself in the face and do the wrong thing.
>I was under the impression that a lot of optimization was done in reaction to, err, React and similar frameworks?
That's not true. There is an enormous amount of investment being poured into the entire HTML/JS/CSS stack.
Svelte's main point is that the performance claims of frameworks like React are just bullshit marketing-speak. That I agree with it. The value of JS UI frameworks in general, isn't in performance, but rather to provide a "declarative, state-driven UI development" because raw JS/HTML/CSS development is terrible and makes it easy to make terrible architectural decisions and write unmaintainable spaghetti code. In this way, whether you go with Vue or React or Angular, it makes no effin difference to performance.
But yes, there is overhead in managing the virtual DOM and yes, you can get yourself in trouble if you don't structure your application in line with how the framework expects you too.
>React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day.
React made a stronger claim. It wasn't just about React vs some Templating framework. React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim.
>Their alternative is to add more complex compiler steps, which I’m sure could work great. However it’s awfully dogmatic to suggest that this is better simply because it eliminates one kind of not-strictly-necessary overhead.
And it's not a bad argument. The DOM is an abstraction and the underlying implementation is highly optimized. DOM mutations are not the expensive thing, it's the final render, and that part has had an enormous amount of work done to make it smart and fast. By the way, Flash had a great built-in rendering model. The Flash display list hierarchy was very well architected and it wouldn't re-render the entire page if only a part of it changed.
>But this isn’t how you sell a framework to programmers, in my opinion.
Claiming your framework is faster than the other guys IS how you sell a framework to programmers. That's how React and Vue were/are being sold.