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

91–100 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#91

Post by hn_throwaway_99 »

oraphalous wrote: post #54

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

> This is what I understood the claim that VDOMs are faster than the real DOM meant - and the article is pretty much eliding this detail.

I disagree with this. I think the major key insight and innovation with React, which this article fully acknowledges, is that it is much easier to think about declarative UI as solely a function of the current state without having to think about the transitions to arrive at that state, and, importantly, the virtual DOM lets you do that performantly.

In other words, to take the example from the article, it would be great if we could have an "onEveryStateChange() { document.body.innerHTML = renderMyApp(); }" function, but doing that would be much too slow because it would recreate the full, real DOM. Using the virtual DOM lets you write essentially the same code, but in a performant manner, and I think the article is clear on this fact.

I'm not familiar with Svelte, but the article has peaked my interest because it is making it sound like it lets you write declarative UI but without needing to do the full virtual DOM diffing.

Re: Virtual DOM is pure overhead (2018)

#92

Post by muxator »

andrewfromx wrote: post #39
QuadrupleA wrote: post #32

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

tell me about it! Or, heaven forbid, just make the user get the entire html page rendered from server after every click like it's 2003 or 2004!

Which sometimes is not bad at all. Ever tried to ctrl-click an interface element (a navigation button, a menu) because you want to open its view in a new window?

A lot of (admittedly badly coded) "modern" web apps ignore basic web idioms (like hyperlinks) and assume as unique single user workflow the one its designer tought the app (and the only one he tested).

Re: Virtual DOM is pure overhead (2018)

#93

Post by oraphalous »

hn_throwaway_99 wrote: post #91
oraphalous wrote: post #54

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

> This is what I understood the claim that VDOMs are faster than the real DOM meant - and the article is pretty much eliding this detail. I disagree with this. I think the major key insight and innovation with React, which this article fully acknowledges, is that it is much easier to think about declarative UI as solely a function of the current state without having to think about the transitions to arrive at that st…

See my reply to Chris_Newton's earlier response to my comment. :)

Re: Virtual DOM is pure overhead (2018)

#94

Post by fnordsensei »

nojvek wrote: post #89

The ideas of svelte are great. It reminds me of snabbdom thunks and inferno blueprints. If you know the view code ahead of time, you could do plenty of perf optimizations since you exactly what changes and what to react to. But sometimes I dynamically generate vdom nodes. Like markdown to vdom. There vdom shines. It’s a simple elegant idea. I think svelte is exaggerating a bit. React and vdom family of libraries are…

I do this with React all the time as well, though via ClojureScript and Re-frame[1], in which nodes are represented as plain Clojure data structures.

E.g., send an article from the server, formatted in EDN/Hiccup[2][3]. Insert it into a component in the frontend, and it's converted to VDOM nodes. No further logic or conversion required.

[1]: https://github.com/Day8/re-frame

[2]: https://github.com/edn-format/edn

[3]: https://github.com/weavejester/hiccup/wiki/Syntax

Re: Virtual DOM is pure overhead (2018)

#95

Post by spankalee »

somerando7 wrote: post #51
jordache wrote: post #27

Earlier quoted context omitted.

>functional and composable way components can be designed and implemented. Ughh.. that's the point of all modern FE frameworks... You are putting that description on a pedestal as if that is a unique property of React.

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?

Check out web components with LitElement and lit-html.

You get a very React-like experience with components and functional templates in JS, but it's all standard JS, and there's no framework, just standard web components. The lock-in and risk is very low for enterprises.

Re: Virtual DOM is pure overhead (2018)

#96

Post by somerando7 »

Stratoscope wrote: post #77
somerando7 wrote: post #51

Earlier 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?

They allow you to use anything you want, as long as it's not React? I am very curious about this kind of decision. I realize you may not be able to share details, but whatever you can share would certainly be interesting.

Probably not WHATEVER, but what's approved by legal. React currently isn't because of the license/company that owns it I believe.

Re: Virtual DOM is pure overhead (2018)

#97

Post by somerando7 »

jacobsenscott wrote: post #73
somerando7 wrote: post #51

Earlier 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?

Why don't they allow react? One reason I can think of is they have a server side side rendered architecture and they want people to continue to use that. They don't want new devs to use company time to buff their resume with unmaintainable learning front end code. At least that's why I generally shoot down attempts at using FE js frameworks over here. We have some really awful react 0.11 pages that are years old that…

Legal reasons.

Re: Virtual DOM is pure overhead (2018)

#98

Post by acemarke »

somerando7 wrote: post #96
Stratoscope wrote: post #77

Earlier quoted context omitted.

They allow you to use anything you want, as long as it's not React? I am very curious about this kind of decision. I realize you may not be able to share details, but whatever you can share would certainly be interesting.

Probably not WHATEVER, but what's approved by legal. React currently isn't because of the license/company that owns it I believe.

Well, the _license_ certainly shouldn't be an issue at this point. It was changed to a standard MIT license a couple years ago, same as all the other major JS frameworks.

If your company has issues with React being developed by Facebook, that's an entirely different question.

Re: Virtual DOM is pure overhead (2018)

#99

Post by karmelapple »

toasterlovin wrote: post #64
oraphalous wrote: post #54

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

Not really a JS developer, but from my recollection, everything you said is essentially correct. I was on the periphery of the Ember community when React dropped. I remember a blog post or something where the Ember developers basically acknowledged that React's virtual DOM approach was significantly more performant than what Ember was doing and, to the Ember community's credit, resolved to re-architect their view ren…

That is indeed what happened, and Ember got some major performance enhancements as a result! Things like Glimmer were a result of this.
Post reply on HN