There are at least two reasonably popular frameworks that offer reactivity without virtual DOM: Svelte and Solid. And both of them are way more ergonomic than what is presented here.
I believe VDOM-based approaches have one decisive advantage — the VDOM structure can be created by any means convenient to the programmer. To me at least, this offers more flexibility and modularity when organising code: you can create as many functions as you need to structure and reuse VDOM construction. This is something I run into with Svelte, which forces me to make a new component for every bit of code I try to isolate. Solid is a bit better — and I really like their idea of "vanishing components" — but you have to follow it's fairly strict rules (e.g. no props destructuring) or things will get weird.
By and large having no VDOM frees you from having to structure things in an unergonomic way, for performance or otherwise, whatever limitations Svelte and Solid have in this regard are self-inflicted. For example my framework allows you to destructure props just fine, still no VDOM (https://github.com/vobyjs/voby).
You can do the same with any system that treats templates as expressions that return a value (the big innovation of React, IMO), it doesn't require vdom.
In Lit, we do this with tagged standard template literal expressions that return what we call a TemplateResult. You can compute, store, abstract over those however you want - they're just JS values. This indeed gives programers a ton of expressive power.
Sure, that's the most straightforward way to approach these things, but doesn't this mean your elements don't have persistent identity between two renders? Tracking elements between renders is what allows animations and other nice things. So it's not exactly the same.
People like to hate on the VDOM, but here's some food for thought:
- VDOM is data-driven without side-effects
- VDOM does not actually require JSX or build steps
- VDOM decouples you from the real dom, which has allowed things like react-native to "just work" the way react web works.
- VDOM means you can make test assertions without having to load up a "browser-like" environment
- JSON is a pretty easy to reason-about data structure, which makes debugging fairly easy
I'm not saying the virtual dom is the best answer, but I guess my point is that it's not really an issue of speed any more. If I recall my internet history, React came at a time when browser DOM standardization was still pretty wonky, so the virtual dom did provide a boost in manipulating the data that would translate to DOM mutations. Now that we're basically all running Chrome or Firefox under the hood (give or take webkit safari), I'm not sure that's the main drive any more, but the other benefits still stand, and that's why things like react are still using the virtual dom.
Anyway, cool library. I'm curious if it provides something that is actually different from other libraries I've used, in terms of interface or flow, and I might find some time to check it out soon. Good job!
Of course you don't need the vdom for testing, but it's typically a little lighter weight since the implementation of the vdom would already be bundled in. That said people typically reach for some special vdom assertion library anyway.
First off, I am always happy to see people trying out new things because it creates innovation. Congratulations on launching!
That said, the big feature here seems to be what the headline says: no virtual DOM. As a user of frameworks, I don't care much about implementation details unless they result in benefits like performance improvements. Does this perform better than React and/or Vue? Or is there some other benefit to it?
Things like Solid (https://www.solidjs.com/) also have no virtual DOM, and the improvements are in higher ceiling for performance, lower memory usage, simpler DX (components are not re-executed, there aren't any dependency arrays anywhere), easy high performance (no useRef this and useRef that to make things fast, no useCallback, no React.memo, these things are just obsolete).
I wouldn’t call it a new thing. We began without virtual DOM and then Facebook sold us the vDOM as the ultimate way to go. Which svelte clearly shows, by removing the unnecessary layer for the vdom it’s much faster and is still reactive.
Or there is Inferno which is VDOM based and outperforms Svelte on most benchmarks. The whole narrative of "VDOM is pure overhead" doesn't hold out in practice, and I suspect really just an excuse to attack React and promote Svelte.
They did this while introducing a lot of compiler magic and automatic dependency discovery that not always works. I’m not sure I’m sold on it. Code you write is not code you execute.
Yeah, it does have significant performance improvements, because diffing the Virtual Dom adds heavily to computation costs if you aren't being extra careful or as the application grows to real-world size, especially in mobile.
No VDom is always faster than having a VDom.
But I do agree with your point 100% that it should tell you right away about it on the README what that means, and the significance behind the claim.
That’s true, but you can say the same thing about reactivity: not having it is always faster than having it. These are not zero-cost abstractions; we use them because the alternative tends to be less performant at scale, but technically you can always beat them by going in and manually updating the DOM yourself.
> because diffing the Virtual DOM adds heavily to computation costs if you aren't being extra careful or as the application grows to real-world size, especially in mobile.
Is there some recent study showing evidence or analysis of this? You're saying the main root cause of poor performance is the diff burning up CPUs?
I always assumed applications run slowly because people are overusing global (redux) state and every state change is subscribed to by like 10 different components. And people making 5 network calls before their component meaningfully renders.
Yes was going to say exactly this, tell my updates are faster or the library is smaller but just saying we built it without virtual DOM doesn’t explain the trade offs in this approach.
Can someone remind me why virtual DOM was/is desirable in the first place and why updating the DOM directly is desirable now?
If I understand correctly react elements are created in memory, and only upon "render" it is turned into the actual DOM. During render in react, it does the tree diffing and state management. Supposedly manipulating the actual DOM directly is "heavy" hence delay/pruning the virtual DOM tree first then rendering would be beneficial? Then why is it working with DOM directly is desirable? And am I right to assume that "without virtual DOM" means work with DOM directly? Someone in the comment mention that Svelte is without vDOM already. Is there some design document that I can refer to, like the reconciliation engine used in react https://github.com/acdlite/react-fiber-architecture
I don't know why VirtualDOM is suddenly getting a bad rep. The reason you often want something like a VirtualDOM is so that you can "pre-process" your DOM updates in-memory so that the actual updates, which are computationally expensive for the browser, can be done more efficiently.
I suspect, but this is just my personal conjecture, that the reason VirtualDOM is suddenly falling out of favour is a reaction against very bloated JavaScript applications and the complexity that underlies working with current popular frameworks and libraries. Some are starting to question whether we are working with solutions to actual problems faced or whether we've adopted approaches that were intended to solve a specific problem faced by some but are inefficient for simpler applications.
As always, be an engineer. Consider all relevant factors before choosing a set of tools or marrying yourself to one technology vs another.
I feel like I live in the Twilight Zone because to me data visualization with a VDOM seems much smoother than without like in Svelte even though data visualization is supposed to be a strong point of Svelte.
As someone who has only really got up to speed with React in the past year, I can't understand why people hate on React. Much of the hate has to be residual hate for Meta.
Svelte to me seems like a mess. $:variables seems like an absolutely terrible idea. Maybe it is a good idea if you are a genius but I assure you I am not and can do absolutely confusing and crazy things with $:variables.
My very rough understanding is: It's nice to be declarative and just re-render everything on every state change. This is impractical to do with actual dom, but maybe works good enough with vDOM and dom diffing. Still, doing vDOM and them actual DOM updates is more work than just doing the DOM updates that are needed. And I guess tools like svelte let you be declarative and only make the necessary DOM updates while skipping the vDOM.
Thanks! This helped lot. Now having taking a gentle look at svelte, I think it is very smart. Instead of diff-ing the virtual component tree, it is maintaining a dependency of statements behind the scene by providing a reactive declaration. Upon each event, the re-run the whole tree of statements, then update the DOM directly with the result of those statements, hence no need heavy manipulation of DOM nor diff-ing of large in memory object. I've only just started to look at svelte though, so could be very wrong. But again thank you so much for you pointer, everything just clicked suddenly.
The reason VDOM was desirable is that React's "View is the function of the State" paradigm has a great developer experience, and VDOM was just the easiest way to implement it without sacrificing performance too much.
Now that we played with the easiest implementation of V = f(S) for a few years, we're moving on to more complex implementations, which have their own benefits. Namely, less overhead and better DX.
Frameworks like Svelte are moving good chunk of state management accidental complexity out of your app code and into the framework itself, where it actually belongs (i.e. where it is essential).
> and VDOM was just the easiest way to implement it without sacrificing performance too much.
Kind of. Virtual DOM nodes are extremely lightweight compared to real DOM nodes, so manipulating a VDOM to determine what updates need to be done to the DOM, instead of doing all interactions/comparisons directly with the DOM, had a big performance boost.
It's easy to forget nearly 10 years on, but React came out when Backbone.js with mustache templates was rather common, and React was a LOT easier to manage. The other popular frameworks at the time were Ember and Angular 1, which were quite a bit larger/heavier. By comparison, React could be adopted in a much more incremental fashion. React was super easy to adopt (and it still is, but there's a lot more of an ecosystem around it now which makes it feel much more like a framework).
The author seems to suggest that React is reactive in the sense of “functional reactive programming” (a la RxJS) but React has never been “reactive” at all (see “scheduling” heading on https://reactjs.org/docs/design-principles.html).
Personally I don't get why you wouldn't use JSX for such a tool. If you're building JS apps for production you'll invariably use a bundler like Webpack so transpiling JSX to JS is not an issue, and it makes Markup code in JS so much more readable.
With JS modules it might be possible to just write JS code and include it in your HTML directly, I'm not sure if I'd recommend that though as performance might not be great as of now, and there are still many other caveats. In a few years this might be less of an issue though when HTTP/3 is widely deployed and loading many tiny files instead of one big one won't make that much of a difference.
For one, JS engines don't support TypeScript natively and it turns out that many teams who build and maintain large, ambitious SPAs think TypeScript is a productivity boost.
What exactly does this offer over, say, SolidJS, which also has reactivity without a virtual DOM, and has a much larger community, ecosystem, etc? As do several other frontend frameworks. Does the world really need another one, unless it can offer something substantially different?
I tried reactivity once to help me understand the implementation details under the hood. I wrote https://fancy-pants.js.org/ for this where I attached mutation to scheduling a render cycle. But it doesn’t address rendering leaving that to the student.
Something that really fascinates me is the difference between diffing versus declaration of dynamic content. In React and Vue it is a runtime function to know what changed and how to apply it. In Ember and Svelte it is a compile time calculation based on markers in the template.
I guess it comes down to personal preference. I’m quite the fan of a declarative style template that gets converted/compiled to a machine under the hood instead of diffing at runtime.
The alternative is a custom DSL for templating which I find much worse. Even CSS has a DSL for conditional and programmatic logic which I only use because of the immense performance benefits it brings.
Certainly not in the form of strings, no. That's a nightmare of run-time debugging just to make sure the tags are all closed and you have the correct attributes.
Perhaps pair it with a typescript library for composing it. There's nothing sacred about HTML for describing the DOM, but that it what it was created for, and the language the browser will report it.
Readit News
I believe VDOM-based approaches have one decisive advantage — the VDOM structure can be created by any means convenient to the programmer. To me at least, this offers more flexibility and modularity when organising code: you can create as many functions as you need to structure and reuse VDOM construction. This is something I run into with Svelte, which forces me to make a new component for every bit of code I try to isolate. Solid is a bit better — and I really like their idea of "vanishing components" — but you have to follow it's fairly strict rules (e.g. no props destructuring) or things will get weird.
In Lit, we do this with tagged standard template literal expressions that return what we call a TemplateResult. You can compute, store, abstract over those however you want - they're just JS values. This indeed gives programers a ton of expressive power.
- VDOM is data-driven without side-effects
- VDOM does not actually require JSX or build steps
- VDOM decouples you from the real dom, which has allowed things like react-native to "just work" the way react web works.
- VDOM means you can make test assertions without having to load up a "browser-like" environment
- JSON is a pretty easy to reason-about data structure, which makes debugging fairly easy
I'm not saying the virtual dom is the best answer, but I guess my point is that it's not really an issue of speed any more. If I recall my internet history, React came at a time when browser DOM standardization was still pretty wonky, so the virtual dom did provide a boost in manipulating the data that would translate to DOM mutations. Now that we're basically all running Chrome or Firefox under the hood (give or take webkit safari), I'm not sure that's the main drive any more, but the other benefits still stand, and that's why things like react are still using the virtual dom.
Anyway, cool library. I'm curious if it provides something that is actually different from other libraries I've used, in terms of interface or flow, and I might find some time to check it out soon. Good job!
[1] https://deno.land/manual@v1.25.4/jsx_dom/deno_dom
That said, the big feature here seems to be what the headline says: no virtual DOM. As a user of frameworks, I don't care much about implementation details unless they result in benefits like performance improvements. Does this perform better than React and/or Vue? Or is there some other benefit to it?
https://krausest.github.io/js-framework-benchmark/2023/table...
Still, the question remains, what's the improvement over Svelte or SolidJS which doesn't use VDOM as well ?
No VDom is always faster than having a VDom.
But I do agree with your point 100% that it should tell you right away about it on the README what that means, and the significance behind the claim.
IIRC in a recent stream the author of Solid showed that it's hard to beat a proper VDOM implementation when you have 1000s of elements.
And most naive non-VDOM implementations will probably lose to a good VDOM implementation.
Is there some recent study showing evidence or analysis of this? You're saying the main root cause of poor performance is the diff burning up CPUs?
I always assumed applications run slowly because people are overusing global (redux) state and every state change is subscribed to by like 10 different components. And people making 5 network calls before their component meaningfully renders.
If I understand correctly react elements are created in memory, and only upon "render" it is turned into the actual DOM. During render in react, it does the tree diffing and state management. Supposedly manipulating the actual DOM directly is "heavy" hence delay/pruning the virtual DOM tree first then rendering would be beneficial? Then why is it working with DOM directly is desirable? And am I right to assume that "without virtual DOM" means work with DOM directly? Someone in the comment mention that Svelte is without vDOM already. Is there some design document that I can refer to, like the reconciliation engine used in react https://github.com/acdlite/react-fiber-architecture
I suspect, but this is just my personal conjecture, that the reason VirtualDOM is suddenly falling out of favour is a reaction against very bloated JavaScript applications and the complexity that underlies working with current popular frameworks and libraries. Some are starting to question whether we are working with solutions to actual problems faced or whether we've adopted approaches that were intended to solve a specific problem faced by some but are inefficient for simpler applications.
As always, be an engineer. Consider all relevant factors before choosing a set of tools or marrying yourself to one technology vs another.
As someone who has only really got up to speed with React in the past year, I can't understand why people hate on React. Much of the hate has to be residual hate for Meta.
Svelte to me seems like a mess. $:variables seems like an absolutely terrible idea. Maybe it is a good idea if you are a genius but I assure you I am not and can do absolutely confusing and crazy things with $:variables.
My very rough understanding is: It's nice to be declarative and just re-render everything on every state change. This is impractical to do with actual dom, but maybe works good enough with vDOM and dom diffing. Still, doing vDOM and them actual DOM updates is more work than just doing the DOM updates that are needed. And I guess tools like svelte let you be declarative and only make the necessary DOM updates while skipping the vDOM.
Now that we played with the easiest implementation of V = f(S) for a few years, we're moving on to more complex implementations, which have their own benefits. Namely, less overhead and better DX.
Frameworks like Svelte are moving good chunk of state management accidental complexity out of your app code and into the framework itself, where it actually belongs (i.e. where it is essential).
Kind of. Virtual DOM nodes are extremely lightweight compared to real DOM nodes, so manipulating a VDOM to determine what updates need to be done to the DOM, instead of doing all interactions/comparisons directly with the DOM, had a big performance boost.
The word "React" never appears in the README.
Something that really fascinates me is the difference between diffing versus declaration of dynamic content. In React and Vue it is a runtime function to know what changed and how to apply it. In Ember and Svelte it is a compile time calculation based on markers in the template.
I guess it comes down to personal preference. I’m quite the fan of a declarative style template that gets converted/compiled to a machine under the hood instead of diffing at runtime.
Perhaps pair it with a typescript library for composing it. There's nothing sacred about HTML for describing the DOM, but that it what it was created for, and the language the browser will report it.