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

241–250 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#241

Post by brundolf »

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…

> HTML and CSS not being first class-citizens as they are in other frameworks

In what ways are HTML and CSS less than first-class citizens in React? In my React codebases we've always written CSS (or SCSS) stylesheets, and components bottom-out in JSX (which is almost exactly just an HTML template with inserts)

In my experience the biggest barrier to (and most legitimate complaint about) React vs other frameworks is state management. It's always had special rules around that (even for experienced JS devs), and hooks turned that up to 11 (not without good reason, but still). While Vue at least has always had super simple state management: you modify normal JS values and the UI updates. Are you sure that hasn't been part of the divide you've observed?

(for the record it is also possible to retrofit React with state management more like Vue's (MobX, etc), but it'll be a compromised experience in some other small ways, and it may create some pain around some other library integrations that ship as hooks)

Re: Virtual DOM is pure overhead (2018)

#242

Post by ironmagma »

imbnwa wrote: post #240
ironmagma wrote: post #231

Earlier quoted context omitted.

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

No, hooks live strictly within the JS execution model. If they didn’t, they’d need a special compiler or some kind of special low level instruction.

Re: Virtual DOM is pure overhead (2018)

#243

Post by imbnwa »

taftster wrote: post #143
dangoor wrote: post #136

Earlier quoted context omitted.

I don't think that perspective is fair to modern browser engines. The additions of flexbox and grid layouts took them beyond just typesetting, I think (not to mention all of the work on JS engines, providing APIs for a whole bunch more device functionality, etc.) So it's true that there's still a "typesetting engine from the 80s" in there, but there's also a powerful layer of app functionality built-in as well. It's…

Right. It's been discussed before, but the web browser is one of the greatest examples of "write once, run anywhere" in terms of the markup that is HTML. If the evolution had happened differently, maybe we'd be all be using Java applets or Flash applications instead. I believe HTML/browser is superior, but I wonder where other platforms would have evolved to.

Flash authoring tools are still unmatched

Re: Virtual DOM is pure overhead (2018)

#244

Post by hbrn »

88913527 wrote: post #20

Poorly written react code isn't performant and removing the Virtual DOM will not fix your problem. It's a hill I'm willing to die on. Many engineers seem to struggle with unnecessary re-renders, to the point where I see long tasks in the performance tab. Clicking a button shouldn't lock the UI thread for 2 seconds.

> removing the Virtual DOM will not fix your problem

Having seat belts will not fix car crash deaths.

But it does make them less likely to occur, doesn't it?

Re: Virtual DOM is pure overhead (2018)

#245

Post by com2kid »

pweissbrod wrote: post #224
shortcake27 wrote: post #185

Earlier quoted context omitted.

> By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application. No you don’t. > In most cases you must choose a framework for routing. Also a framework for state management. I don’t understand this argument. React gives the developer this freedom by design. If you want a framework that has all of these decisions made for you, they exist. > You also dedicate to duplic…

Recently we went through an exercise where we built a to-do simple app using react and rewrote it using HTMX. The functionality was identical between the two apps. The amount of tooling code and duplicative logic was massively higher because of SPA and all the fundamental things it demands. Now if you really need an SPA for your requirements because you have an intrinsically complex front end and you've mastered the…

> Recently we went through an exercise where we built a to-do simple app using react and rewrote it using HTMX.

React is boilerplate madness.

Do the same in Svelte.

I did a form heavy app in Svelte, literally took 1/5th the time it would have taken in React.

SPA fundamentally means that instead of refreshing the page, just the data needed to update what is on screen is sent down to the user.

Ideally, "send data about products on next page of search results" is less than "send all HTML needed to render the next page of search results."

Also the backend ends up simpler, instead of trying to template strings together, the code can just worry about fetching and returning needed data.

I am legit confused why people think generating HTML in some other language (Python, Ruby, etc) is a good idea.

Keep HTML in the browser (easier to develop and debug!) and keep backend business logic someplace else.

Re: Virtual DOM is pure overhead (2018)

#246

Post by imbnwa »

ironmagma wrote: post #242
imbnwa wrote: post #240

Earlier quoted context omitted.

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

No, hooks live strictly within the JS execution model. If they didn’t, they’d need a special compiler or some kind of special low level instruction.

Gotcha

Re: Virtual DOM is pure overhead (2018)

#247

Post by com2kid »

mrtranscendence wrote: post #182
AtlasBarfed wrote: post #137

Earlier quoted context omitted.

I wish there was a "works for Pentium III" label that would help indicate that the app's usability hits necessary minimums on a 1Ghz Pentium III computer. IMO that would be a good optimization floor for avoiding the hidden monstrosity of electron apps and that type of stuff. If your McCrud app can't be responsive on a baseline 1Ghz PIII with 1GB of RAM, then there needs to be some sort of shame pushback. Moore's law…

Why Pentium III? That's nearly 25 years old. You couldn't run Windows 10 on such a processor, let alone a modern browser, and a $200 mobile phone would beat it in benchmarks. Surely you can have a higher floor than that.

Google Maps ran like a dream on Pentium M systems back in 2005. Gmail was also smooth as butter.

Pentium M was a derivative of the Pentium III design.

Ignoring high resolution image assets, there is no reason a website shouldn't degrade and be able run on any machine faster than 300mhz.

Re: Virtual DOM is pure overhead (2018)

#248

Post by com2kid »

marcosdumay wrote: post #198
AtlasBarfed wrote: post #137

Earlier quoted context omitted.

I wish there was a "works for Pentium III" label that would help indicate that the app's usability hits necessary minimums on a 1Ghz Pentium III computer. IMO that would be a good optimization floor for avoiding the hidden monstrosity of electron apps and that type of stuff. If your McCrud app can't be responsive on a baseline 1Ghz PIII with 1GB of RAM, then there needs to be some sort of shame pushback. Moore's law…

Is there some VM that allows limiting the CPU to a performance similar to a P4? (A PIII is way too bad for my tastes.) I imagine Linux would have a bad time running in it.

Pretty sure PIII's beat P4s at a lot of benchmarks. :-D Thus why AMD is around today.

Re: Virtual DOM is pure overhead (2018)

#249

Post by TheRealPomax »

revskill wrote: post #237
MrOwnPut wrote: post #215

Earlier quoted context omitted.

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.

Absolutely, but conversely: the performance hit of the virtual DOM _should_ (and that's doing a lot of heavy lifting) be irrelevant in a well designed UI, because aside from initial load, most parts of the UI don't change for the majority of the lifetime of the app. Only tiny portions of the UI update at a time. The parts that do update can most definitely update fast enough on even moderately modern hardware (both desktop and mobile).

That does, however, require having properly designed your UI, with a knowledge of where the power of your framework of choice is. And that's where a lot of apps fail. Even something as simple yet critical as using vdom keys tends to (for various reasons) never register for many folks, leading to terrible performance.

Re: Virtual DOM is pure overhead (2018)

#250

Post by hbrn »

notshift wrote: post #54

https://twitter.com/dan_abramov/status/1135424423668920326 Above thread summarizes the issue pretty well I think. Optimizing for DOM updates is nice, but you also want to optimize for bundle size and page load time, and at a certain app size the compiler output is always going to be bigger than just using a virtual DOM.

It is true that Svelte and React bundles will grow at different speeds as the app grows. Redundancy gets compressed in React library, but it just stays there in Svelte.

That said, since it is redundancy, I wonder if Svelte bundles are more gzippable (or at least, could be made so).

Post reply on HN