Live data from Hacker News

Virtual DOM is pure overhead (2018)

svelte.dev

111–120 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#111
post #30

Yes and no. Having implemented virtual DOM natively in Sciter (1), here are my findings: In conventional browsers the fastest DOM population method is element.innerHTML = ... The reason is that element.innerHTML works transactionally: Lock updates -> parse and populate DOM -> verify DOM integrity -> unlock updates and update rendering tree. While any "manual" DOM population using Web DOM API methods like appendChild(…

Thank you for your work on Sciter.

Wanting to use it on a new project soon. Love it over some complicated and bloated Electron solution.

Re: Virtual DOM is pure overhead (2018)

#112

Earlier quoted context omitted.

Inferno was one of the first frameworks to embrace compiling JSX as an opportunity for advanced performance. the `$HasTextChildren` is a special attribute their JSX compiler (its a babel plugin) uses to optimize the tree at that point in time the that flag is found. It can do advanced optimization knowing that the children of that component are purely text VNodes. There are other flags available too that optimize dif…

> Even SolidJS hasn't quite crept the performance Inferno has managed to achieve. I see Solid to the left of Inferno in that benchmark, though they are very close indeed. Solid's code looks weird in its own ways I guess, but it looks less hacky/hand-optimized to me. Inferno seems to use less memory though, which seems interesting. Solid isn't fully memory optimized though, it could beat Inferno with more memory optim…

Yep, Solid is among the fastest but requires more cognitive overhead.

Svelte requires very little over and above HTML and JS while still being closer to Solid in performance than React, Vue, or Angular.

And the latest interactions of React and its ecosystem have both high cognitive overhead AND lackluster speed. At least Angular is opinionated. React is just a YOLO ball of yarn for large codebases.

Re: Virtual DOM is pure overhead (2018)

#113
post #36

Earlier quoted context omitted.

> They are all fast I would say they all can be fast. But try browsing the web on a low end Android device and tell me all sites are fast. To my mind the differentiator is how easy a framework makes it to shoot yourself in the foot. And React makes it very easy to re-render a huge swathe of your app when you've only changed one tiny element. React also needs to hydrate every element even when it isn't ever going to c…

There are problems that have to do with the systems built on top of React if not React itself. It is not unusual at all to find some "simple" UI update causes the render() method to be called 20 times. You might blame the application developer for this but other than "keep all the state at the top level of the application and pass it down in props", React doesn't provide a systematic answer for handling state in apps…

> React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways.

The built-in React way of doing that is with context.

Re: Virtual DOM is pure overhead (2018)

#114
post #5

Inferno.js uses VDOM https://github.com/infernojs/inferno and is faster than Svelte according to these benchmarks https://krausest.github.io/js-framework-benchmark/2023/table... . Sooo, VDOM can improve performance?

Solid.js is even faster than inferno, and it doesn't really use a VDOM strategy, uses a strategy much more like svelte. IMO svelte is just poorly implemented from a benchmark perspective.

In reality, most of these benchmarks are not meaningful when talking about real app performance. What's meaningful is how you do global state updates in your app. If you use a react app with react-hook based context providers that unnecessarily update hundreds of components on simple changes, you perf is going to suck. If you use a react app and don't use React.memo anywhere, perf is going to suck. If you use react very carefully and are fully aware of when the vDOM is going to run and use small components that only update when their data actually changes, and ideally avoid running vDOM 60 - 120fps a second for animations, performance is going to be good.

I like Solid.js because it does all this for you by nature of just using the framework. Svelte does some of this for you so for real world apps performance is likely to better than react, but it doesn't do it as well as Solid by nature of it's state management strategy, not by nature of it's DOM update strategy.

The less you update, the faster your app will be. Then the DOM diffing strategy doesn't matter.

Re: Virtual DOM is pure overhead (2018)

#115
post #2

So is the JS runtime. So why don't we just write apps in raw WASM?

The translation layer of calling a web assembly function from javascript is a bit heavy, at the moment. And you have concerns around modeling a flat memory space with pointers, so it can be greedy on memory use. That said, I wouldn't be surprised if this is where the industry moves 5-10 years

I guess the sarcasm was too thick.

My point was that yes, VDOM has overhead. But we accept it as a tradeoff for app development in the name of DevX.

Re: Virtual DOM is pure overhead (2018)

#116
post #30

Yes and no. Having implemented virtual DOM natively in Sciter (1), here are my findings: In conventional browsers the fastest DOM population method is element.innerHTML = ... The reason is that element.innerHTML works transactionally: Lock updates -> parse and populate DOM -> verify DOM integrity -> unlock updates and update rendering tree. While any "manual" DOM population using Web DOM API methods like appendChild(…

If you use dom fragments, in recent browsers, it's up to par.

Re: Virtual DOM is pure overhead (2018)

#117

Earlier quoted context omitted.

I don't get it. JSON+LD is not Javascript. It's not even spelled the same? If you are meaning that your Javascript is able to read JSON+LD, so too could you WASM in this hypothetical world we're talking about.

JSON is literally JavaScript Object Notation, my friend.

Which, humorously, isn't compatible with Javascript object notation. { foo: "bar" } is a valid Javascript object, but not valid JSON.

Regardless, I don't get what you are trying to say. Pretty much every language still in existence is able to work with JSON (even SQL!). JSON is not Javascript. It's not clear why moving code from the Javascript runtime to the WASM runtime would magically make JSON+LD inoperable or whatever it is you are trying to say.

Re: Virtual DOM is pure overhead (2018)

#118
post #87

Earlier quoted context omitted.

Just have a suspendLayout resumeLayout / beginUpdate endUpdate method like Winforms surprised doesn't exist after all these years

Not so easy unfortunately. 1. BeginUpdate stops a control from repainting itself and that is what browser is doing already - no painting happens at the moment of JS execution. So primitive "postpone painting" does not really help. 2. element.update(callback) or DOM.mutate(root,callback) shall be a single method - no one wants EndUpdate() calls to be skipped because of errors thrown and the like.

A script will eventually return to the event loop, where endUpdate() may be called automatically. You don’t even need beginUpdate(), because it may be hidden behind update methods.

Every time I read about DOM I frustrate about how many frontend issues are there due to just bad platform-level patterns. We’re long past the need of reflecting updates auto-instantly in a single call to the engine. And that wasn’t even necessary before.

Re: Virtual DOM is pure overhead (2018)

#119
post #27

Js frameworks are also pure overhead. I have never seen any benchmark where they have ever been better than vanillaJs. /s

There's no real benchmark for developer experience. Performance only matters up to a point. And it depends what you're building. If you're building pages where people just read content - sure - server render + vanilla js it. If you're building something more interactive where you think you'll have greater than 50k lines of JS prepare for pain. Last note - picking the right tool for the job is a quote we repeat often…

Yep, that's my point. The abstractions are a means to an ends. And are worth their overhead in many cases. So calling them pure overhead, for sake of performance, is absurd as calling js framework as pure overhead

Re: Virtual DOM is pure overhead (2018)

#120

And having a custom JS compiler isn't pure overhead?

Are you calling a C compiler overhead as well? Ahead of time compilation is not runtime overhead, and for users of the web, runtime and network latency are all that matters with regard to the perception of speed.
Post reply on HN