Live data from Hacker News

Virtual DOM is pure overhead (2018)

svelte.dev

71–80 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#71
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…

> this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman” The part that I think the article misses is that VDOM is just an implementation detail of React. No one actually really cares about it, and its not the reason why people use React.

That’s the weird part. I agree with you, but then at the end, they say the important part:

> It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development.

I find this bewildering because it makes me feel like the article does actually understand React. It realizes it was faster than frameworks it initially competed against, it understands that virtual DOM is a means to an end. But then at the same time it is classified as a meme that only wins in performance against things nobody would ever do.

In a way, writing it like this makes it harder to critique.

Re: Virtual DOM is pure overhead (2018)

#72

I’m not a JS frameworks expert, too much churn to keep up. I learned Angular 2+ a few years ago and found it to be a bit heavy weight. Thinking of learning Vue 3 now. Svelte looks interesting though. What I am hoping for long term is that the JS/CSS/HTML5 stack will be mature enough and have enough batteries included that I can just write apps using the “standard library” with minimal external libraries. Is that the…

I used React for 3 years and I'm using Angular for 2 years now; Angular is super heavy handed and gets in your way

Re: Virtual DOM is pure overhead (2018)

#73

I read this long ago and I love Rich Harris and I think he is a super smart guy. But the problem as I see it is that he focuses on VDOM as just a performance hedge. As browsers improve (or rather as the market consolidates on WebKit variants as is happening now), then certain DOM operations that took substantially longer on average on IE or Edge vs. Chrome will no longer be as much of a problem, which is my view of w…

“ If you code to just the DOM - that is is where you will stay. Forever.”

Svelte native exists…

The VDOM which mirrors the document DOM is an implementation detail of React, as something sitting between the actual DOM, and the VDOM fragment returned by a React view. It’s true that if the document DOM gets fast enough, the mirroring VDOM could go away, but some diffing algorithm would still have to reconcile the document DOM with whatever fragment is returned from a view.

I think one of the realisations of Svelte is that rather than returning arbitrary runtime generated DOM fragments from views, it is better to have the view implemented by a template that a compiler can understand and manipulate at compile-time. Here we trade off some expressivity (run-time generated DOM) for the ability to do much much more at compile time - I think this is the real point that should be being made in the article.

Re: Virtual DOM is pure overhead (2018)

#74
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 see/hear about an application built with Svelte at scale.

The reason I think React works so well and is so popular atm is because it works just as well at a small scale as it does on a team with 5-6 active contributors (in my experience, at least).

That isn't to say that Svelte can't deliver the same wonderful experience at scale, I've just yet to see a truly shining example of it.

I may also be in the minority, but performance of front end frameworks is near the bottom of my evaluation checklist.

I've used svelte for some one off personal projects, just to get a feel. And it's fine but nothing about has convinced me to lead a project/team towards picking that over React, Vue, or even some SSR framework.

Re: Virtual DOM is pure overhead (2018)

#75
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…

> this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman” The part that I think the article misses is that VDOM is just an implementation detail of React. No one actually really cares about it, and its not the reason why people use React.

> The part that I think the article misses

The article is about VDOM and nothing else. It does not "miss" the part about why react is popular, it simply does not discuss it.

Re: Virtual DOM is pure overhead (2018)

#76

I’m not a JS frameworks expert, too much churn to keep up. I learned Angular 2+ a few years ago and found it to be a bit heavy weight. Thinking of learning Vue 3 now. Svelte looks interesting though. What I am hoping for long term is that the JS/CSS/HTML5 stack will be mature enough and have enough batteries included that I can just write apps using the “standard library” with minimal external libraries. Is that the…

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/essays/locality-of-behaviour/

Re: Virtual DOM is pure overhead (2018)

#77
The most important part of Svelte, to me, is that it allows me to write web applications in the most elegant possible way. The compiler first approach means we get to choose whatever syntax we want to make the whole process as enjoyable as possible.

The most brilliant part of Svelte was the decision to stay as close to JavaScript as possible, so anyone who knows JS, HTML, and CSS knows svelte. Importing any vanilla JS library is plug-and-play, meaning the community and ecosystem span the entire JS ecosystem. No more x-for-react or y-for-vue.

The unbeatable performance is just a plus for me. The DX is so good that building things is incredibly fun, intuitive, and headache free. I can’t emphasize enough how empowering it is.

It’s so exciting seeing the community grow exponentially lately!!

Re: Virtual DOM is pure overhead (2018)

#78
post #70
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…

Performance is not a problem for the most developers, as long as the app runs smooth. React gave us not a better programming model, it gave us an other programming model. In some cases template based enignes are better than JSX, but that discussion has nothing todo with Svelte or React. React boomed cause at that time everybody has enough of bloated frameworks and with JSX you had a wonderfull thing to tinker code...…

> Why made it easy, when you can have it complex? ;-) And it came from well known Facebook, thats it, nothing more.

You can keep telling yourself that React only took over because it makes things more complex and it came from Facebook, if that's what makes you happy.

Re: Virtual DOM is pure overhead (2018)

#79

The web stack, from tunneling thru HTTP to the JavaScript language itself, is a very interesting case study. I think that many decisions, like creating a virtual DOM, make a lot of sense in isolation. But, if you look at the complete ecosystem, no sane human being would have ever designed anything like that. Maybe, the Virtual DOM is pure overhead if you look at the complete system, but: 1. It was reasonable at the t…

What's interesting to me, as someone who is currently learning Web development mid-career, is that I can see that vanilla JS is actually a really good option nowadays, but not necessarily available to anyone who's more established. Because it doesn't seem to have gotten good until fairly recently, and, for the most part, everyone had already made the important technical decisions before that happened. So, even if it'…

Vanilla JS gets messy as your app scales. You will end up building a framework.

Re: Virtual DOM is pure overhead (2018)

#80

Earlier quoted context omitted.

For me, trying to make sense of how React's reconciler matches hook invocations to component instances is pure cognitive overhead. Other people don't seem to have this problem. But trying to accomplish anything in React is arduous for me, particularly with function components and hooks. Class components seem a little more obvious.

Is it possible to just not think about it? Or is that easier said than done?

Yes, it's completely possible and most people don't think about it, at all. It's not complicated.
Post reply on HN