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

311–320 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#311

Post by wildermuthn »

peterhunt wrote: post #153

I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flo…

“A constrained DSL” is precisely what is wrong with so many React alternatives. Anyone who had to deal with writing Angular 1 directives and fight with the digest loop understands how very real the pain is.

Also, there are two types of performance: how fast code runs and how fast a team can maintain and extend code. Does one optimize for running code or for building code? React won because it optimized for the latter. And thank god, because who wants to mess with digest loops and magical DSLs?

Re: Virtual DOM is pure overhead (2018)

#312

Post by nailer »

pcthrowaway wrote: post #222
nailer wrote: post #216

Earlier quoted context omitted.

Honestly I feel like anyone that hasn’t written Svelte by now isn’t an active front end developer.

State of JS disagrees

No it doesn't.

https://2022.stateofjs.com/en-US/libraries/tier_list

https://2022.stateofjs.com/en-US/libraries/front-end-framewo...

https://2022.stateofjs.com/en-US/libraries/front-end-framewo...

Re: Virtual DOM is pure overhead (2018)

#314

Post by AtlasBarfed »

mrtranscendence wrote: post #182
AtlasBarfed wrote: post #137

Earlier quoted context omitted.

I wish there was a "works for Pentium III" label that would help indicate that the app's usability hits necessary minimums on a 1Ghz Pentium III computer. IMO that would be a good optimization floor for avoiding the hidden monstrosity of electron apps and that type of stuff. If your McCrud app can't be responsive on a baseline 1Ghz PIII with 1GB of RAM, then there needs to be some sort of shame pushback. Moore's law…

Why Pentium III? That's nearly 25 years old. You couldn't run Windows 10 on such a processor, let alone a modern browser, and a $200 mobile phone would beat it in benchmarks. Surely you can have a higher floor than that.

The Pentium III was the around a half a gigahertz, and we were starting to get into multi-hundreds of gigabytes.

... that sounds small compared to today's specs, but IMO this is when PCs had plenty of horsepower to run "real" operating systems (32-bit preemptive multitasking), "real" browsers, 3D gaming was into it's fifth year or so, etc.

So this wouldn't be a badge where you say "wow we fit it into this impossibly limited device". The dirty secret of the PC business is that this hardware spec is more than enough for practically all productivity and browsing (and video with hardware acceleration). Now, high polygon high res high antialiased games... but that has actual hardware horsepower needs you can quantify.

The amount of wasted resources from the year 2000 to now is stupefying. Intel and AMD love it! DRAM makers love it! But as an industry we have squandered the last two decades (and the last two decades of CPU improvement), right as gigahertz scaling disappeared, Moore's law is probably going to collapse under its economic weight, Amdahl's law says parallelism won't save us forever.

So if I look at some software and wonder why this relatively straightforward app is hogging along on a PC that is effectively 10-50x faster than a Pentium III 500Mhz (8x-10x in clock speed, then massive improvements to cache, branch prediction, multiple ALUs, speculative execution)... something is wrong.

Re: Virtual DOM is pure overhead (2018)

#315

Post by traverseda »

randomdata wrote: post #227
traverseda wrote: post #192

Earlier quoted context omitted.

I presumed that you were talking about replacing the HTML with a wasm-rendered app, if you're just talking about replacing javascript with compiled javascript blobs, well we already do that general type of transpilation using tools like babel.

The original comment wasn't mine, but there was no mention of HTML anywhere. Where did that come from?

99% of the time WASM is being used right now it isn't being used to manipulate the DOM, and last time I checked the actual DOM bindings for WASM didn't really work.

There was no mention of HTML and right now no one is using WASM for html, so I assumed GP meant normal WASM type stuff, not theoretical WASM-dom bindings that I haven't seen anyone use yet.

Re: Virtual DOM is pure overhead (2018)

#316

Post by nwienert »

The5thElephant wrote: post #308
nwienert wrote: post #291

Earlier quoted context omitted.

No one believes the gospel of syntax, simplicity, and inline styles more than me [0]. I made that before Svelte was a thing and the Vue creator actually asked if he could borrow multiple ideas from that as he was making it. But idk what React codebases you've been in, the bog-standard, overwhelmingly popular bootstraps and guides since way before Svelte ever existed had some pretty nice style solutions and at the min…

> React has some of the most gorgeous style solutions around Can you give an example? > But idk what React codebases you've been in, the bog-standard, overwhelmingly popular bootstraps and guides since way before Svelte ever existed had some pretty nice style solutions and at the minimum importing CSS. Vast majority use Styled Components or another flavor of CSS-in-JS that continues the problem of making it harder fo…

Vast majority use CSS modules or tailwind.

Tamagui is explicitly React Native and Web focused so yea you don’t learn CSS as directly, but that’s the point as there’s no CSS on native. It’s not really relevant since Svelte doesn’t do native (big downside and shows why maybe CSS extremism is not helpful).

Re: Virtual DOM is pure overhead (2018)

#317

Post by randomdata »

traverseda wrote: post #315
randomdata wrote: post #227

Earlier quoted context omitted.

The original comment wasn't mine, but there was no mention of HTML anywhere. Where did that come from?

99% of the time WASM is being used right now it isn't being used to manipulate the DOM, and last time I checked the actual DOM bindings for WASM didn't really work. There was no mention of HTML and right now no one is using WASM for html, so I assumed GP meant normal WASM type stuff, not theoretical WASM-dom bindings that I haven't seen anyone use yet.

> 99% of the time WASM is being used right now it isn't being used to manipulate the DOM

Almost certainly. I would expect that 50% of WASM being used right now is outside of the browser entirely. Cloudflare Workers, for example. Same goes for Javascript.

Regardless, I expect the real serious answer is that writing raw WASM isn't particularly ergonomic. You could do it if you had to, but it is very much designed to be a compiler target. The OP was no doubt alluding to Javascript providing better developer ergonomics much like virtual DOM solutions have done over 'raw' DOM manipulation.

Reading the article he would have realized that Svelte offers much the same without a virtual DOM, and that the headline refers to that, but when was the last time anyone on HN read the article?

Re: Virtual DOM is pure overhead (2018)

#318

Post by traverseda »

randomdata wrote: post #317
traverseda wrote: post #315

Earlier quoted context omitted.

99% of the time WASM is being used right now it isn't being used to manipulate the DOM, and last time I checked the actual DOM bindings for WASM didn't really work. There was no mention of HTML and right now no one is using WASM for html, so I assumed GP meant normal WASM type stuff, not theoretical WASM-dom bindings that I haven't seen anyone use yet.

> 99% of the time WASM is being used right now it isn't being used to manipulate the DOM Almost certainly. I would expect that 50% of WASM being used right now is outside of the browser entirely. Cloudflare Workers, for example. Same goes for Javascript. Regardless, I expect the real serious answer is that writing raw WASM isn't particularly ergonomic. You could do it if you had to, but it is very much designed to be…

> The OP was no doubt alluding to Javascript providing better developer ergonomics much like virtual DOM solutions have done over 'raw' DOM manipulation.

Were they? Alternative interpretations abound. "Raw WASM" implies that they were sarcastically saying the virtual DOM makes things a whole lot easier, and if all you care about is performance you might as well hand write a bunch of assembly.

Another interpretation would be that the whole DOM is inefficient, so you might as well transpile some kind of native toolkit to a WASM engine.

There are a lot of different interpretations for that pithy sentence. Does raw mean written by hand or does it mean not using DOM bindings?

Re: Virtual DOM is pure overhead (2018)

#319

Post by mock-possum »

spankalee wrote: post #17

The key observation about HTML templates is that usually large portions of them don't change with new data. There is static content, and even with lots of dynamic bindings they're tied together in a static structure. So the vdom approach of processing all the static parts of a template during a diff is just extremely wasteful, especially for fairly common cases like conditionally rendering a node before some static c…

Good to see Lit called out here, I love the lit-html approach to using tagged template literals to define views.

Re: Virtual DOM is pure overhead (2018)

#320

Post by com2kid »

marcosdumay wrote: post #269
com2kid wrote: post #248

Earlier quoted context omitted.

Pretty sure PIII's beat P4s at a lot of benchmarks. :-D Thus why AMD is around today.

Well, I was using AMD at the time. AFAIK, the P4 faced badly on jump-happy code, but this was not common enough to be a problem on the real world when compared to a PIII. It was also a power hog, that could barely outrun a snail if you didn't have proper thermal management, but that also doesn't means the processor is slow.

I should have specified perf / watt. Pentium M's came and cleaned up compared to P4s, there was a fair bit of time there when, excluding massive power hungry desktop monsters, a beefy laptop with a Pentium M could easily beat an average desktop with a P4.

And IIRC pipeline stalls on the P4 hurt, badly.

Oh and RAMBUS, I had forgotten about RAMBUS. That also hindered the platform.

Post reply on HN