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

71–80 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#71

Post by thatswrong0 »

acemarke wrote: post #58
adzm wrote: post #25

Earlier quoted context omitted.

Note that even jsx is not technically required, and on occasion I've clenched my teeth and written non-jsx react code for some one-off demos.

Jason Miller's `htm` library is a great alternative: nearly-JSX syntax via template strings, with no compilation needed: https://github.com/developit/htm

I know that in concept not needing compilation is nice because it’s one less thing to have to worry about, but I don’t think I’d want to use JavaScript without any compilation. Just curious what the use case for not doing compilation is?

Re: Virtual DOM is pure overhead (2018)

#72

Post by underwater »

> 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 operations are direct, or the virtual DOM is infinitely fast, there are plenty of situations where you want to avoid running application code on every update.

Some frameworks use data binding to track if a component update is necessary. This is what Svelte does, but because there is no explicit checks they have some weird conventions around annotating certain bound values:

    
        export let num;
        $: squared = num * num;
React just happens to implement this behaviour different: it assumes a component needs updating unless the shouldComponentUpdate() hook says otherwise. The advantage (ironically) is that React is "just JavaScript", whereas Svelte needs a compiler that can instrument the code.

This design decision shouldn't be confusing to the author; I assume he would have made this design decision consciously?

Re: Virtual DOM is pure overhead (2018)

#73

Post by jacobsenscott »

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?

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 will take weeks to redo properly.

Anyway, my point is you might want to check if it is okay to use any FE framework at all. It seems like a very strange policy to say "you can use any FE framework except React".

But if you are going to do this use Vue.

Re: Virtual DOM is pure overhead (2018)

#74

Post by dsissitka »

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…

Rich recently addressed this:

https://youtu.be/AdNJ3fydeao?t=1128

Re: Virtual DOM is pure overhead (2018)

#75

Post by acemarke »

thatswrong0 wrote: post #71
acemarke wrote: post #58

Earlier quoted context omitted.

Jason Miller's `htm` library is a great alternative: nearly-JSX syntax via template strings, with no compilation needed: https://github.com/developit/htm

I know that in concept not needing compilation is nice because it’s one less thing to have to worry about, but I don’t think I’d want to use JavaScript without any compilation. Just curious what the use case for not doing compilation is?

Some folks simply don't want to use a build system, whether it be for experimentation or not wanting to deal with the overhead of tooling.

Others are looking for options that might minimize overall script / JS size (which is a hallmark of Jason Miller, author of both Preact and HTM).

Another might be to make this easier for beginners. For example, the React docs link to an example HTML page that uses the `babel-standalone` build [0] as a way to try out JSX syntax. However, that's a hefty piece of JS, and it's not at all advisable for real use. HTM might be a good alternative to that.

[0] https://reactjs.org/docs/add-react-to-a-website.html#quickly...

Re: Virtual DOM is pure overhead (2018)

#76

Post by addicted »

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 how I remember things as well. The Virtual DOM was a huge improvement compared to other contemporary frameworks because it consolidated multiple changes into a single DOM operation.

For one thing, all the frameworks at the time we’re doing 2 way bindings. Which meant that the smallest change could end up triggering a bunch of computeds and observables, to the point where any change would trigger a bunch of re renders.

React bundled all of those into a single rerender. Further, and I may be mistaken about this, react helped dispel 2 way binding and show that 2 way binding was a performance and reasoning disaster. If that was the case, I’d suppose eliminatin g 2 way binding also likely played a large role in the performance improvements which may potentially have been incorrectly attributed to the VDom.

Re: Virtual DOM is pure overhead (2018)

#77

Post by Stratoscope »

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?

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.

Re: Virtual DOM is pure overhead (2018)

#78

Post by revvx »

thatswrong0 wrote: post #71
acemarke wrote: post #58

Earlier quoted context omitted.

Jason Miller's `htm` library is a great alternative: nearly-JSX syntax via template strings, with no compilation needed: https://github.com/developit/htm

I know that in concept not needing compilation is nice because it’s one less thing to have to worry about, but I don’t think I’d want to use JavaScript without any compilation. Just curious what the use case for not doing compilation is?

I think you have answered your own question: it's one less thing to worry about in your stack.

If you're targeting modern evergreen browsers you already have a lot of modern features at your disposal, including ES6 modules, async/await, string interpolation, but we're not using them.

In fact, I'd say that it's way more than "one thing" that you can stop worrying about: you won't need Webpack/Rollup/etc, Babel, NPM/Yarn, Node.js itself, etc.

Re: Virtual DOM is pure overhead (2018)

#79

Post by oraphalous »

Chris_Newton wrote: post #65
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…

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.

So no - I don't agree the basic premise of the article is correct.

>The important development with React that hadn’t previously been widely seen in front-end, JS-based web development wasn’t the virtual DOM, it was the declarative description of the rendered content — building it in absolute terms from the current state, not in relative terms from the current and previous state.

You are ignoring that fact that the VDOM was the imperative implementation they used under the hood to make the declarative api work. It's the VDOM that allowed them to take state management out of the DOM - and thus why they claimed that the VDOM was faster than the DOM.

Sure - if other folks are finding other implementation approaches that allow one to keep state out of the DOM in even better ways - that's great. That doesn't mean it wasn't reasonable at the time to identify the VDOM with that central innovation since there wasn't many other people doing it in other ways.

>This doesn’t change the fact that the declare-and-diff strategy is extremely expensive compared to actively observing only necessary changes in the underlying state and making only necessary local updates in the (real) DOM.

I'm not arguing this case one way or another... I don't claim to know. The OP is certainly welcome by me to try to continue making that case. I think that's a good contribution to make.

I'm saying that OP could do this without crapping all over React's contribution - which tbh honest smells like a status move in order to obtain more market share. Wanting more market share is fine - but it should be enough to just compare the performance between the two to make that case. Don't straw man a "meme" to attack a competitor's status.

Re: Virtual DOM is pure overhead (2018)

#80

Post by ng12 »

Chris_Newton wrote: post #65
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…

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…

> but separating state and business logic from presentation and rendering logic

I think the parent was referring to something different. When you work directly with the DOM your _view_ logic is stateful. In the old days (jQuery, Bootstrap, Knockout, etc) you were spending a time simply keeping your data and your view in sync -- and god forbid you were trying to re-use some of that view logic in multiple places.

Post reply on HN