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

111–120 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#111

Post by lacampbell »

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…

compared to a well written app that updates the DOM directly only when needed (which I find is easy to accomplish in most apps)

Do you do full blown SPAs with this technique? I mean I'm sure it's possible, but I wonder how difficult it is.

I wouldn't use (p)react for a website that just needed a bit of AJAX, but I find it a bit hard to imagine doing an actual app with vanilla JS.

Re: Virtual DOM is pure overhead (2018)

#112

Post by JMTQp8lwXL »

underwater wrote: post #72

> The original promise of React was that you could re-render your entire app on every single state change without worrying about performance. In practice, I don't think that's turned out to be accurate. If it was, there'd be no need for optimisations like shouldComponentUpdate (which is a way of telling React when it can safely skip a component). It's shouldComponentUpdate(), not shouldDOMUpdate(). Even if DOM operat…

Well-written React code shouldn't need to leverage the shouldComponentUpdate API. The application structure would be off, if that's the case.

Re: Virtual DOM is pure overhead (2018)

#113

Post by tannhaeuser »

kevingadd wrote: post #4

Virtual DOM is a shaky long term bet since it's essentially betting that the cost of DOM operations will always be high enough to justify all the work you're doing (both at runtime and at trying-to-figure-out-how-to-write-this-code time). When it's easy to do your virtualization, you can just go 'well this is an optimization i can remove at any point', but if it's suddenly so complex it introduces bugs, you're in tro…

DOM operations (node insertions, deletions) are trivial. It's the CSS reflow/relayout that's expensive. Though that can be trivially solved by preparing a shadow DOM off-screen, then finally replacing the changed fragment by the newly build-up one. DOM diffing is just a convenient method to do it.

Re: Virtual DOM is pure overhead (2018)

#114

Post by pan_4321 »

Lx1oG-AWb6h_ZG0 wrote: post #48

Dan Abramov has a great thread about this here: https://mobile.twitter.com/dan_abramov/status/11209717954258... . In particular, I find this argument really persuasive: > Time slicing keeps React responsive while it runs your code. Your code isn’t just DOM updates or “diffing”. It’s any JS logic you do in your components! Sometimes you gotta calculate things. No framework can magically speed up arbitrary code. In my…

That's actually what I didn't understand in Dan Abramov's response ...

If you run a synchronous function that takes 2 seconds your app will block whether you use Svelte or React or whatever. You need to offload it to a webworker anyway.

Still I think it's a good idea to update the DOM not more often than needed: Only update the last change of an element every 23 ms and skip the changes that have been overriden. You can do this without a virt DOM.

Re: Virtual DOM is pure overhead (2018)

#115

Post by franciscop »

Seems like just an ad for Svelte, and fairly FUD-ish on that. React will warn you by default when doing that exact example, asking you to provide a key to the `` to avoid re-rendering it unnecesarily. Instead, this states "Unless you're unhealthily obsessed with performance, you're not going to optimise that."

Re: Virtual DOM is pure overhead (2018)

#116

Post by palerdot »

fnordsensei wrote: post #94
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]:…

I just noticed that Reframe README is very amusing and wickedly hilarious in some parts. It is very refreshing to read compared to other bland/formal/techinical READMEs ... Maybe in future I will try and see if using Reframe itself is joyful like its Readme ...

Re: Virtual DOM is pure overhead (2018)

#117

Post by JMTQp8lwXL »

brobdingnagians wrote: post #55
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?

I love Vue.js. I've never really caught onto the JSX stuff. If you have ".Vue" files then you get nice separation of the template html, methods, and the scoped styling. The Javascript syntax is pretty straightforward, and the templates just add nice directives like v-if, v-for, etc. I think it look pretty clean and is fairly easy for JS developers to pick up. Integration into a project is pretty straightforward as we…

I've never understood how people view the separation of template, styles, and business logic into separate files as simpler. Now, to work on a single component, I need to open three files in my editor, instead of one.

Re: Virtual DOM is pure overhead (2018)

#118

Post by JMTQp8lwXL »

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.

My company permits Vue and Angular, but not React. It isn't based in legal reasons, though.

Re: Virtual DOM is pure overhead (2018)

#119

Post by jasonkester »

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…

the DOM was often used to store state.

Every once in a while I'm reminded that I'm mostly disconnected from the way "most" people build things. Thanks for this insight. It finally explains why I hear people talking down about "jQuery developers", if that was something that people actually did.

But wow. I've been building javascript-heavy web stuff since the mid 90's and it had never occurred to me to do that. You have your object model, and each thing had a reference back to its DOM node and some methods to update itself if necessary. All jQuery did was make it less typing to initially grab the DOM node (or create it), and give you some shorthand for setting classes on them.

It also explains why people liked React, which has always seemed completely overcomplicated to me, but which probably simplified things a lot if you didn't ever have a proper place to keep your data model.

I can't imagine I was the only one who had things figured out back then, though. The idea you're talking about sounds pretty terrible.

Re: Virtual DOM is pure overhead (2018)

#120

Post by pan_4321 »

pier25 wrote: post #69

After years of doing mostly React and Vue SPAs I've never experienced a performance problem. The metrics of Svelte that interest me more are lines of code and bundle size, both in which it excels. Here is an article that compares the exact same project called RealWorld written in a number of front end libraries/frameworks. https://medium.freecodecamp.org/a-realworld-comparison-of-fr... Here is the main repo for the R…

Same experience here but with React and Angular (2+). No real world differences that can be observed by an average user in the average app.

The choice has to be made by ecosystem, programming style, etc.

React as a library offers not enough for me personally. Angular is too heavy on concepts. Vue seems to hit the sweet spot?

Post reply on HN