Cample.js: Reactivity without virtual DOM

by Cample • 3 years ago

50 92 3 years ago

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?

andy_ppp• 3 years ago

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.

larsonnn• 3 years ago

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.

nailer• 3 years ago

Solid too. But yes Svelte seems to have been the current thing for a few years now.

szastamasta• 3 years ago

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.

romualdr2• 3 years ago

You're correct, it's not new.

Still, the question remains, what's the improvement over Svelte or SolidJS which doesn't use VDOM as well ?

richeyryan• 3 years ago

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.

https://krausest.github.io/js-framework-benchmark/2023/table...

ulizzle• 3 years ago

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.

dmitriid• 3 years ago

No, it's not always faster.

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.

jakelazaroff4• 3 years ago

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.

password112• 3 years ago

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.

synergy20• 3 years ago

How is it different from svlete and solidjs? both are no-VDom approaches.

fabiospampinato2• 3 years ago

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).

tambourine_man7• 3 years ago

I’m always happy to see React alternatives but I’m not convinced HTML and CSS inside JavaScript was a good idea.

thunderbong• 3 years ago

That ship has sailed long ago!

tambourine_man7• 3 years ago

It has not. I’m right here at land, don’t intend to go and there are dozens of us here :)

jfengel• 3 years ago

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.

antihero3• 3 years ago

Yeah the second I saw the string block I noped out. JSX works really nicely and I dislike weird template string stuff now. Same with vue.

tambourine_man7• 3 years ago

No JSX for me either. I want plain HTML, CSS and JavaScript. All scoped within their files and domains.

sirsuki• 3 years ago

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.

friedman23• 3 years ago

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.

serverholic• 3 years ago

It looks like this guy has created multiple accounts and posted the same URL multiple times.

nayroclade• 3 years ago

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?

ThePhysicist2• 3 years ago

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.

foobarbecue9• 3 years ago

The self-fulfilling prophecy "you'll have to have a build step" makes me so sad.

ThePhysicist2• 3 years ago

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.

postalrat2• 3 years ago

If you don't have a build do you just have a couple giant js files you edit?

andsoitis• 3 years ago

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.

draw_down3• 3 years ago

Going without linting, testing (automated testing anyway), type checking would make me a lot sadder.

ilrwbwrkhv• 3 years ago

Yup it's ugly and tedious. Something like imba is far superior with vastly better ergonomics.

huy-nguyen• 3 years ago

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).

azangru2• 3 years ago

The author seems to suggest that React is reactive

The word "React" never appears in the README.

azangru2• 3 years ago

Reactivity Without Virtual DOM

I am confused. Why are the concepts of reactivity and of virtual DOM put together like this? Was Virtual DOM ever solving the reactivity problem?

athenot• 3 years ago

This is in the same vein as Imba, which their memoized DOM.

https://imba.io

romualdr2• 3 years ago

This place if overcrowded with solution that provide the same benefits than yours, you should clearly put a section describing the benefits of "Why us instead of X" - because it's not clear what this project brings new to the table.

toastercat2• 3 years ago

On the contrary, open source projects are not products, and this one (like many) is free to use, evaluate, and permissively licensed. So I'd encourage anyone who works on a JS framework to do as you please, don't worry about JS-fatigued HN commenters, and share your work with the world if you think others may like it. :)

dmak• 3 years ago

I only read the title, but how is this different than something like Svelte?

a_c2• 3 years ago

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

gspencley2• 3 years ago

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.

khmii• 3 years ago

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.

rmckayfleming• 3 years ago

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).

patrickthebold• 3 years ago

I think https://svelte.dev/blog/virtual-dom-is-pure-overhead might give you some answers to your question.

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.

a_c2• 3 years ago

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.

hbrn3• 3 years ago

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).

Izkata2• 3 years ago

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.

ribit2• 3 years ago

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.

fabiospampinato2• 3 years ago

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).

spankalee3• 3 years ago

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.

ribit2• 3 years ago

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.

bob1029• 3 years ago

This vDOM concept never really clicked for me. I always saw it as some sort of shiny feature that a web framework had to have in order to be considered for use during the last decade.

I've rolled a DIY web framework using websockets and a brutish technique where I simply set document.body.innerHTML to whatever the server pushes. Still haven't found a situation where this falls apart, but I am sure HN can invent a hypothetical that would make me ashamed of myself.

jakelazaroff4• 3 years ago

That won’t preserve things like event handlers and it will perform increasingly poorly as you need to render more often, but for simple use cases it’s probably fine!

hbrn3• 3 years ago

VDOM is just an implementation detail that you shouldn't care about at all.

But React team went big on advertising it as some kind of virtue, and a lot of gullible engineers bought that idea.

Jasper_• 3 years ago

The usual cases are scroll positions, selected text, form fields, event handlers, basically any state that isn't naturally captured in the HTML text. That's where the VDOM differ comes in handy, by modifying existing elements and keeping the structure similar.

spankalee3• 3 years ago

I wish more libraries would user tagged template literals instead of strings with custom expressions.

Then template expressions are just JavaScript and the library doesn't have to implement it's own limited and slower subset, like this seems to do.

mrozbarry2• 3 years ago

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!

rektide• 3 years ago

The bottom half of this list doesnt seem remarkable to me. Smaller DOMs like Deno.DOM[1] or jsdom also can do that: we dont need a vdom to do that.

[1] https://deno.land/manual@v1.25.4/jsx_dom/deno_dom

mrozbarry2• 3 years ago

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.

jiyinyiyong• 3 years ago

While virtual DOM solution has problems, I believe Dioxus https://dioxuslabs.com/ can be a better solution than Solid/Svelte solutions. We should try to optimize it with macros and other memory techniques to make it fast, rather than giving it up.

People may hold opinion that Solid/Svelte are excellent. However that's going towards another direction. Virtual DOM decouples how you declare UI and how it's rendered/updated by framework. Solid/Svelte couple them.

Cample.js: Reactivity without virtual DOM

Related Stories