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

191–200 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#191

Post by underwater »

JMTQp8lwXL wrote: post #112
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.

A React component can do arbitrary, computationally expensive, logic inside components. React gives you the ability to memoize that work. Without shouldComponentUpdate developers would need to hand roll a caching layer or stick computed values in a store.

Re: Virtual DOM is pure overhead (2018)

#192

Post by Udik »

WA wrote: post #185
jasonkester wrote: post #119

Earlier quoted context omitted.

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

If you’ve ever written a video game, I think it’s quite obvious as well. Video games have a main loop, take input, compute the next state, and then merely render the state to the screen. There is no point in manipulating the "UI". The data flow is very clear. Of course, your game can run entirely "in memory" without a render function, which is basically what the game server does. So I guess, many people have figured…

> Video games have a main loop, take input, compute the next state, and then merely render the state to the screen. There is no point in manipulating the "UI". The data flow is very clear.

I always thought this is basically the MVC pattern. And it's obviously the only sane way to do things.

Edit: I don't mind the donwvotes, but am I wrong? The MVC pattern simply seems to mandate, at its core, the separation between the model, its graphical representation, and the input from the user. Input -> model -> view. So a game loop where the user input is gathered, the model is updated by calculating the next state, and the view is displayed seems to me an instance of MVC.

Re: Virtual DOM is pure overhead (2018)

#193

Post by layoutIfNeeded »

nailer wrote: post #158
sam0x17 wrote: post #137

Earlier quoted context omitted.

Convenience is to be taken with a grain of salt, though. In the node.js world, "is-odd" can be a package, and it can have 926,000 weekly downloads and 22 dependents.

Makes sense, you don't want to write your own tests for handling zero.

lol, zero is even.

Re: Virtual DOM is pure overhead (2018)

#194

Post by madeofpalk »

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…

> it was the declarative description of the rendered content

this is absolutely the 'revolution' that React brought front end centre - declarative UI's for the web. This is why people that enjoy working with react enjoy it so much, whether they know it or not.

Re: Virtual DOM is pure overhead (2018)

#195

Post by finchisko »

addicted wrote: post #76
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…

Well written. From my memory I remember situations trying to isolate cascade of rerenderes in backbonejs caused by multiple isolated event handlers. Also state used to problems, before state management libraries existed. And actually messenger (built in) was first app that was written in react, because it was plagued by several bugs, like not showing/resetting unread message count correctly...

Re: Virtual DOM is pure overhead (2018)

#196

Post by ralphstodomingo »

cryptica wrote: post #133
jasonkester wrote: post #119

Earlier quoted context omitted.

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

complexity also kept me away from React. The main reason that it got popular is because it's by Facebook and they know how to manipulate people to use certain products over others (that's their entire business). There have always been simpler and cleaner alternatives. If React was not by Facebook, it would not have gotten popular at all except as a 'cool hack/experiment' - Nobody would have seriously tried to incorpo…

This is awfully dismissive without sound reasoning, I think. It doesn't take long for anyone working with the old ways outlined above (for example, me five years ago) to see why React was in many ways a step forward, defining what we should expect of any new front-end libraries these days. Also, everything starts out as a cool hack/experiment at some point.

> it's one of those tools that tries to take away complexity by adding complexity on top

It's one of those tools that purposely abstracts unproductive, inefficient complexity that we were not aware of before into a higher-level one, forcing us to be more mindful of how we do things. A matter of tradeoffs, I would say, and there's gotta be a limit to how 'simple' one thing can be. Also, you're conflating React the library with the ecosystem around it.

On a sidenote, all the tooling and boilerplate React came hand-in-hand with was markedly a net positive for me. It was in picking up React, during my career, that I learned why tooling is important, picked up tools like Webpack and grunt, learned myself how to do CI/CD and other stuff.

Re: Virtual DOM is pure overhead (2018)

#197

Post by austincheney »

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…

> was typically done when the virtual DOM approach was introduced.

Don't care and I am guessing you didn't read the article. Ignorance of the DOM does not redefine what it is. This is just as true for jQuery stupidity as it is for React virtual DOM nonsense. Fortunately, the DOM is defined in a standard specification so there is a document of truth that you can go read.

> In short - the DOM was often used to store state. And this just isn't a very efficient approach.

Again, don't care. Other people's misuse and stupidity is their problem. That stupidity does not alter the technology specification.

If you really want to know what the DOM is I wrote a very brief summary with links to the specifications: https://prettydiff.com/2/guide/unrelated_dom.xhtml

Re: Virtual DOM is pure overhead (2018)

#198

Post by Udik »

onion2k wrote: post #147
jasonkester wrote: post #119

Earlier quoted context omitted.

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

Bare in mind that most people using jQuery weren't writing JavaScript applications. They were writing backend-driven applications with jQuery enhancements, so there was no real concept of frontend 'state' that was separate to the DOM itself. If your frontend code needed to work with 'state' like form values or element attributes you had to read them, and because there could be multiple separate bits of code working w…

> he thing that changed to make frontend development improve dramatically was hash based routing with ajax...

I think that what's changed is simply that people realized that it's way less messy to use the backend only as a data source (with ajax calls), and leave everything else to the frontend. The cognitive overhead of having the server producing html with some implicit state, then updating that state interactively, and then losing everything again by posting the whole page to the server, was simply unbearable.

When I started building web applications in 2004 I had some experience in writing desktop apps: I simply created a js library to create and destroy UI elements, and wrote "desktop" apps running in the browser.

Re: Virtual DOM is pure overhead (2018)

#199

Post by delusional »

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…

I still do some old school JQuery manipulations, and a lot of what kills you on the performance front is also the repeated manipulations of the same set of elements in the same frame. Often, you go in and change an element. Only to have another piece of javascript change it again. Each of those modifications then require a complete relayout of the page, that's when it gets expensive.

You could say that we should just optimize our JQuery, and you'd be right. We just don't have structured way of figuring out everything that touches a "component". (What is a component anyway, when it's all adhoc).

Re: Virtual DOM is pure overhead (2018)

#200

Post by austincheney »

lacampbell wrote: post #111
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.

> but I wonder how difficult it is.

Its not if you have some basic understanding how the code actually works.

> but I find it a bit hard to imagine doing an actual app with vanilla JS.

Try it. It will blow your mind how simple it is and how little overhead it requires.

Post reply on HN