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

181–190 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#181

Post by aidenn0 »

macspoofing wrote: post #166
aidenn0 wrote: post #146

Earlier quoted context omitted.

I wrote a react application and VDOM overhead was so high that I had to cut down what parts of the UI were rendered to just what was on-screen at any given time. Performance was just barely okay on a desktop and completely unusable on an Android phone. Not using react made everything work amazingly fine. Granted this was an application with fairly low amounts of DOM manipulation (popup things when the user clicks on…

>I wanted to use React because the code was so much cleaner and concise, but it was just way too slow. I've been hard on React in other places in this thread because I agree with the premise of the article that VDOM is not free and that the value of React is not in performance over raw DOM manipulations, but rather in code organization. Having said that, React isn't bad either. That it was too slow for you, I suspect…

> React code was simple enough that it wasn't hard to understand and trace trough, or profile

Interestingly enough, this was the opposite of my experience. For my next project I used Mithril because it was far easier for me to debug, trace, and profile through.

> That it was too slow for you, I suspect, comes down how you wrote and structured your application and not necessarily React.

I had on the order of 100 inputs with two-way binding. My code was structured along the lines of the existing react tutorial of the day (maybe 10ish years ago?). Per suggestions of members of the react community, I restructured it to use ImmutableJS to allow for faster VDOM diffing, which did cause a noticeable speedup, but was still dog slow.

Re: Virtual DOM is pure overhead (2018)

#182

Post by macspoofing »

eagsalazar2 wrote: post #177
macspoofing wrote: post #97

Earlier quoted context omitted.

>Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale. What do you mean 'at scale'. It's a UI framework that runs JS and mutates the DOM - there's no issues with 'scale' here. That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it.

>> That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it. This is complete and utter nonsense. Were you programming seriously before React? There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very…

>This is complete and utter nonsense. Were you programming seriously before React?

Indeed I was.

>There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very real problems.

I'm not saying React isn't a good framework, it is perfectly nice, though I think you're overstating it. AngularJS was a perfectly fine framework as well, and that was out long before React.

>Dismissing Svelt's success/failure by saying all framework success is because of fads is an excuse and, if you are part of the Svelt community

I'm not part of Svelt's community. I haven't actually used Svelt at all. I barely know about it. But I've been around for a while. Why certain frameworks go viral and others do not, is not always based on merit. I'll buy the argument that Svelt doesn't have enough of a benefit over React ... it also came out a few years later and doesn't have Facebook's marketing weight behind it either. Does that mean React is the best thing ever? Eh, it's alright. Having done everything from Flash/Flex/Starling, to Silverlight, to Backbone, to AngularJS, to React, I actually get more excited about State management patterns than widget overlays with some declarative patterns and data-biding. By the way, when it comes to ergonomics of building complex SPAs, I think we're just hitting the place that Flash/Flex was 15 years ago in Web Development.

Re: Virtual DOM is pure overhead (2018)

#183

Post by jlokier »

tyingq wrote: post #171

I'm somewhat surprised that React won out versus Angular or something similar. Because React isn't opinionated about the supporting things around it, there seems to be wide variations in a React stack and approach from team to team. More so than I would typically see in any other ecosystem. But nobody seems to care. Is is that it makes for a sort of meritocracy where people that keep up with the fast changing landsca…

I think it was:

- The Angular dependency injection stuff seemed rather complicated compared with React pragmatism. Using React became heavier by the time Redux and other boilerplatish practices became widespread, but React had already gained adoption by then, and you could still get into it on tiny projects without fancy state management.

- The VDOM had articles saying how much faster it was than everything else, so it gained a reputation for speed compared with the other client-side templating alternatives at the time. Angular 1 had a reputation for being slow due to scanning all state variables on every refresh. Really React wasn't fast at everything, but fast at enough things to get that reputation. People who really understood DOM differential updates already knew how to do it faster than VDOM, either by hand or with smarter differential template compilers, but implementations weren't common. Marko and Svelte came along later.

- After years of being trained that separating HTML templates and code was the right thing to do for better engineering, preferably in separate files, it turns out that was annoying and lots of people really liked inlining the dynamic parts of HTML directly into code.

Re: Virtual DOM is pure overhead (2018)

#184

Post by dsego »

ehnto wrote: post #138
the__alchemist wrote: post #110

When I learned frontend web work and React years ago, I fell for the same "VDOM is fast!" hype, and assumed there was non-JS magic under the hood. I eventually built a VDOM-based frontend WASM framework in Rust (Seed). I now built frontends in HTML and CS, with no frameworks, and minimal, targeted JS code to manipulate the DOM directly; it's liberating, and much faster than both React and WASM/Rust.

It's crazy how quickly frontend UI frameworks became the standard approach. They're not necessary in so many instances where they are used. I also found it pretty comical when server side rendering became a hot topic, like duh guys, that's what we were doing first! Did you forget? Anyway, it's not that frontend UI frameworks are bad, it's more that pragmatism gets thrown out the window so quickly.

> I also found it pretty comical when server side rendering became a hot topic, like duh guys, that's what we were doing first! Did you forget?

A lot of new kids (we call them frontend engineers) haven't done the old school way. They just know SPAs, because that's what they've been taught in the last decade or so.

Re: Virtual DOM is pure overhead (2018)

#185

Post by catlifeonmars »

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…

> but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.

I agree with you in general, but I can’t agree with this statement. Web development needs fewer gatekeepers.

Re: Virtual DOM is pure overhead (2018)

#186

Post by icedchai »

paavohtl wrote: post #119
mumblemumble wrote: post #69

Earlier quoted context omitted.

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

Pedantry time: there is no such thing as a vanilla JS way of building web applications, in the same way there is no vanilla C way of writing compilers. JavaScript as a language does not concern itself with web browsers - that's the responsibility of the DOM API. But even ignoring that, there is no standardized or widely adopted way to build interactive web applications without frameworks.

True, except for the fact Javascript would have no reason to exist without a web browser. Do you remember when Netscape 2.0 was released? That's when Javascript was born. Its primary use cases were form validation and image preloading.

Re: Virtual DOM is pure overhead (2018)

#187

Post by icedchai »

flyingchipmann wrote: post #167
slumdev wrote: post #157

Earlier quoted context omitted.

Browsers support HTML and JS (and a few other things not relevant to this point). Neither HTML or JS on its own will do what you're describing. HTML doesn't allow binding to a data source. JS doesn't allow you to write HTML declaratively. So, people build abstractions. If an abstraction ever became popular enough and futureproof enough, there could be a case for supporting it natively. But I don't know of anything th…

What are you talking about? That's the exactly the purpose of jsx - manipulate html with straightforward javascript. and jsx is just a wrapper for React.createElement().

I find JSX is only straightforward for the simple cases. Often you wind up with unreadable, convoluted garbage because someone was trying to be clever with too many ternary operators, etc.

Re: Virtual DOM is pure overhead (2018)

#188

Post by Quinner »

aidenn0 wrote: post #146
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'…

I wrote a react application and VDOM overhead was so high that I had to cut down what parts of the UI were rendered to just what was on-screen at any given time. Performance was just barely okay on a desktop and completely unusable on an Android phone. Not using react made everything work amazingly fine. Granted this was an application with fairly low amounts of DOM manipulation (popup things when the user clicks on…

It's hard to say for certain, but it sounds as if you may have been doing things that caused lots unnecessary re-renders. React has some pitfalls for beginners, but I've built highly complex frequently updating webapps without the degree of slowness you're speaking of.

Re: Virtual DOM is pure overhead (2018)

#189

Post by slumdev »

flyingchipmann wrote: post #167
slumdev wrote: post #157

Earlier quoted context omitted.

Browsers support HTML and JS (and a few other things not relevant to this point). Neither HTML or JS on its own will do what you're describing. HTML doesn't allow binding to a data source. JS doesn't allow you to write HTML declaratively. So, people build abstractions. If an abstraction ever became popular enough and futureproof enough, there could be a case for supporting it natively. But I don't know of anything th…

What are you talking about? That's the exactly the purpose of jsx - manipulate html with straightforward javascript. and jsx is just a wrapper for React.createElement().

JSX isn't HTML. Is it truly less cognitive burden to have a language that looks like HTML but isn't? With properties changed because they're reserved words? And with control statements from other languages supported inline?

If someone gave me a language that looks like Lisp but with car and cdr renamed to something else, is that really making my life easier?

Re: Virtual DOM is pure overhead (2018)

#190

Post by megous »

catlifeonmars wrote: post #185
darepublic wrote: post #153

Earlier quoted context omitted.

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…

> but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo. I agree with you in general, but I can’t agree with this statement. Web development needs fewer gatekeepers.

Adding and removing nodes from a tree doesn't require a phd.

I don't particularly like React and I never used it, but I can see how it improves performance over naive use of browser APIs, because you can easily do things that are really bad for performance and require needless layout calculations when updating DOM manually, while tools like React will sort the updates in more optimal way without too much thinking.

Post reply on HN