Virtual DOM is pure overhead (2018)

The part that I think the article misses is that VDOM is just an implementation detail of React. No one actually really cares about it, and its not the reason why people use React.

React gave us not a better programming model, it gave us an other programming model. In some cases template based enignes are better than JSX, but that discussion has nothing todo with Svelte or React.

React boomed cause at that time everybody has enough of bloated frameworks and with JSX you had a wonderfull thing to tinker code... thats what developers like, tinker all the day complex bloated code. Why made it easy, when you can have it complex? ;-) And it came from well known Facebook, thats it, nothing more.

I rememnber the day when everybody was shouting, Redux is the best thing every ;) And now "hooks" Really?

React, imo, is about the programming experience. "Thinking in React" is a lot more than just VDOM, and the benefit of "thinking in react" is about the developer experience not the pure benchmarkable output.

Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale.

The reason I think React works so well and is so popular atm is because it works just as well at a small scale as it does on a team with 5-6 active contributors (in my experience, at least).

That isn't to say that Svelte can't deliver the same wonderful experience at scale, I've just yet to see a truly shining example of it.

I may also be in the minority, but performance of front end frameworks is near the bottom of my evaluation checklist.

I've used svelte for some one off personal projects, just to get a feel. And it's fine but nothing about has convinced me to lead a project/team towards picking that over React, Vue, or even some SSR framework.

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.

I feel that way about a lot of articles like this. I want to know what you do well, I don't want to hear someone complain about something else.

Sell me on what you do well and what that means for me.

I work in React a lot and I don't feel like I run into this “pure overhead” type concept in the way they describe it and thus this article makes me:

1. Wonder what they're doing in React that they feel this way.

2. The article quickly becomes much less relevant to whatever it is I'm thinking about.

I think you're interpreting their messaging as "Svelte's compiled DOM is faster than virtual DOMs ergo Svelte is appropriate for every application" whereas the implication is certainly "Svlete's compiled DOM is faster than virtual DOMs ergo Svelte may be a good choice for applications that are constrained by virtual DOM". I don't think it's a reasoning failure, but rather a misunderstanding (an inadvertent straw man on your part).

> Svelte probably hasn’t taken over because the real world isn’t synthetic benchmarks and most apps have more significant concerns than how many times a component can update per second - and even then, in my experience React is more than capable of doing a decent job here

I think this makes a fair amount of sense. Often an incumbent needs to be quite a lot better in order to justify the learning curve, and I'm not sure that Svelte is. That said, I've been part of a lot of Python projects because Python's problems don't often manifest for new projects, but rather at scale (real workloads suffer from Python's poor performance, development velocity decreases at scale due to type annotations, package managers crawl as the dependency tree grows beyond the "toy" category, etc). I wonder if perhaps there's a similar effect in which React is "good enough" for new projects but not enough for

> The irony is that Svelte compiles code that will then run on a JIT under a JavaScript engine. That’s strictly overhead.

I don't understand this claim. In order for it to be "strictly overhead" we have to assume that Svelte's compilation step has no benefit i.e., the output code doesn't reduce the JIT's workload but even more than that, the output code has no advantages (i.e., performance advantages) over React?

> I know this article is from 2018, but it never landed well for me, and Svelte’s virtually unchanged irrelevance should be some kind of cautionary tale. I don’t think there is anything wrong with Svelte. But this isn’t how you sell a framework to programmers, in my opinion.

The way you sell a framework to programmers is largely by the backing of huge tech companies who use it in large, noteworthy projects. That's presumably not an option available to Svelte developers?

Because that is the topic of the article.

It never even says "The virtual DOM overhead is a problem". It actually says exactly the opposite, it's often fast enough and not a problem. It didn't call Virtual DOM a meme, it called "the virtual DOM is fast" a meme.

Performance wise, as the article says, it is pure overhead. Virtual DOM is the solution to a problem the javascript frameworks create themselves.

I've had argue against managers that no, using a virtual DOM will not magically make our pure JS app run any faster. Especially once I put in the work to make the DOM as seldom accessed as I could.

There is a fantastic reason these JS frameworks work that way. Instead of building creating and update logic, you just need creation logic and always rebuild the widget. But that's super slow, so you use a virtual DOM to make it faster. Just not as fast as it would have been if you hadn't used the framework.

The tradeoff being that your code is often significantly simpler and easier to maintain. Though that also breaks down in some parts.

a more catastrophic failure of reasoning, that is far more prevalent, is not understanding that virtual DOM is overhead on top of the regular DOM, not some magic fairy dust invented by facebook geniuses that just makes the web better (tm) because you are a dev whose first exposure to web development was via a React tutorial where you built some <popular app> clone as it held your hand every step of the way, and now you are loosed into the jungle of problems in the wild ready to crush the spirits of those old tired jquery devs. bwahahahaha.

Svelte performance is a nice bonus but it is the last reason I prefer Svelte over React. I prefer Svelte because it is truly reactive (unlike React) which makes everything easier, cleaner & more readable.

Svelte is the only framework you can grasp in 10min by just looking at a few examples. To get started, you don't even have to read a tutorial or documentation, the code is self-explanatory.

React is a complex beast and, in my opinion, all this is an overkill / overengineered environment for expressing UIs.

I find Svelte to be the only framework that "make sense". Ultimately UI is not that complex, it's a store -> derived variables -> UI where each step is a reactive function of the previous one. A framework should let you express this very concisely and take care of everything else for you.

If x = y + z then I want to write x = y + z, end of the story. Like in a Excel sheet, just write the formulas and that's it. No useStates, hooks, componentShouldUpdate(), and other wierd stuff.

Svelte is to React what Pluto is to Jupyter Notebooks, less popular because of legacy, but, in my opinion, obviously more elegant & cleaner

Modern software commonly goes through multiple transformation (compilation stages) and it's increasingly common for some of them to be AOT, and some to be JIT, and neither AOT or JIT is overhead, even in combination. They have different pros/cons and in fact together you get the best of both worlds.

This doesn't negate your main point, but I wish you didn't end with an example of "irony" that actually is incorrect.

Secondly, you're dismissive of the idea that 'the virtual DOM is fast' is a meme (in the original Dawkinian sense; I'm not talking about gifs with Impact-typefaced captions), which suggests you haven't spent a lot of time around developers on places like Twitter and Stack Overflow. This misperception _absolutely_ exists, and this article was written to correct it, not to 'sell' Svelte.

Svelte isn't intent on 'taking over'. We're quite happy providing developers with an alternative to React that enables them to write less code and not have to worry about performance. That said, I'd argue the 'irrelevant' label is somewhat unfair (https://twitter.com/swyx/status/1409529125539254277, https://2020.stateofjs.com/en-US/technologies/front-end-fram...).

And this, ladies and gentlemen, is how we ended up with web pages that lead modern mid- and even high-end personal computers grind to a halt.

Squeezing performance out of DOM manipulation is really tricky because the performance profile of pretty much everything changes frequently without rhyme or reason.

This makes me feel conflicted.

With React/Angular/Vue you're given a stable base upon which to build new components and logic, so most of the libraries end up being vaguely consistent with the underlying tech.

With JS libraries it's the wild west once again and before you know it, your components will need 3 different mechanisms of being initialized, their internals will use different approaches, before long you'll have multiple versions of jQuery in there as well and it'll make you consider the downsides of that approach.

But maybe I only have that outlook because I've witnessed many such situations of poorly integrated JS libraries and have therefore gotten used to walled gardens.

Yes! I've been a full-time React developer for about 5 years, and recently had the chance to try Svelte on a small pet project. I'd written most of the project in React and had a free weekend so I figured what the heck – let's see how it'd look in Svelte. :)

Within a day most of the functionality was in place, and the code just felt _beautiful_. I loved that it removed so much boilerplate (wrote some examples here[0]), and some of the React headaches (like using "Undo" in a controlled <textarea>) were just gone. The ergonomics (especially the built-in stores, error handling, and <svelte:head>) were lovely surprises!

I'm really bullish on it and so happy it's starting to grow.

[0]: https://mtm.dev/react-vs-svelte

So, even if it's not necessary now, there's not necessarily any escape. The problem with complex tech stacks is that, for a variety of technical and social reasons, it's much easier to add to them than it is to take away. You can't necessarily incrementally roll back any of the bits of an existing React-based site; such an effort is liable to spiral into a complete rewrite. It's relatively easy, though, to incrementally add new things in order to paper over whatever's bugging you at the moment.

The social story is similar. Coming from a position of knowing very little, the effort for me to learn the vanilla JS way of doing things is roughly similar to the effort to learn the React way of doing things. But, if I were already invested in the React ecosystem, that wouldn't be the case. I wouldn't just have to learn new tooling, I'd also have to re-learn my entire way of thinking about how to architect a webpage. Realistically, you can't, all else being equal, justify a radical re-tooling in order to achieve an incremental benefit like that.

I think that the independence of various parts of the web stack is actually a strength, not a weakness. Because you don't need the complete ecosystem — you can pick and choose which parts to use, mostly without compromise.

That's just cheating though, isn't it? And not in a good way. If you smear your DOM update over consecutive frames, you can maybe cram in 2-4x more operations in there before the user starts noticing. Past this point, a smeared update starts having design implications - things that should happen simultaneously now happen sequentially. Not to mention, application starts to feel heavy.

Svelte on the other hand is as optimized as possible - update the data, modify the corresponding DOM pieces directly. There is no realistic use case where you’d need to spread an update over multiple frames.

JavaScript is the wrong example. It didn't succeed on merit, but because it was the sole language available for the web platform for the entire history of the web until recently and even now it enjoys significant "unfair" advantages (browsers only expose DOM APIs to JavaScript, the JS standard library is baked into the browser while other languages must ship their own over the network, etc).

I’m curious- how much experience do you have with Svelte and what in particular do you find it makes more difficult or convoluted than React?

I disagree. I've found Javascript to be quite complicated.

However, I agree with your takes that:

1. It's highly accessible - yes, you can learn a single language and get away with only knowing that language for a good chunk of your career nowadays.

2. It does involve fairly immediate feedback (somewhat akin to Python in that regard), because it's interpreted. Given that it's also visual, and a strong majority of people equate the internet to solely what you see in a browser, it's a pretty gratifying experience (even if, later in your career, you avoid it like the plague).

this is a no-brainer, right? The tricky part is how you identify redundant calls and eliminate them, knowing that some have more cost than others.

That will still only result in a performant, smooth 60fps application if you can do all the calls and ops that aren't redundant in less than 11ms (16.6ms per frame, but the browser needs about 5ms to update the screen). If you're trying to do more than you can calculate in 11ms then you have to start spreading things over multiple frames hopefully doing what's most important first. This is pretty much what React's concurrent rendering claims if can do for you. If it works well it really will make applications feel significantly better. As far as I know Svelte doesn't have a solution for that. It just hopes you can get everything done in that 11ms.

To be fair, 11ms is quite a lot of time on a modern computer, so unless you're doing some heavy calculation work that you can't move off the main thread to a worker you should be fine.

Facebook has been working for a while on Ahead-Of-Time compilation for React. Interestingly, it looks like they thought the problem was too complicated and they gave up:

> To address this challenge we initially experimented with one approach to ahead-of-time (AOT) optimization — Prepack — but ultimately that direction did not pan out. Specifically, we realized that many AOT optimizations don’t work because they either don’t have enough global knowledge or they have too little. For example, a component might be static in practice because it always receive a constant string from its parent, but the compiler can’t see that far and thinks the component is dynamic. Even when we could make optimizations work, we found that they were unpredictable to the developer. Without predictability it was hard for developers to rely on them.

Instead they're now experimenting with moving the virtual DOM resolution to the server and avoiding sending all the "templating" code to the client, which achieves a similar result. See https://reactjs.org/blog/2020/12/21/data-fetching-with-react....

- smaller (because Svelte doesn't include Svelte in the binaries it outputs, but rather a dynamically generated static mapping between data and elements)

- better organised (single function components, with the JS, HTML and CSS in a single file) - like Vue!

- simpler (name = 'Joe' instead of const [getName, setName] = useState(null); setName('joe')). The last one isn't quite true as you can't use this in all circumstances - fruits.push('pear') won't update fruits, you have to run 'fruits = fruits' afterward to trigger the update (there are other ways too).

  Svelte is a component framework — like React or Vue — but with an important difference. Traditional frameworks allow you to write declarative state-driven code, but there's a penalty: the browser must do extra work to convert those declarative structures into DOM operations, using techniques like that eat into your frame budget and tax the garbage collector.

  Instead, Svelte runs at build time, converting your components into highly efficient imperative code that surgically updates the DOM. As a result, you're able to write ambitious applications with excellent performance characteristics.

When Svelte builds your app, it’s fully aware of what components will need to update when data changes, and so it can wire up those precise dependencies statically. Then when data changes at runtime, instead of needing to diff the new state against the old state, components are updated in the way that was prescribed at build time, which is maximally efficient (as long as Svelte’s compiler is reasonably smart).

EDIT: Hmm, a few minutes later, the Marko post is blank, or not, depending on whether I'm logged it. That's... unexpected. Maybe a rate limit? The working url is https://dev.to/ryansolid/what-has-the-marko-team-been-doing-... . Too late to delete the post to leave the url clear for someone else to post. :/

[1] https://news.ycombinator.com/item?id=27676785 What Has the Marko Team Been Doing All These Years? Jun14 By Ryan Carniato of Solid, now on ebay's Marko. The interesting discussion at the end (including why Marko didn't catch on) turned up: [2] https://news.ycombinator.com/item?id=27676743 Mini apps: A web developer's exploration into mini apps — apps that are built with web technologies but that do not run in browsers.

I asked Rich Harris (author of Svelte) this: https://twitter.com/jamescuenod/status/1326747369480871941?s...

Ryan Carniato (author of Solid) makes some comparisons to Svelte here: https://dev.to/ryansolid/5-ways-solidjs-differs-from-other-j... and also here: https://github.com/solidjs/solid/blob/809fd5b8683e6f8c338961...

Sites using React or Vue all seem to be searchable using standard CTRL-F for me.

In other words it virtualizes views (like when you have a 1000 row table and you only render rows 40-50), but this is not the same as DOM virtualization.

https://htmx.org - server interactions in HTML

https://alpinejs.dev - small front end tweaks in your HTML

https://tailwindcss.com - styling in your HTML

This is pretty a simple stack that keeps everything in one file (for something I am calling Locality of Behavior[1]) and all of them are dependency free.

full disclosure: I am the author of htmx

[1] - https://htmx.org/essays/locality-of-behaviour/

Browser differences are mostly disappearing, they have gained some very good APIs are CSS has gained significant layout capabilities with grids and flex. So the need for libraries like jQuery for dealing with DOM differences is disappearing. New standard libraries like Intl and now Temporal make libraries like Moment obsolete.

The web is also gaining a component model with Web Components that will help you get some level of sanity when building some mildly complex reusable stuff. This is probably very good for content heavy sites, which make the majority of the web.

The other part of the web is applications running on top of the Web platform. Those still heavily benefit from frameworks. Having some amount of sanity when managing state is very much welcome. And functional programming models have proven that a declarative way of approaching UIs is much better than dealing with browser APIs imperatively.

So for some years frameworks will still be useful for certain use cases. For the others, we should be embracing Web technologies. Maybe with some light libraries like Stencil and Catalyst.

Svelte Kit is just the equivalent of (an opinionated) Next.js, Gatsyby, or Nuxt.js framework. Those frameworks are also incredibly opinionated on purpose.

What did you find unappealing about Kit?

Sigh. https://wiki.gnome.org/Projects/Seed

(JavaScript-related, so not just any random name collision.)

I also found it pretty comical when server side rendering became a hot topic, like duh guys, that's what we were doing first! Did you forget?

Anyway, it's not that frontend UI frameworks are bad, it's more that pragmatism gets thrown out the window so quickly.

I think this approach definitely has a lot of merit, but in terms of absolutes, it's still not quite there. Specifically, you're still going to be diffing as many bindings as a component has, be it one or one hundred, even if only one changed.

Another more micro-level issue is that dynamically resolving which DOM properties to update is polymorphic, so you don't get nearly as much JIT optimization compared to a compiled approach that outputs monomorphic static property assignments.

I quite like Solid.js' approach, which addresses both of these problems via a reactive data flow and aggressive compilation, while still providing a React-like experience.

> it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in

The abstraction is valuable, but its cost need not be so high. I do wish they'd elaborate on what Svelte does differently though, or link to another post which elaborates.

Which browsers do not support natively for decades and entire markets of ecosystems grow to work around that stupidest fact. Browsers could detect, batch and “reconcile” (whatever that means) the changes to the js runtime with much less runtime and devtime overhead than it is done in js by manual state tracking and updates.

- The Angular dependency injection stuff seemed rather complicated compared with React pragmatism. Using React became heavier by the time Redux and other boilerplatish practices became widespread, but React had already gained adoption by then, and you could still get into it on tiny projects without fancy state management.

- The VDOM had articles saying how much faster it was than everything else, so it gained a reputation for speed compared with the other client-side templating alternatives at the time. Angular 1 had a reputation for being slow due to scanning all state variables on every refresh. Really React wasn't fast at everything, but fast at enough things to get that reputation. People who really understood DOM differential updates already knew how to do it faster than VDOM, either by hand or with smarter differential template compilers, but implementations weren't common. Marko and Svelte came along later.

- After years of being trained that separating HTML templates and code was the right thing to do for better engineering, preferably in separate files, it turns out that was annoying and lots of people really liked inlining the dynamic parts of HTML directly into code.

Sometimes, I'd make use of a component that did this itself, but yeah. At least back then, it was a lot of manual wiring. Maybe similar to backbonejs in some ways.

The toy video games that I wrote were more React-like, in that you would simply update your models, and then a separate process would re-render 30-60 times per second. So, as a developer, you could really just think in terms of data transformations.

Anyway, it's been 15 years since I've done either. I'm not sure how modern, native toolkits work. I assume there are decent React-like top-down-dataflow approaches these days.

Svelte native exists…

The VDOM which mirrors the document DOM is an implementation detail of React, as something sitting between the actual DOM, and the VDOM fragment returned by a React view. It’s true that if the document DOM gets fast enough, the mirroring VDOM could go away, but some diffing algorithm would still have to reconcile the document DOM with whatever fragment is returned from a view.

I think one of the realisations of Svelte is that rather than returning arbitrary runtime generated DOM fragments from views, it is better to have the view implemented by a template that a compiler can understand and manipulate at compile-time. Here we trade off some expressivity (run-time generated DOM) for the ability to do much much more at compile time - I think this is the real point that should be being made in the article.

For 90-95% of applications, a single page app architecture with a front-end JavaScript framework running a bunch of application code and rendering output is overkill and you could write the same app in half the time using server side rendering.

It'd be handy to have it as a flippable switch

Plain-JS DOM manipulation code can become quite complex very fast, and I think that's what opens the door for inefficiency and also a lot of errors, because it's hard to keep track of possible DOM permutations.

I am currently working with low-latency audio and the latency requirements mean I have minimal buffering. While the VDOM render cycle is generally fast enough to be unnoticeable to the user, it stalls the audio buffering just enough to cause some stalling. There's a few heavier parts of the application where the rendering is expensive enough to briefly stall animations as well.

While both of these issues are something we need to fix, it is specifically the rendering/vdom process that we need to work around to address these performance concerns, and we are definitely not at all Facebook.

Svelte (and some other contenders, like concurrent mode React) improve performance enough that interactive animated datavis stuff can also be done declaratively.

Implemented a undo/redo stack on top of Vuex once that worked on some very large data structures.

Got unresponsiveness after only ~3 changes to the data. Purely due to how Vuex checks state for changes. No network, no database; purely in the frontend client.

Ended up needing to freeze the state as I pushed it into the Vuex store, so Vuex wouldn't check previously pushed state for changes.

My point is, there are multiple places where, if you are building an app of scale, you can run into client performance issues.

If I'm building a desktop app that will run in the browser then it isn't much of an issue, but if that same app is expected to run on a mobile device then my wild JavaScript kludges start to really matter.

No it doesn't. Second-to-last paragraph:

"It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones."

I have heard that claim myself before.