Virtual DOM is pure overhead (2018)

https://svelte.dev/blog/virtual-dom-is-pure-overhead

by nailer • 7 years ago

720 332 7 years ago

saggas• 7 years ago

I have never used modern JS frameworks like Angular, React and Vue and I have always assumed (hoped) that they contained optimisations that you would be unlikely to use in your vanilla JS code even though you could. Something like FastDOM which batches read/write operations to avoid unnecessary reflows. Do they contain anything like that?

xtagon2• 7 years ago

I'm not sure if this is exactly what you mean, but Ember.js has a concept called a "runloop" which batches different actions into queues, which does seem to help with rendering/reflows.

zeugmasyllepsis• 7 years ago

To varying degrees depending on the library, I believe the answer is "yes, they sometimes do". Angular and Ember at least have systems for batching user interactions, which translate into model updates, and thus potentially DOM updates. I believe the respective systems for handling this are called Zone and Backburner for Angular and Ember, but I've been out of touch with those projects for a couple of years.

There's definitely a trade-off, however. They make a huge difference for noisy events (like mouse move, scrolling, dragging, etc), but tend to make debugging much harder in my experience. When things go wrong, the stack traces nest deeply into the event handling systems and code paths no longer resemble the relatively straightforward world of traditional event calls, where a callback handler is invoked directly in response to a single event.

kevingadd4• 7 years ago

Virtual DOM is a shaky long term bet since it's essentially betting that the cost of DOM operations will always be high enough to justify all the work you're doing (both at runtime and at trying-to-figure-out-how-to-write-this-code time). When it's easy to do your virtualization, you can just go 'well this is an optimization i can remove at any point', but if it's suddenly so complex it introduces bugs, you're in trouble.

Naturally, the cost of DOM operations didn't go unnoticed and while people have been going in on virtual dom solutions like React, the devs of Firefox, Chrome and Safari have all been aggressively optimizing the dom - making the native code bits faster and moving more of the DOM into javascript so all your JS can get inlined and optimized. It gets harder and harder for libraries to compete with regular DOM as a result.

striking• 7 years ago

react-dom (https://github.com/facebook/react/tree/master/packages/react...) is shipped as a dep of react, and seems to be where all the heavy lifting is. I believe that, should DOM ops become fast enough that you don't need vDOM anymore, you could easily no-op all of this out with direct DOM calls.

mantap• 7 years ago

Surely JS engines are also optimising React-style code. e.g. the article says that react style code does a lot of unnecessary object creation (e.g. map) but if that is now a common pattern then JS engines can do a lot to optimise that away.

kevingadd4• 7 years ago

You can optimize the unnecessary operations but it's a lot more work to fully determine that they're unnecessary and erase them.

addicted2• 7 years ago

Well, you could also potentially have a future where the VDom is the primary Dom in itself.

As in, the VDom doesn’t need to be converted to HTML for the browser to render, but rather, the browser directly converts the VDom objects into Pixels.

pier253• 7 years ago

The cost of the DOM operation is the same. The difference is that React batches the changes to reduce the number of operations whenever possible.

Sawamara4• 7 years ago

Ew, not really. Even the getters can be performance-heavy in DOM-land. If you store your data in JS-land, and only diff against that, you never need to touch the dom for anything, except the endpoint insertions. At worst, it is matched evenly by any sort of custom vanillaJS+Dom manipulation tool (which needs to be perfectly well written, and hand-crafted to match what you are currently working on). At best, its several orders of magnitudes faster compared to a badly written DOM-manipulation-heavy code.

tannhaeuser• 7 years ago

DOM operations (node insertions, deletions) are trivial. It's the CSS reflow/relayout that's expensive. Though that can be trivially solved by preparing a shadow DOM off-screen, then finally replacing the changed fragment by the newly build-up one. DOM diffing is just a convenient method to do it.

spankalee8• 7 years ago

This is absolutely true.

Virtual DOM diffs do a huge amount of unneeded work because in the vast majority of cases a renderer does not need to morph between two arbitrary DOM trees, it needs to update a DOM tree according to a predefined structure, and the developer has already described this structure in their template code!

A large portion of JSX expressions are static, and renderers should never waste the time to diff them. The dynamic portions are clearly denoted by expression delimiters, and any change detection should be limited to those dynamic locations.

This realization is one of the reasons for the design of lit-html. lit-html has an almost 1-to-1 correspondence with JSX, but by utilizing the static/dynamic split it doesn't have to do VDOM diffs. You still have UI = f(data), UI as value, and the full power of JavaScript, but no diff overhead and standard syntax that clearly separates static and dynamic parts.

The syntax is very close:

JSX:

   render(props) {
     return <>
       <h1>Hello {props.name}</h1>
       {props.items
          ? <ol>{props.items.map((item) => 
              <li>{item.label}</li>)}
            </ol>
          : <p>No Items</p>}
     </>;
   }

lit-html:

   render(props) {
     return html`
       <h1>Hello ${props.name}</h1>
       ${props.items
          ? html`<ol>${props.items.map((item) => 
              html`<li>${item.label}</li>`)}
            </ol>`
          : html`<p>No Items</p>`}
     `;
   }

I really think the future is not VDOM, but more efficient systems, and hopefully new proposals like Template Instantiation can advance and let the browser handle most of the DOM updates natively.

edit: closed JSX fragment as pointed out

foobarbecue• 7 years ago

Typo -- you didn't close your fragment on the JSX.

ec1096853• 7 years ago

One thing nice about React is that it can take care of quoting for you depending on the method call the jsx template translates into (attribute, value, element name). String templates doesn’t have that nice property.

spankalee8• 7 years ago

Can you explain that more?

I'm not sure what you're saying is true with lit-html. You don't have to quote attributes with single expressions.

    html`<div class=${myClass}></div>`

is perfectly fine.

arthurdenture• 7 years ago

lit-html is context-aware and safe, just like JSX. It's not a raw string templating library.

https://lit-html.polymer-project.org/guide/template-referenc...

lacampbell3• 7 years ago

Do you use lit-html?

The idea is interesting. It looks more procedural than say preact, but I also appreciate the directness.

dmitriid3• 7 years ago

I really think the future is not VDOM, but more efficient systems, and hopefully new proposals like Template Instantiation can advance

Template Instantiation is like a half of a half of 1% "advance" in the best case scenario. It's being rushed forward despite the fact that no one sat down and listed all the benefits vs. all the downsides of implementing it in the browser.

What browsers do need is a declarative DOM API and a native "DOM as a function of state" which renders the whole instantiation proposal moot, and at the same time actually advances the browser as a platform.

There's a discussion on GitHub which in my opinion is going nowhere because TI is viewed as unquestionable good https://github.com/w3c/webcomponents/issues/704

xtagon2• 7 years ago

Svelte's philosophy on turning the virtual DOM concept inside out sounds like it has merit, and is very promising. But it's going to take a lot more than that, in my opinion, before a large number of people consider switching from React, Ember, etc.

I don't see that as a drawback, I see it as an open opportunity for Svelte to keep building out on improvements other than the DOM updates, and catching up with everything else the SPA alternatives provide that have nothing to do with the virtual DOM.

For example, Ember is just a joy to work with, and makes it easy to rapidly prototype reactive frontends in a way that reminds me of Ruby on Rails's initial appeal to developer happiness, and the tooling is very mature. If you could unlock all those benefits while keeping the blazing fast DOM updates, oh boy!

hatch_q• 7 years ago

Tooling is the key word here. Svelte simply doesn't have the tooling needed for any big project. - testing/testability (unit-tests are easy, but what about functional, e2e?) - strong-typing support (flow, typescript) - good IDE support? - i18n? ICU support, etc? They need to redo what ember-intl or react-intl do.

Without these things it's simply not viable to start bigger projects with new framework.

nemothekid4• 7 years ago

Virtual DOM is pure overhead*

* Compared to doing static analysis and optimizing your UI updates at build time.

While I certainly agree that svelte's approach may be the future, I think React and others, are very much a needed stepping stone (especially when you consider all the work done transpiling JS code).

The Virtual DOM was the most performant solution that applied generally to many a large number of cases. The reason almost everyone did `x.innerHtml = html` is that it was the most general and widely available solution.

floatboth6• 7 years ago

No, you don't need to do anything at build time! (You don't even have to have a build time.)

You can just… instantiate a template, remembering where the "holes" are, to get precise update functions for every data field that gets inserted into the template. This is what lit-html does, and it's such an obvious approach I'm really surprised that VDOM took off before it.

https://lit-element.polymer-project.org

Lowkeyloki3• 7 years ago

First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented.

Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library, all things considered. The only compilation step necessary is JSX to Javascript. JSX maps pretty directly to React's API. This means compilation is pretty simple. So much so that you can do it by hand really easily if you really wanted to. Svelte, on the other hand, is pretty compilation-heavy. There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that compared to React's runtime library approach. But if you are comfortable with that trade-off, that's perfectly fine. It is worth being aware of it, though.

kabes• 7 years ago

Virtual dom is an implementation decision for performance a developer shouldn't even be very aware of. The main upside to react is that it has a huge ecosystem.

Waterluvian• 7 years ago

You should at least be aware of the gist, lest you obsess over premature optimization.

1. Changes to the DOM cost a ton more than executing JS code.

2. So don't feel too bad when a render() gets called that doesn't change anything because the virtual DOM swallows that.

adzm• 7 years ago

Note that even jsx is not technically required, and on occasion I've clenched my teeth and written non-jsx react code for some one-off demos.

toastal• 7 years ago

Weird. I feel like clenching my teeth using JSX and a compilation step when a function suffices.

acemarke4• 7 years ago

Jason Miller's `htm` library is a great alternative: nearly-JSX syntax via template strings, with no compilation needed:

https://github.com/developit/htm

jordache2• 7 years ago

functional and composable way components can be designed and implemented.

Ughh.. that's the point of all modern FE frameworks...

You are putting that description on a pedestal as if that is a unique property of React.

munchbunny2• 7 years ago

Composable, yes, but functional as in functional programming, no.

somerando73• 7 years ago

Currently trying to find a new framework to do a front-end with because the company I'm currently interning doesn't allow React :^)

Looking at angular code, it's pretty ugly. What would be the next best thing to look at? Vue?

namelosw7• 7 years ago

React is more like 'Lambda the Ultimate Web Component'.

A component is almost a function returns element. Expanding a component is like calling a function and give it the property.

So you can have some abstract common behavior in HOC f and g, then you can have HOC `h = compose(f(g))`.

A quick comparison with Angular: @Component({template, style}) seems composable if we stretch a lot. But why make template and style in the decorator... They are not something we consider most abstract at all.

The function is the simplest yet composable abstraction over the template, Cheng Lou also has a really excellent talk on the topic: https://www.youtube.com/watch?v=mVVNJKv9esE&t=1470s

Lowkeyloki3• 7 years ago

Other projects in my company are still using Angular 1.x and Backbone. I guess it depends on your definition of modern.

fouc• 7 years ago

Isn't it possible to skip the compile step in react, by using hyperscript instead of JSX?

blotter_paper• 7 years ago

Hyperscript isn't necessary. React's jsx is just getting transformed into React.createElement() calls which you can do manually: https://reactjs.org/docs/react-without-jsx.html

namelosw7• 7 years ago

It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte), it's never clear what's the differences between them.

It's almost a new language but similar every time, with different pitfalls -- an ad-hoc, informally-specified, bug-ridden, sometimes slow implementation of half of HTML and half of JavaScript.

For example, a framework Foo does not have the concept 'else' at all in HTML template. Another framework Bar has an 'else' like <div bar:else="expr" />, but the scope of else is totally different from another framework Baz or JavaScript itself.

JSX on the other hand, is straightforward -- when you open a curly bracket, it's just JavaScript expressions -- map, condition, lexical closure, everything works out of the box.

preommr4• 7 years ago

It always bugs me when I'm using a framework with custom HTML templating language (Angular, Vue or possibly Svelte)

This is the most ridiculous thing I hear when people compare frameworks.

I don't know about angular anymore, but with vue you can use jsx if you wanted to. It's in the official docs, so it's not some random third party support either.

Also, my dude, there's like half a dozen rules when it comes to vue templates. Jsx has lots of small rules about component names and things like class vs classname as well.

As for putting javascript expressions in your templates... Each to his own I guess, because imo it's a pretty bad anti-pattern to put an extensive amount of procedural code in the template code. Again with vue, using things like computed properties in single file components (SFC) makes it very easy to read and maintain code.

Rotareti• 7 years ago

Don't forget to mention the poor (and complicated) editor support for "these custom HTML templating languages". JSX is very well supported in most editors.

dirkg2• 7 years ago

Anything with a DSL is evil. That's why I never liked Vue and don't understand its huge popularity - you get none of the functional benefits of React, you might get a minor speed increase, and you DO get to write code the old style with custom DSL and no clear components.

nailer3• 7 years ago

Svelte, on the other hand, is pretty compilation-heavy. Personally, I'm less comfortable with that compared to React's runtime library approach.

Svelte compiles, React runs at runtime, that's true.

I've spent the last week (and weekend) doing the UI for a new project in Svelte. The compiler approach is pretty rad as it seems to catch more errors before I test them in browser.

You can download any project from the https://svelte.dev/ tutorial / online REPL and it'll have a rollup file, watching files, compiling them and telling about broken code.

vscode also has a plugin for Svelte components that shows pretty underlines while you work. The compiler approach means I see more warnings faster and save time.

dahfizz• 7 years ago

There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that...

How is this different than the "non-trivial" transformations that V8 makes to actually compile and run your code? Does svelte do unpredictable / unexpected things? Don't you make runtime calls to the react lib where they can do whatever they want? I'm genuinely confused.

I don't care one way or the other - I'm not a web dev. It seems from this comment that you're just scared of compilers, which is strange. No matter what you're relying on third party libs in your code. Why is it somehow safer for that third party code to be used at run time rather than compile time? I would probably argue the opposite. Why the strong aversion to compilers?

Lowkeyloki3• 7 years ago

I don't actually have a strong aversion to compilers. I use tools like Babel and Webpack regularly. However, I've seen the types of transformations the Svelte compiler does and they tend to hide complexity, making it harder to trace and debug code at runtime. Source maps can only do so much. It's much harder to debug code that doesn't resemble what you wrote in the first place.

atan6• 7 years ago

There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that compared to React's runtime library approach.

I initially had a similar concern, but so far, the opposite appears to be true. The Svelte compiled code is quite readable and easy to follow, and because there is no runtime, it's much easier to walk through exactly what is happening. With a complex runtime, it can sometimes be difficult to figure why something isn't working as expected without having a deep understanding of the runtime codebase.

thoman23• 7 years ago

2 things I'm not seeing in the article or in the comments so far:

1) The virtual DOM is an abstraction that allows rendering to multiple view implementations. The virtual DOM can be rendered to the browser, native phone UI, or to the desktop.

2) The virtual DOM can, and should, be built with immutable objects which enables very quick reference checks during the change detection cycle.

spankalee8• 7 years ago

There are other ways to represent a UI as data that don't require a diff. JSX's default compiler output throws away information needed to do efficient updates, and instead requires diffing the entire old and new trees.

Immutable objects may optimize for checking for data changes, but only if you do that, as in shouldComponentUpdate or checking inside render(). They don't optimize the _diff_, which is done against the DOM.

keymone• 7 years ago

How often is diff done against the DOM? My understanding is that it’s done against last valid vDOM instead.

kgwxd2• 7 years ago

On point #2, ClojureScript not only provides immutability out of the box, but also has libraries for replacing JSX with the same stuff everything else is built with. It's an insanely beautiful way to work with React.

city41• 7 years ago

Reagent is probably the best UI dev experience I’ve found yet.

A quick blog post explaining why for anyone curious about reagent: https://www.mattgreer.org/articles/reagent-rocks/

kgwxd2• 7 years ago

There's a good discussion about this article on the Clojure Reddit sub: https://www.reddit.com/r/Clojure/comments/bqh0z4/virtual_dom...

chrismorgan• 7 years ago

1: there’s no reason at all why VDOM should be the abstraction over the multiple view implementations; there’s no need: it’s all duck typed, so make DOM (or at least the subset of it that Svelte will generate) the abstraction that other things must implement. I believe this is how Svelte Native works.

Furthermore, as a compiler, Svelte is well placed to render to multiple implementations, efficiently—though implementing it is likely to take more effort if you’re dealing with a different-shaped API. This is demonstrated by the fact that Svelte has two compilation targets at present. First, dom, which is designed for client-side DOM operation; and secondly, ssr, server-side rendering, which is based on emitting strings, and never constructs a DOM.

2: even if you can do things that way, you’re still doing more work than is necessary, because you’re calling the whole render method and performing even simple comparisons that just aren’t necessary. VDOMs render methods are allocation-heavy, because they deliberately create new objects all over the place. In the words of the article, which I assert does deal with this, albeit obliquely: virtual DOM is pure overhead.

guscost• 7 years ago

From the conclusion:

Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough.

In other words, Virtual DOM is somewhat-valuable overhead. This is a cool alternative, seemingly sort of a compile-time version of Knockout. It's probably worth a try for writing an efficient client app, but I have a hunch that I'd miss the "HTML-in-JS(X)" pattern if I went back to using "JS(?)-in-HTML" instead. A VDOM runtime allows you to write plain JS that "just works", at least until certain parts need to run faster. This means junior programmers can pick it up and become productive quickly, and avoid driving their projects off a metaphorical cliff.

Of course this is bought with bandwidth and CPU overhead, lots of it in some cases. The call you should make when considering a VDOM is whether the safety and familiarity benefits are worth the overhead. If your team is experienced enough to take on a new DSL for rendering markup (which every template-binding tool really is) and meticulous enough to assign instead of mutate and avoid two-way binding pitfalls, go for it. If not, be careful.

This is not meant as a challenge. Personally I wouldn't want to work on a big application that is wholesale optimized in this way, unless there was no alternative. I wouldn't write my own game engine (if it was for a job) either.

floatboth6• 7 years ago

You can easily do HTML-in-JS "react-like" rendering without diffing!

lit does just that https://lit-element.polymer-project.org

namelosw7• 7 years ago

I thought this was well known years ago. A better description for VDOM should be 'It's not fast, and is not slow either'.

But frankly, what I see in virtual DOM is not about speed. It's a declarative interface, an abstraction. It's more like a blueprint that's easier to interpret across different environments like React Native, WebGL. Even if you don't need any of these cross-platform benefits it's still good for testing -- without real DOM.

As for performance, it could be an aspect of advertising but I doubt it really matters anymore.

I saw many applications where AngularJS is too slow, and I even worked on one for quite a while -- it's just a fairly typical 'enterprise application'. But I still yet to see a real-world front-end project where React is too slow.

Users won't even care about if it is 10ms or 30ms.

Rusky2• 7 years ago

The point of the article is that you can get that same declarative interface at much lower cost, with a more efficient implementation.

namelosw7• 7 years ago

I'm not sure if it's still an 'interface' since it's compiling another language to imperative code which operates DOM API. So it requires other platforms implements a similar imperative API surface as DOM.

Bahamut• 7 years ago

I work on one with React that is too slow in the browser with a team that only has senior devs, and users even filed bugs about the performance - we do heavy computations, and React's model of blocking rendering on having everything updated can freeze our UI for up to 10s while data comes in from various API requests. I believe our app would be performing much better for the end user if we were using Angular 2+ interestingly enough due to its built in incremental updating - there would be other tradeoffs though.

Part of the problem is not having good enough APIs currently (we have to make too many API requests and data payloads are too fat, sometimes up to 2 MB per request), but imperfect APIs tend to be the case in a lot of apps early in their lifecycle. I've actually been a bit disappointed in React's performance from a UX perspective.

charrondev• 7 years ago

This seems almost entirely unrelated yYou framework though.

You are blocking rendering on IO. This can be greatly improved by offering

- Good loading indicators that stay consistent for related IO. - Caching to speed up or remove the need for requests. - Fetching related data in parallel. - Prefetching data.

jasonshaev• 7 years ago

I don't understand what this has to do with React. You are sending 2MB of data to the frontend. Can you paginate it? Request a subset?

If you are fetching data from multiple endpoints and waiting to render anything until ALL of them come back, that has nothing to do with React. You can start rendering the components that already have their data as soon as it comes back, not wait for all of the other components to have fetched.

computerex2• 7 years ago

What a strange post. Yes, virtual DOM is overhead, much like JIT compilation is an "overhead". But this overhead ultimately translates to better performance because many virtual DOM transformations can be buffered into 1 transformation of the real DOM.

Rusky2• 7 years ago

Better performance than completely recreating the DOM, sure. But all the time spent constructing and diffing the virtual DOM is pure overhead compared to simply doing that 1 real transformation directly.

azangru• 7 years ago

ultimately translates to better performance

Better compared to what?

For a library like React, which re-renders the DOM tree every time component’s props or state change, virtual DOM with diffing and patching is indeed a better approach as compared to naive re-rendering of the whole DOM.

But as Rich Harris said during his talk about Svelte v.3.0, whenever he hears claims about better performance of frameworks based on virtual DOM, illustrated with benchmarks, he runs the same benchmarks with Svelte (not based on virtual DOM), and inevitably gets better results.

nemothekid4• 7 years ago

But as Rich Harris said during his talk about Svelte v.3.0, whenever he hears claims about better performance of frameworks based on virtual DOM, illustrated with benchmarks, he runs the same benchmarks with Svelte (not based on virtual DOM), and inevitably gets better results.

That isn't a fair comparison. Consider this analogy - React is the JVM and Svelte is Rust. JS before either is C. Now it can be shown that in most cases that C is faster than anything on JVM, but in reality it wasn't, and that C code was riddled with bugs. The JIT'd JVM comes a long and guarantees safer and more performance code. Then someone comes a long and says the JIT is overhead rewrites everything in Rust and shows how fast the program is.

What's being ignored is the man-years, technology and insights that made Rust possible. The fact of the matter is, (1) code that is written like Svelte generates was incredibly rare and difficult to achieve and (2) Svelte is pretty radical in how the framework is implemented (at a high level, Svelte is essentially doing static analysis on your code to figure out where the DOM is being updated, serving a like-minding purpose of Rust's borrow checker).

computerex2• 7 years ago

Better compared to what?

Better than, presumably the old way of doing things, doing DOM transformations manually in handwritten code.

I haven't seen these talks by Rich Harris but they sound very interesting and I'd be very interested to see the performance.

austincheney4• 7 years ago

The JIT is not overhead and it is in no way related to the DOM. The JIT is a compiler in a VM. The DOM is a standard data model living in memory.

ummonk• 7 years ago

The danger of defaulting to doing unnecessary work, even if that work is trivial, is that your app will eventually succumb to 'death by a thousand cuts' with no clear bottleneck to aim at once it's time to optimise.

This is so true in practice.

ng122• 7 years ago

I keep hearing this and find it really hard to care about. Runtime performance is not a bottleneck for me. Once in a blue moon I'll have to optimize a React component with shouldComponentUpdate but otherwise I have no performance concerns even on old browsers.

There are other characteristics that are very, very important like build size. VDOM is not worth thinking about.

Honestly I don't understand Svelte. It sounds like it's very good at the things it does but the things it does are not the things I need.

dsissitka2• 7 years ago

If you value build size you might want to take another look at Svelte. Build size is one of its strengths. For example, the Svelte implementation of RealWorld is roughly 10% of the size of the React/MobX implementation:

https://medium.freecodecamp.org/a-realworld-comparison-of-fr...

Edit: Confused the React/Redux implementation with the React/MobX implementation the first time around.

JMTQp8lwXL5• 7 years ago

To my understanding, one of (or the singular) author of Svelte was a developer for the NY Times who wanted to easily create visualizations with thousands of data points, and the existing UI libraries weren't cutting it on performance. Depending on the types of applications you build day-to-day, this problem space might be niche. Your standard CRUD app (tables, forms, etc) would not be leveraging Svelete's capabilities; in a sense, it could be a pre-mature optimization.

ralphstodomingo3• 7 years ago

I feel as if Svelte came at the wrong time. These days, when most people know either React or Vue or some other thing, and computing devices are performing better over time, there's diminishing returns on performance optimization. Sure, you do a bit of it, and then you're often better doing something else, like enhancing developer experience for example.

I really like the idea, and will play around with it, but fat chance it's getting into production with me. I am much more productive with React now, and I worry more about business requirements than raw performance (that I almost never worry about these days).

atan6• 7 years ago

Sure, you do a bit of it, and then you're often better doing something else, like enhancing developer experience for example.

Aside from its performance optimizations, arguably one of the biggest selling points of Svelte is its developer experience (which is enabled by it being a compiler). See https://svelte.dev/blog/svelte-3-rethinking-reactivity. And because only the features used in your components get included in the final bundle, the framework is free to add nice extras (like its transitions/animations system) without negatively impacting apps that don't need those extras.

osrec2• 7 years ago

We implemented a library at my company that does not use a virtual DOM, but instead captures reactive "change functions".

The framework captures dependencies between the reactive "change functions" and underlying variables, and executes the functions whenever a variable's value changes. You can also have dependencies between variables (like computed vars in Vue), and the lib works out the correct order for calculation and execution. All the change functions get queued up and applied in order before the next repaint.

Everything is component based, and there is even a nice kind of inheritance (with lazy, async component loading).

It works rather well. I'd be happy to share it with anyone that's interested! Not open sourcing it yet, as I envisage it would be a full time job to support it!

Edit: the upside of the change functions is that YOU decide how the DOM is updated. It's really quite cool to be able to implement a function like the following and have it run to update this.$dateOfBirth whenever this.data.dateOfBirth changes:

  function()
  { 
    this.$dateOfBirth.val(this.data.dateOfBirth);
  }

That is of course a simple example, but when you need even more control, reactive change functions have proven to be super useful (for us anyway!).

markharper• 7 years ago

That sounds similar to the incremental lambda calculus described in this paper: https://arxiv.org/abs/1312.0658 There's an implementation for DOM updates in Purescript (https://blog.functorial.com/posts/2018-04-08-Incrementally-I...), but I haven't come across a similar approach in Javascript yet.

osrec2• 7 years ago

Yes, it's a similar idea. The only difference I can see is that in our library, the dependencies are automatically tracked, and there is some additional clever scheduling around when a function should be run.

wnevets2• 7 years ago

I remember when react was new and the reason why everyone should use it was because of its virtual dom and lack of typescript.

Now everyone is saying the virtual dom isn't the point and advocating typescript.

ec1096853• 7 years ago

Seriously, who actually said lack of typescript was a plus for React ever? That seems like a non-sequitur.

wnevets2• 7 years ago

A lot of people back when every blog was comparing Angular (read not angularjs) and Reactjs.

QuadrupleA• 7 years ago

So glad to see this article, I've long wondered how this "virtual DOM is faster" myth got accepted as gospel when clearly it's pure overhead, compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps).

Can't speak to the svelte approach due to inexperience with it, but good to see this myth challenged - react.js is fine but I worry there's been a cargo cult mentality around it, that it's The One True Modern Way To Do Web Apps, when really it's a tradeoff that involves some extra layers and performance baggage, and like any tool you need to weigh the pros and cons.

andrewfromx• 7 years ago

tell me about it! Or, heaven forbid, just make the user get the entire html page rendered from server after every click like it's 2003 or 2004!

muxator• 7 years ago

Which sometimes is not bad at all. Ever tried to ctrl-click an interface element (a navigation button, a menu) because you want to open its view in a new window?

A lot of (admittedly badly coded) "modern" web apps ignore basic web idioms (like hyperlinks) and assume as unique single user workflow the one its designer tought the app (and the only one he tested).

mruniverse2• 7 years ago

Yeah, you're right. But then you get others now trying to say "No no no, you have it all wrong. We didn't really say VDOM was faster. You misunderstood."

Tade02• 7 years ago

I hate this type of argument - blaming the receiver while at the same time taking no responsibility for their poor wording.

lacampbell3• 7 years ago

compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps)

Do you do full blown SPAs with this technique? I mean I'm sure it's possible, but I wonder how difficult it is.

I wouldn't use (p)react for a website that just needed a bit of AJAX, but I find it a bit hard to imagine doing an actual app with vanilla JS.

vast• 7 years ago

React and friends made themself show up on every party. Even if the model isn't remotely appropriate for the taks at hand, you have to argue about them. I am convinced that half the modern frontend devs don't even know how a "classic" web app could work. SPAs or frameworks usually used for SPAs are the default state and there isnn't any competitive option with a real name except jquery/ajax/html. Even talking about the latter will brand you as dinosaur in many circles.

austincheney4• 7 years ago

but I wonder how difficult it is.

Its not if you have some basic understanding how the code actually works.

but I find it a bit hard to imagine doing an actual app with vanilla JS.

Try it. It will blow your mind how simple it is and how little overhead it requires.

Tade02• 7 years ago

react.js is fine but I worry there's been a cargo cult mentality around it,

And also an actual personality cult directed at some key people.

nailer3• 7 years ago

compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps).
Can't speak to the svelte approach due to inexperience with it

Heya! I'm been using Svelte for the last week for a new project - knowing React has the lion's share of community right now, but feeling like Svelte is where things are going to be.

Regarding: "compared to a well written app that updates the DOM directly only when needed" - exactly! Svelte actually does this for you. Given the following Svelte code:

    age = 7;

That just updated anything bound to 'age' in the DOM. No set() or setState() or whatever. Or for an array:

    favoriteFoods.push('peaches');
    favoriteFoods = favoriteFoods;

That just updated the DOM for anything bound to 'favoriteFoods'.

The whole point of Svelte is that it takes your input JS, and builds the well written app as output!

It's very easy to pick up and I like it a lot.

https://svelte.dev/

jeremyjh• 7 years ago

Svelte definitely is compelling, but one thing I really like about using React or Vue.js are the very mature communities and in particular the full-featured styled widget libraries. Projects like Semantic UI React[1] or Buefy[2] (Bulma/Vue.js) give you so many basic components that would be major time sink to create yourself in every project. Does Svelte have anything like this?

[1] https://react.semantic-ui.com

[2] https://buefy.org/documentation

revskill• 7 years ago

To me, React is more about Developer Experience. The ease to reason about the app is far much more important than anything else.

The problem with Svelte, is that, it sounds "words louder than action".

You can learn from React documentation. Instead of throwing a bunch of concept to the dev face, it brings out the WHY of ReactJS with real code.

Teaching users right from documentation is the best way to introduce a library/framework for user to really experience with the tech.

rahimnathwani• 7 years ago

If you like the React documentation with real code examples, you'll love the Svelte tutorial with both code examples and a live playground. The UI is beautiful, too:

https://svelte.dev/tutorial/basics

The examples are also very clear:

https://svelte.dev/examples#hello-world

reilly3000• 7 years ago

Has anybody here migrated a UI from React to Svelte? How did it go?

ru999gol• 7 years ago

of course not, this is just opinionated rubbish, in the real world people use react dom/native

PudgePacket2• 7 years ago

Be kind. Don't be snarky. Comments should get more thoughtful and substantive, not less, as a topic gets more divisive.

https://news.ycombinator.com/newsguidelines.html

https://mobile.twitter.com/sveltejs/status/10885005396404183...

paulddraper• 7 years ago

I quote an Angular contributor

If you call something "view" and diff it, then it's Virtual DOM.
If you call something "view model" and diff it, then it's Dirty checking.

(Angular uses the latter.)

https://github.com/angular/angular/issues/22587#issuecomment...

Lx1oG-AWb6h_ZG0• 7 years ago

Dan Abramov has a great thread about this here: https://mobile.twitter.com/dan_abramov/status/11209717954258.... In particular, I find this argument really persuasive:

Time slicing keeps React responsive while it runs your code. Your code isn’t just DOM updates or “diffing”. It’s any JS logic you do in your components! Sometimes you gotta calculate things. No framework can magically speed up arbitrary code.

In my experience, as your app grows, the amount of time you spend on dom reconciliation becomes negligible compared to your own business logic. In this case, having a framework like React (especially with concurrent mode) will really help improve perceived user experience over a naive compiled implementation.

tylerhou2• 7 years ago

In my experience, as your app grows, the amount of time you spend on dom reconciliation becomes negligible compared to your own business logic. In this case, having a framework like React (especially with concurrent mode) will really help improve perceived user experience over a naive compiled implementation.

In my experience, the exact opposite occurs. If there is ever any heavy computation I need to do, I usually try spawn a web worker or offload it to the server. In contrast, as your app tree grows reconciliation costs grow (super?)linearly, and more importantly there is (currently) no way to offload reconciliation.

dmix3• 7 years ago

Same, the only time I've run into performance issues with Vue after building many very complex deeply nested components prior to this was one which ground to a halt on re-rendering because I was simply rendering too many elements into the DOM with their subsequent watchers filling up memory.

After hours of combing through frames of the memory profiler and seeing only highly concurrent framework calls the only solution was to paginate the particular content. 99% of the users never had this issue but it was 1-2 customers who had thousands of components to render instead of the usual hundreds.

I'm really curious now if Svelte would have helped with that because it was a huge dev timesink and one where I was never satisfied with the solution. As it really should be able to render that amount of data. It obviously wasn't a problem in the jQuery/Rails version I was replacing and improving upon (although page load times was higher).

The new React concurrency model wouldn't have helped from what I've read. I just needed something lighter weight from the rendering model itself. Vue 3.0 is apparently going to come with plenty of performance improvements so I'm looking forward to that as well.

spoiler• 7 years ago

Product/application growth doesn't necessarily mean the DOM grows, though.

dsissitka2• 7 years ago

Rich recently addressed this:

https://youtu.be/AdNJ3fydeao?t=1128

bastawhiz2• 7 years ago

I think it neglects Dan's original point. Say you're doing a search input that filters a list of elements using fuzzy matching. No amount of optimization in your components or the framework is going to make the fuzzy string matching library you use work faster. Faster renders might make more room for the main thread to update, but fundamentally the problem persists. Concurrent React would allow you to type while the fuzzy matching happens asynchronously.

This is different than the demo shown. The demo with the charts is very render heavy. It's an unrealistic experience (and in my opinion, it is regretful that it was used to show the power of async rendering). In any real application, if you're rerendering thousands of nodes on every key press when their component instances are not changing input/state, something is very wrong. A fuzzy string matching filter is a much better example of this, since the visibility of each item is dependent on the state of the text input.

Sure, not all items in your list will update simultaneously. But are they really all visible on screen? Do they really all do need to be updating instantly? The overhead of the framework is almost certainly negligible here either way. But the scheduling that takes place is going to be critical, because that's what will directly affect how the app's performance is perceived by the user.

pan_43212• 7 years ago

That's actually what I didn't understand in Dan Abramov's response ...

If you run a synchronous function that takes 2 seconds your app will block whether you use Svelte or React or whatever. You need to offload it to a webworker anyway.

Still I think it's a good idea to update the DOM not more often than needed: Only update the last change of an element every 23 ms and skip the changes that have been overriden. You can do this without a virt DOM.

oraphalous3• 7 years ago

I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced.

Here's the gist of how folks would often update an element. You'd subscribe to events on the root element of your component. And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child elements that need updating - inspecting the DOM in various ways so as to determine the component's current state.

If your component needed to affect components higher up, or sibling to the current instance - then your application is often doing a search of the DOM to find the nodes.. and yes if you architect things well then you could avoid a lot of these - but let's face it, front end developers weren't typically renown for their application architecture skills.

In short - the DOM was often used to store state. And this just isn't a very efficient approach.

This is what I understood the claim that VDOMs are faster than the real DOM meant - and the article is pretty much eliding this detail.

As far as I'm aware React and its VDOM approach was the framework that deserves the credit for changing the culture of how we thought about state management on the frontend. That newer frameworks have been able to build upon this core insight - in ways that are even more efficient than the VDOM approach is great - but they should pay homage to that original insight and change in perspective React made possible.

I feel this article and many of the comments here so far - fail to do that - and worse, seem to be trying to present React's claim of the VDOM faster than the DOM as some kind of toddler mistake.

toasterlovin• 7 years ago

Not really a JS developer, but from my recollection, everything you said is essentially correct. I was on the periphery of the Ember community when React dropped. I remember a blog post or something where the Ember developers basically acknowledged that React's virtual DOM approach was significantly more performant than what Ember was doing and, to the Ember community's credit, resolved to re-architect their view rendering layer to shrink the performance gap.

karmelapple• 7 years ago

That is indeed what happened, and Ember got some major performance enhancements as a result! Things like Glimmer were a result of this.

Chris_Newton3• 7 years ago

In short - the DOM was often used to store state. And this just isn't a very efficient approach.

By some people, sure, but separating state and business logic from presentation and rendering logic was a well-known idea many, many years before React was around.

I think the basic premise of the article here is correct. The important development with React that hadn’t previously been widely seen in front-end, JS-based web development wasn’t the virtual DOM, it was the declarative description of the rendered content — building it in absolute terms from the current state, not in relative terms from the current and previous state. The virtual DOM is a means to that end: it makes that approach fast enough that it can be used with acceptable performance for a lot of realistic applications.

This doesn’t change the fact that the declare-and-diff strategy is extremely expensive compared to actively observing only necessary changes in the underlying state and making only necessary local updates in the (real) DOM. In a typical web app, if there is such a thing, that might not matter very much. In more demanding cases, say when you’ve got tables with thousands of cells or you’re drawing a complicated diagram with SVG, it’s still all too easy to run into performance lag with any library that uses this strategy. Then you start using escape hatches like shouldComponentUpdate or using lifecycle methods to manipulate the (real) DOM directly rather than rendering through React, at which point you’re not really benefitting from React at all for that particular component (though of course you might still be benefitting from it for the other 90% of your UI code and incorporating the rest into the same overall design using those escape hatches might make sense in that situation).

oraphalous3• 7 years ago

By some people, sure, but separating state and business logic from presentation and rendering logic was a well-known idea many, many years before React was around.

My claim is that this isn't a good representation of the FE culture as a whole - even if there were islands of enlightment out there. Hell, just about all of the enterprise codebases I get contracted to work on are STILL do state management the old way.

So no - I don't agree the basic premise of the article is correct.

The important development with React that hadn’t previously been widely seen in front-end, JS-based web development wasn’t the virtual DOM, it was the declarative description of the rendered content — building it in absolute terms from the current state, not in relative terms from the current and previous state.

You are ignoring that fact that the VDOM was the imperative implementation they used under the hood to make the declarative api work. It's the VDOM that allowed them to take state management out of the DOM - and thus why they claimed that the VDOM was faster than the DOM.

Sure - if other folks are finding other implementation approaches that allow one to keep state out of the DOM in even better ways - that's great. That doesn't mean it wasn't reasonable at the time to identify the VDOM with that central innovation since there wasn't many other people doing it in other ways.

This doesn’t change the fact that the declare-and-diff strategy is extremely expensive compared to actively observing only necessary changes in the underlying state and making only necessary local updates in the (real) DOM.

I'm not arguing this case one way or another... I don't claim to know. The OP is certainly welcome by me to try to continue making that case. I think that's a good contribution to make.

I'm saying that OP could do this without crapping all over React's contribution - which tbh honest smells like a status move in order to obtain more market share. Wanting more market share is fine - but it should be enough to just compare the performance between the two to make that case. Don't straw man a "meme" to attack a competitor's status.

ng122• 7 years ago

but separating state and business logic from presentation and rendering logic

I think the parent was referring to something different. When you work directly with the DOM your _view_ logic is stateful. In the old days (jQuery, Bootstrap, Knockout, etc) you were spending a time simply keeping your data and your view in sync -- and god forbid you were trying to re-use some of that view logic in multiple places.

madeofpalk• 7 years ago

it was the declarative description of the rendered content

this is absolutely the 'revolution' that React brought front end centre - declarative UI's for the web. This is why people that enjoy working with react enjoy it so much, whether they know it or not.

addicted2• 7 years ago

This is how I remember things as well. The Virtual DOM was a huge improvement compared to other contemporary frameworks because it consolidated multiple changes into a single DOM operation.

For one thing, all the frameworks at the time we’re doing 2 way bindings. Which meant that the smallest change could end up triggering a bunch of computeds and observables, to the point where any change would trigger a bunch of re renders.

React bundled all of those into a single rerender. Further, and I may be mistaken about this, react helped dispel 2 way binding and show that 2 way binding was a performance and reasoning disaster. If that was the case, I’d suppose eliminatin g 2 way binding also likely played a large role in the performance improvements which may potentially have been incorrectly attributed to the VDom.

concerned_user2• 7 years ago

To me it was not only that as I didn't do games or highly interactive UI's where DOM updates would really matter but it freed me from the burden of ad-hoc updating with jquery as everybody was used to. Unless you had some framework or had invented ways to centrally store state chances are your code was all over the place.

I tried 2-way binding in ExtJS and it seemed to work well at first then I started adding more and more binds to the component and at certain point performance just tanked.

And it was after I started with React already so I just didn't bother to investigate, issue actually was some kind of loop being formed and things aborting due to hitting limits. Which I guess means I used it somewhat incorrectly but I never had that issue with react.

finchisko• 7 years ago

Well written. From my memory I remember situations trying to isolate cascade of rerenderes in backbonejs caused by multiple isolated event handlers. Also state used to problems, before state management libraries existed. And actually messenger (built in) was first app that was written in react, because it was plagued by several bugs, like not showing/resetting unread message count correctly...

hn_throwaway_99• 7 years ago

This is what I understood the claim that VDOMs are faster than the real DOM meant - and the article is pretty much eliding this detail.

I disagree with this. I think the major key insight and innovation with React, which this article fully acknowledges, is that it is much easier to think about declarative UI as solely a function of the current state without having to think about the transitions to arrive at that state, and, importantly, the virtual DOM lets you do that performantly.

In other words, to take the example from the article, it would be great if we could have an "onEveryStateChange() { document.body.innerHTML = renderMyApp(); }" function, but doing that would be much too slow because it would recreate the full, real DOM. Using the virtual DOM lets you write essentially the same code, but in a performant manner, and I think the article is clear on this fact.

I'm not familiar with Svelte, but the article has peaked my interest because it is making it sound like it lets you write declarative UI but without needing to do the full virtual DOM diffing.

oraphalous3• 7 years ago

See my reply to Chris_Newton's earlier response to my comment. :)

floatboth6• 7 years ago

lit-html also lets you write declarative UI without diffing (and use actual HTML tag syntax without any build tools): https://lit-html.polymer-project.org

and LitElement gives you a base class for Custom Elements that uses lit-html with Shadow DOM: https://lit-element.polymer-project.org

ben509• 7 years ago

Svelte is a compiler, so I think it's figuring out the possible state changes as part of compilation. Contrast with React where any component can return any elements at any time.

EB66• 7 years ago

What I think this article does very well is rebut the myth that the DOM is slow. The DOM is not slow -- on the contrary, it is very fast. What is slow is browser reflow, page refreshes, display calculations, etc. In web app development of yesteryear, browser reflow was typically triggered by poorly conceived manual DOM manipulations -- which gave birth to the myth that the DOM itself is slow.

Implementing a virtual DOM and VDOM diffing is just one way to manipulate the DOM more efficiently and intelligently. At my work, we've chosen a different path without the overhead and leaky abstraction of a virtual DOM.

We built our own component-based SPA framework and recently open sourced it ( https://github.com/ElliotNB/nimbly ). Each component must have a definition of what state mutations should trigger what portions of the component DOM (via CSS selectors) to refresh. There's no extra overhead for a VDOM and VDOM diffing at all. The only overhead is accrued ahead of time by the developers who must write a definition of how their component should update in response to state changes. When state does change, the framework bundles up the queued DOM changes between all components on the page, identifies/eliminates any redundant changes and refreshes the DOM in one go.

mruniverse2• 7 years ago

...seem to be trying to present React's claim of the VDOM faster than the DOM as some kind of toddler mistake.

It wasn't a toddler mistake, but it was repeated over and over to convince people to move to React.

jasonkester• 7 years ago

the DOM was often used to store state.

Every once in a while I'm reminded that I'm mostly disconnected from the way "most" people build things. Thanks for this insight. It finally explains why I hear people talking down about "jQuery developers", if that was something that people actually did.

But wow. I've been building javascript-heavy web stuff since the mid 90's and it had never occurred to me to do that. You have your object model, and each thing had a reference back to its DOM node and some methods to update itself if necessary. All jQuery did was make it less typing to initially grab the DOM node (or create it), and give you some shorthand for setting classes on them.

It also explains why people liked React, which has always seemed completely overcomplicated to me, but which probably simplified things a lot if you didn't ever have a proper place to keep your data model.

I can't imagine I was the only one who had things figured out back then, though. The idea you're talking about sounds pretty terrible.

cryptica• 7 years ago

complexity also kept me away from React. The main reason that it got popular is because it's by Facebook and they know how to manipulate people to use certain products over others (that's their entire business). There have always been simpler and cleaner alternatives.

If React was not by Facebook, it would not have gotten popular at all except as a 'cool hack/experiment' - Nobody would have seriously tried to incorporate it into a production application.

As soon as you scratch the surface, you understand that it's one of those tools that tries to take away complexity by adding complexity on top.

The story has gotten more complicated though because now React has so many components and there is all this conveninent tooling and boilerplate around it but still I would never choose it over VueJS.

Anything that comes out of Facebook is just pure manipulation.

sam0x177• 7 years ago

My god, it finally all makes sense!

And this is why I've been developing all my modern web applications as essentially an S3 bucket of flat HTML with vanilla javascript and jquery sprinkled in sitting behind cloudfront, connected to a fast API built of cloud functions / lambdas written in crystal/rust/etc. I use a custom routing system (I have S3 set up to respond with a 200 at the index in the event of a 404, so I have unlimited control over pathing from within my js logic) and I never let node touch anything at all. And I'm super happy about it. Never has it been easier to get things done. I don't have to fight with any system because there is no system to get in my way.

This gives me:

1. 2-4 second deploys

2. full control over assets pipeline (I call html-minifier, etc., manually in my build script)

3. literally serverless -- S3 or lambda would have to go down for there to be an issue (ignoring db)

4. caching at the edge for everything because of cloudfront

5. zero headaches because I don't have to do battle with node or react or anyone's stupid packages

6. (surprisingly) compatibility with googlebot! It turns out that the googlebot will index js-created content if it is immediate (loaded from a js file that is generated by a lambda and included in the document head tag as an external script, for example)

7. full control over routing, so I don't have to follow some opinionated system's rules and can actually implement the requirements the project manager asks me to implement without making technical excuses.

This does not give me:

1. A magical database that has perfect automatic horizontal scaling. Right now there is no magic bullet for that yet. Some come close but eschew the transactional part of ACID, making themselves basically useless for many applications.

And the parent post exactly matches my usage of jQuery :D

onion2k• 7 years ago

Bare in mind that most people using jQuery weren't writing JavaScript applications. They were writing backend-driven applications with jQuery enhancements, so there was no real concept of frontend 'state' that was separate to the DOM itself. If your frontend code needed to work with 'state' like form values or element attributes you had to read them, and because there could be multiple separate bits of code working with the same form or element you had to write values back to the DOM so the next bit of code had the correct 'state'.

The thing that changed to make frontend development improve dramatically was hash based routing with ajax, and later the introduction of the history API. That caused frontend development to have a need to retain state between 'pages', so then was a need to find a better way to store it than using DOM attributes.

radicalbyte• 7 years ago

That's just a symptom of Javascript being the entry-level language. You can be sort of productive without ever understanding how anything works.

Where these frameworks really come into their own is when you want to create reusable components and share them outside a team. jQuery did a good job with their plugins back in the day but Angular 2 (and React, and soon native Web Components) so that far better.

LoSboccacc• 7 years ago

I mean, I use to store data in my model and have the controller doing the rendering like anyone else that has some kind of experience on how ugly the opposite would become, but to outright demonize state within html seems quite misguided as well

there are things that are massively annoying to do without sneaking a data-uuid and data-type here and there, like drag&drop or specific customer requests - if anyone has ever written a cms, imagine the customer coming and telling "I want this product image in black and white" - if you had data attributes around, it's a css two liners, if you didn't because you're trapped into a either-or mindset, you have to also add the image-bw class on the rendering code with "customer ==" and "product ==" checks

WA• 7 years ago

If you’ve ever written a video game, I think it’s quite obvious as well. Video games have a main loop, take input, compute the next state, and then merely render the state to the screen. There is no point in manipulating the "UI". The data flow is very clear.

Of course, your game can run entirely "in memory" without a render function, which is basically what the game server does.

So I guess, many people have figured it out but didn’t transfer the knowledge from one area to the other.

Thanks for the insight, because I also always wondered what’s considered so new about React, although I have to admit that I still wrote my fair share of jQuery Spaghetti code.

Udik3• 7 years ago

Thanks for this insight. It finally explains why I hear people talking down about "jQuery developers", if that was something that people actually did.

Yes. It seems that most of the frameworks people are so enthusiastic about are invented just to prevent bad developers from writing their awful code. Which they end up doing anyway.

Anecdote: years ago, when he decided moving to Angular.js, my boss justified it with "following best practices". Then he proceeded to rewrite all the application components as controllers quering the context to decide how to behave, and talking to everything else through global events. Took me weeks to rewrite everything in a sane way. (Years later it was decided everything was too slow, and it was rewritten in good vanilla js, with a huge performance boost).

citeguised2• 7 years ago

When I got into front-end coming from Design, jQuery just got huge. Due to lack of senior front-end-devs in the company, my JS was this exact pile of jQuery with state in data-attributes. The things weren't really complex (Modals, Tabs, Form-Validation etc.), so it was never a problem.

Nowadays I'd still do simpler components this way. For anything heavier I'll grab React from the beginning, because of it's enforcement of modularity and state-management.

I'm interested in the way of architecting things you described, since I used to try similar ways, but always ended up state-in-dom. Would you have examples or literature on this?

ivanhoe• 7 years ago

To me the core problem wasn't with the data model, it's just that a declarative approach to binding events and reactive updates that knockout, vue, react, etc. provide reduces significantly the amount of repetitive, boilerplate code that you need to write. All that searching for nodes, adding handlers and callbacks, then updating the DOM when data model changes is now handled by frameworks. As you've said, this is not really jQuery vs React issue at all, jQuery just provides some nice cross-browser shortcuts. The main problem IMHO in jQuery era was in keeping the binding/callback logic separated from the html templates that define the dom structure itself. In big apps it made it difficult to follow which code binds to what part of UI, and there was no way to prevent someone from binding to the same node you're working on from some completely different part of the app. Now with declarative approach it's all in the same place and it's immediately clear what handlers you have in place on any html element, making refactoring much less stressful.

tomaskafka• 7 years ago

Few years ago I just did a 'react + redux in jquery' on a smaller project. A state of app was in a single object (= super easy debug, undo or save), any user action generates a state delta (which properties of state needs changing), and a central dispatcher updates the UI according to state changes. Quick and painless.

austincheney4• 7 years ago

was typically done when the virtual DOM approach was introduced.

Don't care and I am guessing you didn't read the article. Ignorance of the DOM does not redefine what it is. This is just as true for jQuery stupidity as it is for React virtual DOM nonsense. Fortunately, the DOM is defined in a standard specification so there is a document of truth that you can go read.

In short - the DOM was often used to store state. And this just isn't a very efficient approach.

Again, don't care. Other people's misuse and stupidity is their problem. That stupidity does not alter the technology specification.

If you really want to know what the DOM is I wrote a very brief summary with links to the specifications: https://prettydiff.com/2/guide/unrelated_dom.xhtml

delusional• 7 years ago

I still do some old school JQuery manipulations, and a lot of what kills you on the performance front is also the repeated manipulations of the same set of elements in the same frame. Often, you go in and change an element. Only to have another piece of javascript change it again. Each of those modifications then require a complete relayout of the page, that's when it gets expensive.

You could say that we should just optimize our JQuery, and you'd be right. We just don't have structured way of figuring out everything that touches a "component". (What is a component anyway, when it's all adhoc).

hopsoft• 7 years ago

the DOM was often used to store state. And this just isn't a very efficient approach.

StimulusJS is a modern approach that uses the DOM to manage state. In my experience it has proven to be quite simple and performant.

https://stimulusjs.org/handbook/managing-state

acdha• 7 years ago

yes if you architect things well then you could avoid a lot of these - but let's face it, front end developers weren't typically renown for their application architecture skills. … This is what I understood the claim that VDOMs are faster than the real DOM meant - and the article is pretty much eliding this detail.

I agree that a large part of the problem is the lack of proper architecture and general poor quality of practice but that’s also a problem for the distinction which you’re attempting to draw. I think the core React team likely meant what you meant but the community’s love of both fads and crapping on whatever isn’t new and shiny meant that nuance was deeply buried under the “it’s go-faster magic from Facebook!!!” marketing train.

I remember having absolutely surreal experiences where it was like “why are you saying it’s faster? Here’s a benchmark showing it’s 5 orders of magnitude slower.” “It uses a virtual DOM” “I know, but don’t you have a benchmark where it’s actually faster?” “You just don’t get it”.

I do think React helped bring some improvements around architecture but I think an under-appreciated part of that was that since it required a full compiler toolchain, 100% of projects could use the latest JavaScript features (notably ES6 classes and arrow functions), data structures, modules rather than rewriting everything, etc. which noticeably reduced the number of complex things people had to get right, tune, and reason about.

ljm• 7 years ago

I love how many people there are in this thread that somehow avoided the jQuery hell a lot of us battled against.

I was involved in that, mostly from when my paycheque involved throwing together websites in Drupal 6. Holding that architecture together was trouble enough without having to also care about the frontend, we were only scripting it. The idea of the HTML being considered an 'app' was utterly alien to me and my colleagues at that time.

I fondly remember the short period of time where we had post after post attempting to explain what a closure is, because for most of the authors back then the concept of a function pulling outside variables into its scope was utterly alien to us. Even now this practical meme persists[0].

Ten years later and I find closures more intuitive than half the stuff we've concocted in OOP land.

More than that, jQuery was a means to an end and to shove low-effort animation and UI into an app to make it look snazzy and 'Web 2.0' like (glass effect banners, drop shadows and all). If it wasn't jQuery it was script.aculo.us.

Then we got Backbone and Coffeescript at around the same time, by which time I was a Ruby dev. Backbone contributed to a fundamental shift in how we build a frontend, and we had Knockout, Sencha, ExtJS, etc. following along. And then the concept of 'comet' (keeping an HTTP connection alive for long polling) and MeteorJS.

The impact of React and its concept of the VDOM has been phenomenal. It may be overhead as the Svelte authors say, but the experience of working with React, and any similar library in the ecosystem, is a boon to anyone who wants to do serious work in the browser. Without being hyperbolic this feels like the legacy of smalltalk: programming in a dynamic environment, only you're not actually aware that you are.

There has to be a fantastic retrospective on the progression of JS since that initial ten-day genesis.

[0] https://medium.com/dailyjs/i-never-understood-javascript-clo...

Klonoar2• 7 years ago

Not just jQuery... we had some crazy times with Dojo, MooTools, and so on. Closures and "this" being screwy (IMO) led to junior developers spending an insane amount of effort shoving things into DOM elements because it was a free global store that you could inspect and work with.

The VDOM is cool, but React (& co's) appeal is the streamlined development tooling, approaches, and ecosystem where there's a mostly agreed upon way to do things.

I fondly remember the short period of time where we had post after post attempting to explain what a closure is, because for most of the authors back then the concept of a function pulling outside variables into its scope was utterly alien to us. Even now this practical meme persists[0].

My favorite was actually when we needed a groundswell movement to make people realize that $() wasn't a variable, but a function call, and for complex selectors (before querySelectorAll, when Sizzle was a far more complex beast) you really wanted to cache it. Or, getting people to stop attaching event handlers to every row in a 10k row table, and to just match the click to the row once.

It really does feel like people have forgotten just how rough the gap was back then.

For real though. I feel comfortable building something in VanillaJS... e.g, building up a fragment before shoving it into the DOM, architecting how updates are applied, etc. This is all stuff that was hard learned, and became easier the more I stepped outside JS later on. I would in no way want a junior trying to do this without learning the better practices found in React - _not_ because they need the crutch, but because I learned those some lifecycle methods and such from Cocoa/UIKit and you need a frame of reference to internalize it all.

edem• 7 years ago

React has nothing to do with this. They just took an idea as old as Windows 1.0 and applied it to web development.

stolsvik• 7 years ago

Why don't the credit of "changing the culture of how we thought about state management on the frontend" go to AngularJS? At least Angular is what changed it for me, and it is the oldest of them.

Klonoar2• 7 years ago

Because Angular wasn't the first? Angular 1.0 also left an eternally bad taste in many peoples mouths.

jkoudys• 7 years ago

Absolutely, and it ignores that React has never been designed purely to render into the browser DOM as defined by the w3. The browser's DOM is simply one target, though certainly the most popular one. I use React every day for building other things: xml targets like PDFs, word docs, and SVGs, raw strings, canvases, native, etc. Far from a toddler's mistake, the team was well aware of this from the start, and the shift from everything in the 'react' package to splitting out 'react-dom' is clear evidence of this.

Components are a very powerful concept that goes way beyond the common scenario of building a web page and updating it with some data.

EGreg2• 7 years ago

I have always said:

Angular is diffing the model

React is diffing the view

That’s all. Better to just skip the diffing usually, and grab references to elements and update them when certain events happen. It’s really ok!

quickthrower2• 7 years ago

The problem is spaghetti! You have something in the Dom and you might not know what can or has updated it or why...

EGreg2• 7 years ago

When everything is event based, you know. You can trivially even record the entire call stack on an object attached to the DOM element, when your framework is in debug mode. You can see the whole history of call stacks if you so choose.

And there is no waste, either.

floatboth6• 7 years ago

https://lit-element.polymer-project.org

lit-html essentially grabs references to elements automatically when parsing a template. You get react-like rendering without any diffing! And does not require build tools.

smith-kyle• 7 years ago

Here, we're generating a new array of virtual <li> elements — each with their own inline event handler — on every state change, regardless of whether props.items has changed. Unless you're unhealthily obsessed with performance, you're not going to optimise that.

React makes it pretty trivial to prevent rerenders when props have not changed

pier253• 7 years ago

After years of doing mostly React and Vue SPAs I've never experienced a performance problem.

The metrics of Svelte that interest me more are lines of code and bundle size, both in which it excels.

Here is an article that compares the exact same project called RealWorld written in a number of front end libraries/frameworks.

https://medium.freecodecamp.org/a-realworld-comparison-of-fr...

Here is the main repo for the RealWorld project for front and backend:

https://github.com/gothinkster/realworld

pan_43212• 7 years ago

Same experience here but with React and Angular (2+). No real world differences that can be observed by an average user in the average app.

The choice has to be made by ecosystem, programming style, etc.

React as a library offers not enough for me personally. Angular is too heavy on concepts. Vue seems to hit the sweet spot?

underwater2• 7 years ago

The original promise of React was that you could re-render your entire app on every single state change without worrying about performance. In practice, I don't think that's turned out to be accurate. If it was, there'd be no need for optimisations like shouldComponentUpdate (which is a way of telling React when it can safely skip a component).

It's shouldComponentUpdate(), not shouldDOMUpdate(). Even if DOM operations are direct, or the virtual DOM is infinitely fast, there are plenty of situations where you want to avoid running application code on every update.

Some frameworks use data binding to track if a component update is necessary. This is what Svelte does, but because there is no explicit checks they have some weird conventions around annotating certain bound values:

    <script>
        export let num;
        $: squared = num * num;
    </script>

React just happens to implement this behaviour different: it assumes a component needs updating unless the shouldComponentUpdate() hook says otherwise. The advantage (ironically) is that React is "just JavaScript", whereas Svelte needs a compiler that can instrument the code.

This design decision shouldn't be confusing to the author; I assume he would have made this design decision consciously?

JMTQp8lwXL5• 7 years ago

Well-written React code shouldn't need to leverage the shouldComponentUpdate API. The application structure would be off, if that's the case.

underwater2• 7 years ago

A React component can do arbitrary, computationally expensive, logic inside components. React gives you the ability to memoize that work. Without shouldComponentUpdate developers would need to hand roll a caching layer or stick computed values in a store.

rayiner• 7 years ago

Only ever having used MFC and Swing, this seems odd to me. A diff of the entire DOM on every state change? You never see anything like that in native toolkits. ELI5: What problem is that solving?

adamnemecek• 7 years ago

Makes programming somewhat easier and also batches layouts.

Tehdasi• 7 years ago

The problem it's solving is the DOM being unsuited to writing the kind of applications that MFC and Swing are used for writing. (which, for the web, is a SPA)

andrekandre• 7 years ago

isn’t this pointing to more of a fundamental problem with how browsers/html/document model are designed/implemented than anything else?

html was originally a document format, not an app framework, and i think all of these frameworks (large and small) are just workarounds when what we really need is a fundamental re-imagining of what the browser should/could be.

sometimes i wonder if alan kay was right when he said the browser should have been basically just byte-code interpreter[1]...

[1] http://www.drdobbs.com/architecture-and-design/interview-wit...

tptacek• 7 years ago

You write your UI declaratively, in almost straight-line code, and never "update" anything in the UI itself. It's significantly easier to write.

nojvek• 7 years ago

The ideas of svelte are great. It reminds me of snabbdom thunks and inferno blueprints. If you know the view code ahead of time, you could do plenty of perf optimizations since you exactly what changes and what to react to.

But sometimes I dynamically generate vdom nodes. Like markdown to vdom. There vdom shines. It’s a simple elegant idea.

I think svelte is exaggerating a bit.

React and vdom family of libraries are great. Svelte is great too. Not mutually exclusive.

Someone should write a Babel jsx transpiler that does svelte like compile time optimizations for react. At the same time still allows dynamic runtime diffing if needed.

No reason why we can’t have best of both worlds.

acemarke4• 7 years ago

The React team (and other parts of Facebook) _was_ working on a project along those lines called "Prepack":

https://prepack.io/

I think work on that has slowed for the time being, but it's got some interesting possibilities.

fnordsensei2• 7 years ago

I do this with React all the time as well, though via ClojureScript and Re-frame[1], in which nodes are represented as plain Clojure data structures.

E.g., send an article from the server, formatted in EDN/Hiccup[2][3]. Insert it into a component in the frontend, and it's converted to VDOM nodes. No further logic or conversion required.

[1] https://github.com/Day8/re-frame

[2] https://github.com/edn-format/edn

[3] https://github.com/weavejester/hiccup/wiki/Syntax

palerdot• 7 years ago

I just noticed that Reframe README is very amusing and wickedly hilarious in some parts. It is very refreshing to read compared to other bland/formal/techinical READMEs ... Maybe in future I will try and see if using Reframe itself is joyful like its Readme ...

gigatexal• 7 years ago

Seems plausible to me but the examples don’t work on mobile (iPhone iOS 12.3 with safari) nor is the layout mobile friendly at least when render in portrait modes on my phone.

kyberias• 7 years ago

Please God let me never get into a situation where I need use these frameworks.

franciscop• 7 years ago

Seems like just an ad for Svelte, and fairly FUD-ish on that. React will warn you by default when doing that exact example, asking you to provide a key to the `<li>` to avoid re-rendering it unnecesarily. Instead, this states "Unless you're unhealthily obsessed with performance, you're not going to optimise that."

lenkite2• 7 years ago

Personally, I find modern template based approaches like lit-html, hyperhtml/lighterhtml better and faster. And also being far, far smaller. Throw in a CSS framework like bulma or tailwind-css and you are good to go at a smaller footprint and better performance.

floatboth6• 7 years ago

And lit works without any build tools!

nsonha5• 7 years ago

the main reason templates are bad is not that it needs a build step, it's more about being non-standard (a problem lit-html doesn't have), and not statically analyzable (think typescript's jsx), which lit-html doesn't solve.

Sawamara4• 7 years ago

I was running some quite complex UI systems in several of my projects with vanillaJS, cached DOM elements, all that jazz. Nothing like VDOM. Then eventually, it started to finally bog me down. Like rendering an inventory in an RPG system where you can buy stuff from the vendors: I started to get dissatisfied with change operations that lasted upwards to 2-3ms in a bad day. Then I started caching even more DOM elements, and started to build local data structures to see which was rendered last,and to what, to avoid rerendering everything, and to optimize to the change-based render only.

A few weeks of this, and it dawned on me that had I needed to generalize my solution, I would have arrived at the exacty same model that hyperscript does for its diffing, and something similar to whats underneath React's diffing method (or Preact since I prefer that, but they share the API).

So yeah, virtual dom is just a more clever and straightforward way to map your state to the dom, identifyng exactly where the changes happened, and only updating those nodes, instead of doing any queries towards the dom api (costly, can cause rerender,like when checking for bounding boxes, etc).

It IS more useful because you no longer need to maintain a hyper-specific update function per project and manuallí created/maintained differs.

Mikushi• 7 years ago

Not to be grating but your problem sounds more like using the wrong tool for the job. DOM is not made to render video game UI, it is a bad tool to do so as you discovered yourself.

Sawamara4• 7 years ago

Tell that to Guild Wars 2. (https://mithril.js.org/framework-comparison.html)

But putting even those games aside which use webview for UI, there are still video games made inside the browser, and for those, having sub-1ms rerender times with React is perfectly reasonable. We could get into immediate mode vs retained mode debates right about here, but that is a slightly different topic :D

vfc1• 7 years ago

Angular also works in a somewhat similar way, there is also no virtual DOM.

Instead, the modern compiler is used at build time to generate what looks like a change detection function and a DOM update function per component.

These functions will detect changes and update the DOM in an optimal way without any DOM diffing.

However, because Javascript objects by default are mutable, after each browser event Angular in its default change detection mode has to check all the template expressions in all the components for changes, because the browser event might have potentially triggered changes in any part of the component tree.

If we want to introduce some restrictions and make the data immutable, then we can check only the components that received new data by using OnPush change detection, and even bypass whole branches of the component tree.

This is the current state of things, for the near future Angular is having it's internals rebuilt in a project called Ivy.

One of the main goals of Icy is to implement a principle called component locality.

Ivy aims at getting to a point where if we change only one component, we only have to recompile that component and not the whole application.

I think the article puts the focus on the wrong thing. The current change detection and DOM update mechanisms made available by modern frameworks virtual DOM or not are more than fast enough for users to notice, including on mobile and once the application is started.

What we need is ways to ship less code to the browser, because that extra payload makes a huge difference in application startup time.

2T1Qka0rEiPr• 7 years ago

Thanks for the write up - it's a very succinct explanation of how Angular works in comparison.

I found the original article to be a really good read, and the Svelte approach in general seems rather neat. I do however find that in this current front-end framework sphere, there seems to be a huge amount of religiosity and one-upping going on.

I hear routinely (on-line and off) developers vocalising some anti-[jQuery,angular,etc.] mantra, which to be honest saddens me. Yes the jQuery approach was flawed in so many ways in comparison to the modern frameworks. Yes Angular 1.x was flawed in many ways compared to what we have on offer today. But those tools were still great improvements on what we had before (for anyone who knew the DOM-API standardisation nightmares pre-jQuery, or state management / testability woes pre angular/react).

Svelte may take us down the next path, and if it allows us to produce better, smaller, more testable code then it has my full backing. But I think as a community we need to strive to be less polarising - from my perspective its likely to be mostly reductive, and lead to even more JavaScript fatigue.

ralphstodomingo3• 7 years ago

I would guess this is partly because the modern front-end framework leaderboard is a zero-sum game: you can't possibly be sane to use two or more different frameworks for most of your day-to-day work. Maybe you have one for work and one for hobby development, but that's about it. I'd be torn to remember quirks of both React and Vue, for example.

And thus you see it in discussions that people feel the need to pull one down to put their preferred one on the top. We know what happens to a library without a critical mass of adopters: they lose contributors, which in turn reduces the rate of growth, and in turn, the quality of the library over time.

Which is kinda sad. A lot of work goes into these frameworks that I really respect. There's no logical rule that says these new ideas completely succeed their precedents. I wonder what needs to be done to get us over that JS fatigue.

fauigerzigerk2• 7 years ago

The current change detection and DOM update mechanisms made available by modern frameworks virtual DOM or not are more than fast enough for users to notice, including on mobile and once the application is started. What we need is ways to ship less code to the browser [...]

I wonder how it affects battery usage though. Downloading the code doesn't happen as often as running the code, if it's really an app and not content needlessly packaged as an app.

beders2• 7 years ago

It is simply mind-boggling how much effort the JS community has put into working around the performance properties of a document layout engine to make it 'interactive' and 'responsive'.

With only 3 major rendering engines left standing, where is the concerted push to turn these document renders into general purpose, fast, desktop-quality rendering engines?

Back to Svelte vs. React vs. Reagent vs. Vue.JS vs. Angular vs. (insert framework-of-the-month-here)

One common theme seems to be: Run code to manipulate a tree-like data structure (DOM) efficiently. This obviously needs to become: Submit data to the rendering engine to manipulate the tree-like structure. (and in a way .innerHtml is doing that for a sub-tree, but is not suitable for general-purpose tree manipulation)

writepub2• 7 years ago

where is the concerted push to turn these document renders into general purpose, fast, desktop-quality rendering engines

The DOM is fast enough for desktop apps @60 or even 90 frames per second, especially of you follow best practices (no framework required)

beders2• 7 years ago

If it is fast enough, why is everyone optimizing?

vaibhavkul• 7 years ago

This is why I find the flutter approach interesting: it has its own rendering engine. I would guess it is optimized for this sort of thing (dynamically rendering UI elements) without depending on an external entity (DOM).

Maybe there is a future where flutter style renderers become standard, have a container like a browser (to avoid the entire runtime baggage when it's deployed), and people target it instead of the DOM? This gives best of both worlds--write apps in a declarative way, without the need of any external "optimizing" framework.

ozten• 7 years ago

Does Flutter bridge accessibility APIs?

_0w8t2• 7 years ago

Direct manipulations of DOM are expensive. It is vastly more cheaper to create or update JS object than create or manipulate DOM node. So the claim that VirtualDom is always an overhead is not true. The diff algorithm can give a set of DOM operations that are less expensive than typical sequence of manual mutations. So virtual DOM can be faster if savings from less DOM operations are bigger than extra JS work.

Surely carefully crafted direct DOM mutations will be the fastest approach, but it typically leads to hard to maintain code.

kanonk• 7 years ago

Seems like the author - and a lot of people here - have failed to realize this. This is the real benefit in DOM manipulations with VDOM.

nsonha5• 7 years ago

the author and others did not avocate manual DOM manipulations. He wrote a framework that can generate optimal DOM manipulation code without the need of a virtual DOM.

atan6• 7 years ago

I'm not sure you understood the article. The Svelte compiler does in fact generate code that performs "carefully crafted direct DOM mutations," though it is not hard to maintain, because the compiler handles it. Given code that already knows exactly which DOM updates to make, virtual DOM would indeed be pure overhead.

_0w8t2• 7 years ago

Typical React code does not know which updates to make. It always builds the Virtual DOM from scratch as is was the first time. It is the diff algorithm then figures out the set of changes.

If code knows which updates to make, it essentially embeds a particular form of the diff algorithm. That inevitably leads to more code to write as besides the initial construction of DOM one has to track changes. And such manual tracking is not necessary optimal as the diff algorithm has a global picture and can target the globally optimally set of mutations, while manual in-component tracking optimizes for a particular component.

_pdp_• 7 years ago

Writing some basic apps with vanila js is fine. But I think we use browsers for much more than this these days. For that we do need this level of overhead because DOM is just too simple for the task.

DigitalSea• 7 years ago

This is why I use Aurelia. It's a Javascript framework many here have probably never heard of or used, it debuted in 2015 and I have been working with it for four years now. Sadly Aurelia debuted at the height of the React hype and soon after, Vue hype.

Rob Eisenberg (the man in charge of the Aurelia project) had the right idea straight out of the gate. A reactive binding and observation system that worked like a virtual DOM (isolated specific non-destructive DOM operations) without the need for an actual virtual DOM. Which allows you to use any third-party library without worrying about compatibility or timing issues with the UI.

This is one area where React falters, at least when I used it. third party libraries clashed with the virtual DOM. When you start introducing abstractions to solve imaginary problems caused by improperly written code (the myth of the DOM being slow) you introduce issues you have to battle later on as your application scales.

Tobani• 7 years ago

The default behavior for javascript interacting with the DOM is incredibly slow once the page gets complicated enough. I've certainly seen it first-hand. This may not be a problem you have, and indeed maybe not everybody needs react. But the problems things like react/vue/whatever solve (correctly or not) isn't imaginary.

baybal2• 7 years ago

This is what I use when I need to do very minimalistic UI and feel that bringing Vue/React is an overkill https://github.com/adamhaile/S - reactivity without DOM superglue to it.

amelius• 7 years ago

I think most people in this thread focus too much on the vdom, and miss the important part of the post:

Unlike traditional UI frameworks, Svelte is a compiler that knows at build time how things could change in your app, rather than waiting to do the work at run time.

keepsmiling• 7 years ago

hello very great article. i've been working as a developer for over 20 years now and have to say that do more experience you have on fewer and fewer trains you jump on what should not be heisen that i don't look at frameworks anymore but to describe it it's just often too much of a good thing. every framework has good pages but you should keep it simple. ciao

patsplat• 7 years ago

Double buffering is a standard rendering technique. It might be pure overhead but it won't look that way.

peterbraden• 7 years ago

It's not double buffering - double buffering is just calculation into memory and then a memory update.

VDOM is essentially calculating the buffer once in a scripting language, and then again in a fast way if necessary.

Despite that, it may still be a good idea.

gr__or• 7 years ago

I wrote about this a while ago, and now I wonder whether I read this post at some point in the past. Anyway, here it is:

https://dflate.io/svelte-react-reconciliation

snewcomer24• 7 years ago

Here are some measurements of vdom vs plain ol DOM manipulation - https://github.com/patrick-steele-idem/morphdom#benchmarks

Virtual DOM is pure overhead (2018)

Related Stories