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

231–240 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#231

Post by ironmagma »

ttfkam wrote: post #161
ironmagma wrote: post #145

Earlier quoted context omitted.

Mental overhead matters much more than performance overhead to most applications. The whole plot of JS is that it’s easy enough to work with that it overpowers any performance limitations. Svelte invents a completely new execution model for JS which adds overhead.

I honestly don't believe you've actually used Svelte even in an experimental context to make such a comment. Go check out the tutorial on the Svelte site and get back to us. It's literally >90% just HTML, CSS, and JS. The last <10% is split between stores, if- and each-blocks, and data binding syntax. If you don't know HTML, CSS, and JS as a web developer, I don't know what to tell you. If you do, the notion that Sve…

And that’s similarly how I feel about people who think Svelte is significantly less complex than React. At least React is just Javascript. Svelte tries to override assignment to trigger side effects. That’s crazy.

Re: Virtual DOM is pure overhead (2018)

#232

Post by peterhunt »

tobr wrote: post #223
peterhunt wrote: post #153

I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flo…

I think your conclusion in point 2 is misguided, but I can see where you’re coming from. It’s true that virtual DOM has a lot of expressive power, and Svelte’s templating features are more limited in how you can approach certain problems. I find Svelte’s slots especially challenging for more advanced use cases, and wish they were more composable. But in my experience, React’s openness to expressive experimentation is…

I think there are two things that are interesting about your point of view.

First, I think a mistake the react team made was not exerting more control over the ecosystem. I think a lot of questionable content marketing pieces ended up as “best practices” which we are still unwinding as a community.

Second, I totally buy the idea that there are multiple personas and that different tools speak to different personas. The sustained popularity of constrained dsls among subsets of the frontend community speaks to this.

Re: Virtual DOM is pure overhead (2018)

#233

Post by onion2k »

My life, and blood pressure, would be greatly improved if every article about JS frameworks ended with a paragraph that says something like "... but JS frameworks are pretty fast really, so you'll only see a problem if you're changing lots of things on the page at once. And if you're updating lots of DOM nodes in a single action then maybe you need to think hard about your underlying HTML structure and UX instead of worrying about what JS is doing. That's where your problem lies after all."

Re: Virtual DOM is pure overhead (2018)

#234

Post by nwienert »

The5thElephant wrote: post #208
peterhunt wrote: post #153

I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flo…

Regarding your second point, this is exactly why I like Vue and Svelte so much over React (which I am also quite familiar with). Coming from a design background and having learned HTML/CSS first, the Svelte and Vue approach to SFCs and templating makes it far easier to understand, write, and visually parse than React where everything is always JS first. I can't think of a situation where Svelte/Vue limited me from do…

It's great to argue for Vue/Svelte, but just to clarify - the entire point about HTML/CSS isn't really true, there's no difference in support between React or any other framework there.

And disagree on HTML/CSS skill loss being a thing, or being proximately caused by React. And no it doesn't have any div-soup causative effect either.

I get that templates are simpler for non-coders. Unfortunately, in all but the simplest cases the cost-benefit is towards the React model as you are just "using the platform" to build your views - ie, JS and not some arbitrary DSL.

Re: Virtual DOM is pure overhead (2018)

#235

Post by fleddr »

satvikpendem wrote: post #226
fleddr wrote: post #217

Imagine being someone in the semiconductor industry reading this. You're at the absolute pinnacle of high-tech and are approaching the limits of material reality to realize a 20% faster CPU. It's a true super human accomplishment. Software developers: well yes, 99% of the cycles I use are completely needless, but it's still plenty fast enough! Which we justify with the idea that a framework like React is abstract, he…

"What Andy giveth, Bill taketh away" https://en.wikipedia.org/wiki/Andy_and_Bill%27s_law

Good one, did not know that law but it's on point.

Re: Virtual DOM is pure overhead (2018)

#236

Post by acdha »

_Algernon_ wrote: post #207
acdha wrote: post #52

Earlier quoted context omitted.

This is over-simplified: the overhead of an abstraction can be cancelled out by work or optimizations which you wouldn't have done without the abstraction. As a simple example, most Python programs are faster than the C code the same developer would have written in the same time because they have a rich library of optimized code and getting it working quickly means that they had more time to focus on algorithm-level…

Tough crowd today... My comment was a reference to xkcd: https://xkcd.com/378/ Maybe I should have made it more obvious by referencing the butterflies instead.

Heh, yes. This runs into something like Poe’s law because you can find people who sound exactly like that but are serious. I especially remember someone’s reaction when their hand-tuned assembly started under-performing compared to GCC once we recompiled for (IIRC) Pentium 4 chips.

Re: Virtual DOM is pure overhead (2018)

#237

Post by revskill »

MrOwnPut wrote: post #215
TheRealPomax wrote: post #167

Note that a virtual DOM is pure overhead if you already have a real DOM to work with . That's kind of the ignored superpower of a framework like React, which makes the virtual DOM the authority: there might be a DOM, but there also might not be. Whether the virtual DOM reflects to a real DOM, or native UI, or Qt, or an ASCII terminal interface, it doesn't care. This is also the part that most web devs have the hardes…

Why did I have to scroll this far down for the real answer? This is the true power of the VDOM, to abstract the view from platforms. Why be a web developer when you can be a cross-platform app developer? That's why I don't use Svelte and other web SPA frameworks...

The point is, if you want to make your web app the most performant as possible, cross-platform solution has limitation.

Re: Virtual DOM is pure overhead (2018)

#238

Post by leetrout »

satvikpendem wrote: post #225
peterhunt wrote: post #153

I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flo…

Isn't SolidJS supposed to be like React (in that it has JSX, hooks etc) but without the VDOM? So I guess that would sidestep your point #2, but curious to hear your thoughts on it. Personally I don't use Svelte, Vue, Solid etc simply due to the (lack of) library support compared to React. For example, I wanted to do something in 3D the other day and reached for react-three-fiber, there simply isn't something comparab…

> For example, I wanted to do something in 3D the other day and reached for react-three-fiber, there simply isn't something comparable in the non-React world.

Respectfully, that is because you dont _need_ anything other than ThreeJS in the other frameworks.

I do find it interesting that it says it performs faster due to reacts scheduler.

Re: Virtual DOM is pure overhead (2018)

#239

Post by satvikpendem »

leetrout wrote: post #238
satvikpendem wrote: post #225

Earlier quoted context omitted.

Isn't SolidJS supposed to be like React (in that it has JSX, hooks etc) but without the VDOM? So I guess that would sidestep your point #2, but curious to hear your thoughts on it. Personally I don't use Svelte, Vue, Solid etc simply due to the (lack of) library support compared to React. For example, I wanted to do something in 3D the other day and reached for react-three-fiber, there simply isn't something comparab…

> For example, I wanted to do something in 3D the other day and reached for react-three-fiber, there simply isn't something comparable in the non-React world. Respectfully, that is because you dont _need_ anything other than ThreeJS in the other frameworks. I do find it interesting that it says it performs faster due to reacts scheduler.

> Respectfully, that is because you dont _need_ anything other than ThreeJS in the other frameworks.

Not really, ThreeJS is imperative, react-three-fiber is declarative. I use the latter for the same reason I use React over jQuery, I don't have to mess around with appending nodes, I can lay out my view declaratively and have the framework fill in the rest.

Re: Virtual DOM is pure overhead (2018)

#240

Post by imbnwa »

ironmagma wrote: post #231
ttfkam wrote: post #161

Earlier quoted context omitted.

I honestly don't believe you've actually used Svelte even in an experimental context to make such a comment. Go check out the tutorial on the Svelte site and get back to us. It's literally >90% just HTML, CSS, and JS. The last <10% is split between stores, if- and each-blocks, and data binding syntax. If you don't know HTML, CSS, and JS as a web developer, I don't know what to tell you. If you do, the notion that Sve…

And that’s similarly how I feel about people who think Svelte is significantly less complex than React. At least React is just Javascript. Svelte tries to override assignment to trigger side effects. That’s crazy.

Aren't Hooks also a significant deviation from the JS execution model? That they needed to write whole new documentation to clarify the model and its application seems to speak to some deviation
Post reply on HN