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

221–230 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#221

Post by coldtea »

Udik wrote: post #192
WA wrote: post #185

Earlier quoted context omitted.

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

Actually that's one way to do things, the two ways being retained mode and immediate mode.

And each has their own use cases and challenges.

Traditionally, however, most well known GUIs (most of the apps people use on the desktop) were done with retained mode libraries (GTK, Qt, Cocoa, and so on).

>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.

There's nothing preventing the view being a retained mode UI widget tree -- which is how MVC was commonly implemented iirc.

Re: Virtual DOM is pure overhead (2018)

#222

Post by barrkel »

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…

Before anybody runs away and thinks there's a fundamental insight here, I have to say that all that's really changing is who owns the retained model: application or UI library.

I mean retained by contrast with immediate, as in the early DirectX jargon.

By retained model, I mean the source of truth as to the current state of the UI. Games normally use an immediate mode API, but they still render the UI from a model; it's just that they own the model, whereas with UI toolkits, you generally manipulate a model the UI toolkit maintains and the UI toolkit renders from that model.

Retained mode UIs are much easier to start with. You can get something that looks good up and running very quickly, because you don't need to think through the best representation for your UI - skilled designers and engineers have already done the work, and developed composition and drawing routines so that it all hangs together.

The trouble starts in more sophisticated applications, where the internal model has grown more complex, and UI code is increasingly an exercise in duplicating changes from one model to the other, via reactive techniques like data binding, or more imperatively from events. Having components denormalize state is a recipe for desynchronization bugs.

The problem doesn't totally go away if you move wholesale to immediate mode where the app owns the model, though. There are UI concerns that don't really belong in most application models; things like focus, selection, non-local UI idioms like radio buttons, caret position in text, etc. Doing these things right involves a lot of subtle design. Most app developers are better off handing these concerns to experts who focus on them.

Re: Virtual DOM is pure overhead (2018)

#223

Post by Tobani »

DigitalSea wrote: post #220

This is why I use Aurelia. It's a Javascript framework many here have probably never heard of or used, it debuted in 2015 and I have been working with it for four years now. Sadly Aurelia debuted at the height of the React hype and soon after, Vue hype. Rob Eisenberg (the man in charge of the Aurelia project) had the right idea straight out of the gate. A reactive binding and observation system that worked like a vir…

The default behavior for javascript interacting with the DOM is incredibly slow once the page gets complicated enough. I've certainly seen it first-hand. This may not be a problem you have, and indeed maybe not everybody needs react. But the problems things like react/vue/whatever solve (correctly or not) isn't imaginary.

Re: Virtual DOM is pure overhead (2018)

#224

Post by hopsoft »

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. And this just isn't a very efficient approach.

StimulusJS is a modern approach that uses the DOM to manage state. In my experience it has proven to be quite simple and performant.

https://stimulusjs.org/handbook/managing-state

Re: Virtual DOM is pure overhead (2018)

#225

Post by vijaybritto »

Udik wrote: post #192
WA wrote: post #185

Earlier quoted context omitted.

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

Though your opinion is mostly right, I think people are downvoting for the sentence "obviously the only same way to do things"

Re: Virtual DOM is pure overhead (2018)

#226

Post by prashnts »

underwater wrote: post #191
JMTQp8lwXL wrote: post #112

Earlier quoted context omitted.

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.

With the current release, you can use a hook, such as `useMemo`, which would memoize the value for the entire lifecycle of your component. I’ve been writing in react for around 3 years now, and never had to use shouldComponentUpdate, but instead compute whatever needed either on mount or when props changed. Curious what prompted the case you mentioned?

Re: Virtual DOM is pure overhead (2018)

#227

Post by spoiler »

tylerhou wrote: post #59
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…

> In my experience, as your app grows, the amount of time you spend on dom reconciliation becomes negligible compared to your own business logic. In this case, having a framework like React (especially with concurrent mode) will really help improve perceived user experience over a naive compiled implementation. In my experience, the exact opposite occurs. If there is ever any heavy computation I need to do, I usually…

Product/application growth doesn't necessarily mean the DOM grows, though.

Re: Virtual DOM is pure overhead (2018)

#228

Post by LandR »

Udik wrote: post #198
onion2k wrote: post #147

Earlier quoted context omitted.

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…

I've recentlt started working on a project where they store data / state in the ids of dom objects. Sometimes even something like dash separated strings that need to then be parsed.

I come from having done pretty much no Web development and this seems like a hateful way to do development.

Re: Virtual DOM is pure overhead (2018)

#229

Post by Bahamut »

namelosw wrote: post #18

I thought this was well known years ago. A better description for VDOM should be 'It's not fast, and is not slow either'. But frankly, what I see in virtual DOM is not about speed. It's a declarative interface, an abstraction. It's more like a blueprint that's easier to interpret across different environments like React Native, WebGL. Even if you don't need any of these cross-platform benefits it's still good for tes…

I work on one with React that is too slow in the browser with a team that only has senior devs, and users even filed bugs about the performance - we do heavy computations, and React's model of blocking rendering on having everything updated can freeze our UI for up to 10s while data comes in from various API requests. I believe our app would be performing much better for the end user if we were using Angular 2+ interestingly enough due to its built in incremental updating - there would be other tradeoffs though.

Part of the problem is not having good enough APIs currently (we have to make too many API requests and data payloads are too fat, sometimes up to 2 MB per request), but imperfect APIs tend to be the case in a lot of apps early in their lifecycle. I've actually been a bit disappointed in React's performance from a UX perspective.

Re: Virtual DOM is pure overhead (2018)

#230

Post by jordache »

namelosw wrote: post #67
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.

React is more like 'Lambda the Ultimate Web Component'. A component is almost a function returns element. Expanding a component is like calling a function and give it the property. So you can have some abstract common behavior in HOC f and g, then you can have HOC `h = compose(f(g))`. A quick comparison with Angular: @Component({template, style}) seems composable if we stretch a lot. But why make template and style i…

whether getting a component via a function call, vs an named export identifier (component class) - They have essentially the same net benefit over time.

A function that returns a component has no more reusability than a component class' identifier. That component itself has a very narrow use case of it being a UI component.

Post reply on HN