Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Virtual DOM is pure overhead (2018)

svelte.dev

Post reply on HN
Print view View original

61–70 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#61

Post by namelosw »

Lowkeyloki wrote: post #11

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,…

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

Re: Virtual DOM is pure overhead (2018)

#62

Post by smith-kyle »

> Here, we're generating a new array of virtual 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

Re: Virtual DOM is pure overhead (2018)

#63

Post by rahimnathwani »

revskill wrote: post #38

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 lib…

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

Re: Virtual DOM is pure overhead (2018)

#64

Post by toasterlovin »

oraphalous wrote: post #54

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…

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.

Re: Virtual DOM is pure overhead (2018)

#65

Post by Chris_Newton »

oraphalous wrote: post #54

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…

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

Re: Virtual DOM is pure overhead (2018)

#66

Post by pier25 »

kevingadd wrote: post #4

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 tro…

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.

Re: Virtual DOM is pure overhead (2018)

#67

Post by namelosw »

jordache wrote: post #27
Lowkeyloki wrote: post #11

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,…

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

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

Re: Virtual DOM is pure overhead (2018)

#68

Post by ec109685 »

spankalee wrote: post #45
ec109685 wrote: post #35

Earlier quoted context omitted.

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.

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` ` is perfectly fine.

Ah, thanks for pointing that out.

Re: Virtual DOM is pure overhead (2018)

#69

Post by pier25 »

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

Re: Virtual DOM is pure overhead (2018)

#70

Post by kevingadd »

mantap wrote: post #17
kevingadd wrote: post #4

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 tro…

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.

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