Please God let me never get into a situation where I need use these frameworks.
Virtual DOM is pure overhead (2018)
101–110 of 344 posts
Re: Virtual DOM is pure overhead (2018)
#102Earlier quoted context omitted.
In short - the DOM was often used to store state. And this just isn't a very efficient approach. By some people, sure, but separating state and business logic from presentation and rendering logic was a well-known idea many, many years before React was around. I think the basic premise of the article here is correct. The important development with React that hadn’t previously been widely seen in front-end, JS-based w…
>By some people, sure, but separating state and business logic from presentation and rendering logic was a well-known idea many, many years before React was around. My claim is that this isn't a good representation of the FE culture as a whole - even if there were islands of enlightment out there. Hell, just about all of the enterprise codebases I get contracted to work on are STILL do state management the old way. S…
My claim is that this isn't a good representation of the FE culture as a whole - even if there were islands of enlightment out there.
I can’t really dispute that since I don’t have any useful statistical evidence. All I can say is that in my experience there were mostly two types of people working on front-ends to run in browsers in the early days: Web designers who learned programming, and programmers who learned the basic Web technologies and/or plugins. (Today, with the industry being somewhat more mature, I’d say there’s a third group, who come straight into full-on front-end programming of JS-based web UIs at the same time as they’re learning HTML and CSS.)
Crucially, this means you have some web developers who have broader programming experience and/or formal training, and others whose knowledge mostly comes from online tutorials and QA sites and from the knowledge and culture passed on by their peers. The former type probably have some understanding of software architecture for more substantial applications, and might well have had a reasonably systematic data model, separated business rules from the rendering(s) of the underlying data, and so on. The latter type often aren’t aware of these concepts and tend to write much more hacky code — such as keeping application state in the DOM — because they don’t know any better.
Adopting a comprehensive framework can mitigate that lack of knowledge to some extent, which I suspect is a big part of why the heavyweight frameworks caught on in front-end work just as they did in desktop UI work earlier, but ultimately there’s still no substitute for knowing what you’re doing. Today the same type of people who used to keep their application state in an ad-hoc mix of scattered variables and the DOM are trying to build their entire application architecture with React components and either scattering the state and business logic throughout those components or, in some cases, adopting a heavyweight data management architecture like Redux instead.
Re: Virtual DOM is pure overhead (2018)
#103Earlier quoted context omitted.
> ultimately translates to better performance Better compared to what? For a library like React, which re-renders the DOM tree every time component’s props or state change, virtual DOM with diffing and patching is indeed a better approach as compared to naive re-rendering of the whole DOM. But as Rich Harris said during his talk about Svelte v.3.0, whenever he hears claims about better performance of frameworks based…
> But as Rich Harris said during his talk about Svelte v.3.0, whenever he hears claims about better performance of frameworks based on virtual DOM, illustrated with benchmarks, he runs the same benchmarks with Svelte (not based on virtual DOM), and inevitably gets better results. That isn't a fair comparison. Consider this analogy - React is the JVM and Svelte is Rust. JS before either is C. Now it can be shown that…
> Now it can be shown that in most cases that C is faster than anything on JVM, but in reality it wasn't, and that C code was riddled with bugs.
Um, what? Your metaphor breaks down because it doesn’t really connect with reality. The operating system and the browser you typed that in are written in C/C++ because the performance hit of doing that in a language like java would be absurd. Practically every performance sensitive application is still written in C/C++ (games, productivity tools, desktop apps, etc). Rust is, outside of places like HN, just an interesting novelty to like 99.999% of the software industry, and your average java app is glue code between a gui and a database.
Re: Virtual DOM is pure overhead (2018)
#104I have always said: Angular is diffing the model React is diffing the view That’s all. Better to just skip the diffing usually, and grab references to elements and update them when certain events happen. It’s really ok!
The problem is spaghetti! You have something in the Dom and you might not know what can or has updated it or why...
Re: Virtual DOM is pure overhead (2018)
#105I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced. Here's the gist of how folks would often update an element. You'd subscribe to events on the root element of your component. And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child…
What I think this article does very well is rebut the myth that the DOM is slow. The DOM is not slow -- on the contrary, it is very fast. What is slow is browser reflow, page refreshes, display calculations, etc. In web app development of yesteryear, browser reflow was typically triggered by poorly conceived manual DOM manipulations -- which gave birth to the myth that the DOM itself is slow.
Implementing a virtual DOM and VDOM diffing is just one way to manipulate the DOM more efficiently and intelligently. At my work, we've chosen a different path without the overhead and leaky abstraction of a virtual DOM.
We built our own component-based SPA framework and recently open sourced it ( https://github.com/ElliotNB/nimbly ). Each component must have a definition of what state mutations should trigger what portions of the component DOM (via CSS selectors) to refresh. There's no extra overhead for a VDOM and VDOM diffing at all. The only overhead is accrued ahead of time by the developers who must write a definition of how their component should update in response to state changes. When state does change, the framework bundles up the queued DOM changes between all components on the page, identifies/eliminates any redundant changes and refreshes the DOM in one go.
Re: Virtual DOM is pure overhead (2018)
#106I think this article - and many of the comments on this thread are forgetting the context of how DOM manipulation was typically done when the virtual DOM approach was introduced. Here's the gist of how folks would often update an element. You'd subscribe to events on the root element of your component. And if your component is of any complexity at all - first thing you'd probably do is ask jQuery to go find any child…
> ...seem to be trying to present React's claim of the VDOM faster than the DOM as some kind of toddler mistake.
It wasn't a toddler mistake, but it was repeated over and over to convince people to move to React.
Re: Virtual DOM is pure overhead (2018)
#107So glad to see this article, I've long wondered how this "virtual DOM is faster" myth got accepted as gospel when clearly it's pure overhead, compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps). Can't speak to the svelte approach due to inexperience with it, but good to see this myth challenged - react.js is fine but I worry there's been a ca…
Yeah, you're right. But then you get others now trying to say "No no no, you have it all wrong. We didn't really say VDOM was faster. You misunderstood."
Re: Virtual DOM is pure overhead (2018)
#108Earlier quoted context omitted.
> But as Rich Harris said during his talk about Svelte v.3.0, whenever he hears claims about better performance of frameworks based on virtual DOM, illustrated with benchmarks, he runs the same benchmarks with Svelte (not based on virtual DOM), and inevitably gets better results. That isn't a fair comparison. Consider this analogy - React is the JVM and Svelte is Rust. JS before either is C. Now it can be shown that…
> Now it can be shown that in most cases that C is faster than anything on JVM, but in reality it wasn't, and that C code was riddled with bugs. Um, what? Your metaphor breaks down because it doesn’t really connect with reality. The operating system and the browser you typed that in are written in C/C++ because the performance hit of doing that in a language like java would be absurd. Practically every performance se…
I had a feeling it was a poor analogy after I submitted it. I'll leave it up, but the analogy doesn't properly convey the point I was trying to get across. This isn't a discussion about Java's relative performance with C++.
It's more about the performance gains of properly optimizing your DOM modifications aren't generally possible with a static analysis like Svelte employs.
Re: Virtual DOM is pure overhead (2018)
#109I keep hearing this and find it really hard to care about. Runtime performance is not a bottleneck for me. Once in a blue moon I'll have to optimize a React component with shouldComponentUpdate but otherwise I have no performance concerns even on old browsers. There are other characteristics that are very, very important like build size. VDOM is not worth thinking about. Honestly I don't understand Svelte. It sounds…
To my understanding, one of (or the singular) author of Svelte was a developer for the NY Times who wanted to easily create visualizations with thousands of data points, and the existing UI libraries weren't cutting it on performance. Depending on the types of applications you build day-to-day, this problem space might be niche. Your standard CRUD app (tables, forms, etc) would not be leveraging Svelete's capabilities; in a sense, it could be a pre-mature optimization.
Re: Virtual DOM is pure overhead (2018)
#110Earlier quoted context omitted.
Currently trying to find a new framework to do a front-end with because the company I'm currently interning doesn't allow React :^) Looking at angular code, it's pretty ugly. What would be the next best thing to look at? Vue?
What about Preact :)
Great suggestion. Preact is only 3kb so your users will appreciate it too.