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

221–230 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#221

Post by throwaway894345 »

SquareWheel wrote: post #207
throwaway894345 wrote: post #127

Earlier quoted context omitted.

> Javascript was a meme language, but it was easy to use and highly accessible. Now its everywhere, in everything, including places it has no business being. JavaScript is the wrong example. It didn't succeed on merit, but because it was the sole language available for the web platform for the entire history of the web until recently and even now it enjoys significant "unfair" advantages (browsers only expose DOM API…

While never widely adopted, VBScript was able to be ran in script tags in Internet Explorer.

I fully believe that JS is better than VBScript, but it's also possible that many other factors contributed to JS's triumph over VBScript. In whichever case, this is pretty weak evidence for the claim "JS won its popularity relative to other languages by merit" (presumably you weren't intending it to be strong evidence).

Re: Virtual DOM is pure overhead (2018)

#222

Post by recursivedoubts »

fokinsean wrote: post #152
recursivedoubts wrote: post #76

Earlier quoted context omitted.

You might want to take a look at the HAT stack: https://htmx.org - server interactions in HTML https://alpinejs.dev - small front end tweaks in your HTML https://tailwindcss.com - styling in your HTML This is pretty a simple stack that keeps everything in one file (for something I am calling Locality of Behavior[1]) and all of them are dependency free. full disclosure: I am the author of htmx [1] - https://htmx.org/e…

HTMX has been on my radar for a little while. Do you have a starter template with all of these hooked together? Or an example repo?

There are example projects in a bunch of different back ends available here:

https://htmx.org/server-examples/

Re: Virtual DOM is pure overhead (2018)

#223

Post by lhorie »

darepublic wrote: post #153
mumblemumble wrote: post #124

Earlier quoted context omitted.

> React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim. My impression is that it's the kind of claim that's actually true in general, despite being false in all the particulars. Like, every step of the way, yes, virtual DOM adds extra steps to the process, and they have a cost. But, in the big picture, if you'…

no its not wrong to criticize the culture in web development of salivating over every new framework. And rebuilding company code in hyped up framework X without pausing to understand the problem you're trying to solve and why the current glob of code is so damn buggy. I see experienced web devs, if not fall for this mistake themselves, happily prop it up to management every damn day across many companies. I've read t…

> reaches for a complicated library way to do it

This is neither here nor there. Some people write awful React code too.

> having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer

I mean, knowing how to do it is good and all, but knowing how to do it well is a rare skill. There's a ton of random performance gotchas to be aware of (like, reading a property in the middle of a bunch of writes causing double repaints) and frameworks do consistently apply optimizations that you as a regular dev would probably not ever think of (sorting optimizations being some of the least trivial ones).

Re: Virtual DOM is pure overhead (2018)

#224

Post by thunderbong »

I've commented on Svelte before [0]. Adding the same comment here -

>> I've worked on multiple modern JS frameworks and Svelte is the closest I can get to mapping my mental model of how a web page works (HTML, CSS, JS) with the framework.

Actually, I should correct myself - yes, the breakdown in terms of technology is HTML, CSS, JS but the underlying abstraction is actually - structure, presentation and functionality.

This is where, imho, Svelte really shines. It helps you to map your mental model of structure, presentation and functionality to it's corresponding implementation of HTML, CSS, JS with a sprinkle of syntactic sugar. This goes way far in keeping the code easy to understand and maintainable in my opinion.

[0]: https://news.ycombinator.com/item?id=26723214

Re: Virtual DOM is pure overhead (2018)

#225

Post by spankalee »

I work on the Lit team at Google. A colleague there who went on to work on Flutter's VDOM-like system once said that React traded off CPU cycles for developer ergonomics and conceptual simplicity.

A VDOM tree represents far more DOM states than a template will ever be put in, so materializing VDOM and diffing are absolutely pure overhead compared to the system knowing ahead of time what might change. With VDOM you repeatedly compare many nodes that will never show a diff, and that's just waste.

VDOM brought three important things to the table, initially paid for by that overhead: * Template as values. JSX expressions produce JS values, and this is allows a functional programming approach to UI. * Expressions and control flow in JS. This shrunk the domain of the template DSL to just the component nodes, and reused knowledge and machinery of JS. Theoretically that leads to faster and smaller templating. * One-way data flow. This is a result of the first two items, but important on its own. Two way binding is nice sugar for some situations, but it makes it hard to reason about the state a template is in.

Those are really great aspects of the VDOM approach (for a class of programmers, markup based templates are great for others).

So the challenge to me had been to preserve those features, actually deliver on the smaller and faster part, and reduce the CPU overhead. That can be done with compiler-first systems like Svelte, but I think we get just as faster or faster, and as small or smaller with a pure runtime approach based on template literals, like we have with lit-html.

Template literals let us describe the static and dynamic parts of a template separately, so there's no VDOM overhead. We don't compare the output of template expressions, we compare the inputs to the dynamic bindings. It's often an order-of-magnitude less diffing work, and approaches the point where the required DOM operations are the limiting factor. So we get low-CPU overhead, templates as expressions, logic in JS, and one-way-bindings, with no compiler. I really think this is the best of both conceptual simplicity and overhead - preserving much of the VDOM model, but doing it faster.

Re: Virtual DOM is pure overhead (2018)

#226

Post by mbgerring »

protonimitate wrote: post #74
jchw wrote: post #41

Svelte does something interesting in an innovative way. However, this article is overly focused on just one element of how React works. If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Their alternative is to add more complex compile…

> React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. React, imo, is about the programming experience. "Thinking in React" is a lot more than just VDOM, and the benefit of "thinking in react" is about the developer experience not the pure benchmarkable output. Svelte has been around for a few years now - and I've yet to se…

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

One of the lead developers of Svelte uses it at the New York Times on some of their high traffic interactive data visualization pages, including their COVID charts.

Re: Virtual DOM is pure overhead (2018)

#227

Post by SquareWheel »

throwaway894345 wrote: post #221
SquareWheel wrote: post #207

Earlier quoted context omitted.

While never widely adopted, VBScript was able to be ran in script tags in Internet Explorer.

I fully believe that JS is better than VBScript, but it's also possible that many other factors contributed to JS's triumph over VBScript. In whichever case, this is pretty weak evidence for the claim "JS won its popularity relative to other languages by merit" (presumably you weren't intending it to be strong evidence).

I was only commenting on the claim that JavaScript was the "sole language available for the web platform".

Re: Virtual DOM is pure overhead (2018)

#228

Post by cuddlecake »

rendall wrote: post #218
cuddlecake wrote: post #213

Earlier quoted context omitted.

It's kind of gatekeepy insisting on styled components being of lower quality than using pure CSS. Styled Components serves a specialized purpose of styling things on the web. Maybe less elegant or performant in some respect than pure CSS, but with trade offs that some development teams will happily take. I also hate the sentiment, that software development needs to adhere to some notion of purity or divine elegance.…

Use styled components if they suit your use case, by all means. But if that use case is We don't have to learn CSS because we can just not think about it with this nifty innovation then the use case is horrific.

Eh, I'd say it's a valid use case as any.

Maybe someone just didn't have the time confidence or interest to learn CSS. Maybe it's as simple as doing what you want, doing what you can afford to do, etc.

What I don't like is the negative framing of this choice. Bad things will be built, regardless of the underlying tools. Grandparent claimed that using Frameworks results in bad practices. I claim that shaming people and questioning their choices (whether they made them consciously or unconsciously) is a bad practice.

Re: Virtual DOM is pure overhead (2018)

#229

Post by lhorie »

spankalee wrote: post #225

I work on the Lit team at Google. A colleague there who went on to work on Flutter's VDOM-like system once said that React traded off CPU cycles for developer ergonomics and conceptual simplicity. A VDOM tree represents far more DOM states than a template will ever be put in, so materializing VDOM and diffing are absolutely pure overhead compared to the system knowing ahead of time what might change. With VDOM you re…

> I really think this is the best of both

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

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

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

Re: Virtual DOM is pure overhead (2018)

#230

Post by rendall »

cuddlecake wrote: post #228
rendall wrote: post #218

Earlier quoted context omitted.

Use styled components if they suit your use case, by all means. But if that use case is We don't have to learn CSS because we can just not think about it with this nifty innovation then the use case is horrific.

Eh, I'd say it's a valid use case as any. Maybe someone just didn't have the time confidence or interest to learn CSS. Maybe it's as simple as doing what you want, doing what you can afford to do, etc. What I don't like is the negative framing of this choice. Bad things will be built, regardless of the underlying tools. Grandparent claimed that using Frameworks results in bad practices. I claim that shaming people an…

I dunno. Maybe. How about the practice of removing a test that fails? Literally, test fails, remove it, problem solved. Ship it. Sure there are build warnings, but CI isn't complaining, so..? Is that a valid use case? If your team member did that, you'd be cool-and-the-gang, easy-like-sunday-morning, shaming-is-the-real-shame?
Post reply on HN