Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The browser's main thread is expensive

kciter.so

Post reply on HN
Print view View original

61–70 of 154 posts

Re: The browser's main thread is expensive

#61

Post by fassssst »

charcircuit wrote: post #55
prodigycorp wrote: post #42

Earlier quoted context omitted.

what's your solution to the performance hit that you get when you load up the dom with a zillion things? long, unvirtualized threads will bring every decent computer to its knees. the sites could implement their own search to make it all work if they wanted to. they just dont. but blaming virtualization is not tit.

The solution is to improve the browser to remove the performance hit. Modern computers are extremely powerful so there is no good reason why they would not be able to handle a zillion things in the DOM.

A zillion things is more than a zillion bytes of RAM :p

Re: The browser's main thread is expensive

#62

Post by fxd »

martinald wrote: post #49

Good article and I wish this was much better known. The issue is though that it's too focused on interactivity. In reality, 90%++ of slow sites are not slow because of interactivity really, they are slow because they ship enormous react/nextjs bundles and have extremely heavy hydration work to do. _so many_ sites have bundles >10MB that need to be downloaded, parsed and hydrated. I've even seen (many) sites which hav…

Why would a regular React site be so huge?

Maybe they had bundled fonts and images.

The bundle is just the lib plus your files minified.

You want to bundle vs hitting dozens of requests just to get files.

It’s not like React/webpack is a black box doing things I don’t know or want.

Performance: I challenge you to build a complex 3D game in vanilla threejs vs using r3f. useFrame alone is worth it

Re: The browser's main thread is expensive

#64

Post by mr_toad »

charcircuit wrote: post #55
prodigycorp wrote: post #42

Earlier quoted context omitted.

what's your solution to the performance hit that you get when you load up the dom with a zillion things? long, unvirtualized threads will bring every decent computer to its knees. the sites could implement their own search to make it all work if they wanted to. they just dont. but blaming virtualization is not tit.

The solution is to improve the browser to remove the performance hit. Modern computers are extremely powerful so there is no good reason why they would not be able to handle a zillion things in the DOM.

The browser can easily handle millions of calculations and then render a million DOM elements so quickly that you won’t even notice it. The problem is when you try and do this hundreds of times very second.

The irony is that obsessing over smoothness and frames per second is what causes this in the first place.

Re: The browser's main thread is expensive

#65

Post by RetroTechie »

jcelerier wrote: post #56
martinald wrote: post #49

Good article and I wish this was much better known. The issue is though that it's too focused on interactivity. In reality, 90%++ of slow sites are not slow because of interactivity really, they are slow because they ship enormous react/nextjs bundles and have extremely heavy hydration work to do. _so many_ sites have bundles >10MB that need to be downloaded, parsed and hydrated. I've even seen (many) sites which hav…

I challenge you to browse the web one week on this laptop part of the current top 10 Amazon best sellers on a gigabit fiber connection and tell me if you still think that this is the problem: https://www.amazon.com/HP-Everyday-Processor-Microsoft-Porta...

Please don't brush off parent's "slow connection". Many people are stuck with that.

A prime example: cookie dialogs. On a slow connection, page loads, large parts are rendered, and you start reading. After that, some script starts to present a cookie dialog, and everything freezes. Page doesn't scroll anymore, buttons don't work, sometimes a previously-readable page is darkened or otherwise obscured so you can't keep reading while this goes on.

Then a whole bunch of stuff is downloading, which (again: "slow connection") takes forever. Like 20s+. Halfway through you see "accept / reject / settings", but none of those buttons respond (except the dark pattern where "accept" often works faster or smoother than either "reject" or "settings". Aaargh!). When things respond again, consider yourself lucky when page re-renders as before.

Which also runs afoul of 1 of my pet peeves with user interfaces: DO NOT PRESENT A UI ELEMENT UNTIL CODE TO PROCESS ITS USE, IS PRESENT IN MEMORY & READY. Really simple right? Yet I see examples ignoring this oooften.

A 'slow' CPU, low RAM/swapping etc just makes this worse. Web developers tend to have fast machines & connectivity so they may not even be aware of this. Or think it's a non-issue even though it affects many users - existing or potential.

Re: The browser's main thread is expensive

#66

Post by pjmlp »

martinald wrote: post #49

Good article and I wish this was much better known. The issue is though that it's too focused on interactivity. In reality, 90%++ of slow sites are not slow because of interactivity really, they are slow because they ship enormous react/nextjs bundles and have extremely heavy hydration work to do. _so many_ sites have bundles >10MB that need to be downloaded, parsed and hydrated. I've even seen (many) sites which hav…

99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.

Re: The browser's main thread is expensive

#67

Post by pjmlp »

fxd wrote: post #62
martinald wrote: post #49

Good article and I wish this was much better known. The issue is though that it's too focused on interactivity. In reality, 90%++ of slow sites are not slow because of interactivity really, they are slow because they ship enormous react/nextjs bundles and have extremely heavy hydration work to do. _so many_ sites have bundles >10MB that need to be downloaded, parsed and hydrated. I've even seen (many) sites which hav…

Why would a regular React site be so huge? Maybe they had bundled fonts and images. The bundle is just the lib plus your files minified. You want to bundle vs hitting dozens of requests just to get files. It’s not like React/webpack is a black box doing things I don’t know or want. Performance: I challenge you to build a complex 3D game in vanilla threejs vs using r3f. useFrame alone is worth it

What a joke of challenge, there is still no browser 3D game that is a match to Infinity Blade, that Apple used to demo OpenGL ES 3.0 hardware in 2011.

Anyone serious about 3D gaming on the Web has to do streaming.

Re: The browser's main thread is expensive

#68

Post by pjmlp »

amelius wrote: post #60
martinald wrote: post #49

Good article and I wish this was much better known. The issue is though that it's too focused on interactivity. In reality, 90%++ of slow sites are not slow because of interactivity really, they are slow because they ship enormous react/nextjs bundles and have extremely heavy hydration work to do. _so many_ sites have bundles >10MB that need to be downloaded, parsed and hydrated. I've even seen (many) sites which hav…

Since at least Windows 3.1 we all know that cooperative multitasking is a bad idea. But we see a lot of developers use it, even Rust developers who should know better.

It predates Windows 3.1.

Re: The browser's main thread is expensive

#69

Post by vbezhenar »

This mistake gets repeated over and over again, in every single GUI framework of any kind. I don't understand why does it have to be that way.

Just use multi-threading. Run each library in a separate thread. Use actors approach to pass data between libraries, application and finally to submit data to update GUI.

Using single thread for everything and expecting that developer will create separate threads for heavy work is obvious approach, but it never worked. Developer doesn't care. And user gets inferior experience.

Re: The browser's main thread is expensive

#70

Post by bee_rider »

bob1029 wrote: post #57

If you are currently trying to build a web-based clone of something approximating ChatGPT, pretty much everything in this article is absolutely mandatory. The streaming response UI/UX is a total nightmare to make work smoothly. You have to come up with clever heuristics around where to chop up the stream of changes and how to batch the work relative to frame updates to make it not look like confetti during a streamin…

I really don’t understand why the LLM web chat clients have all converged on this UI where one character appears at a time. It is kind of fun the first time (like you are watching some Harry Potter special effects where an enchanted book writes itself). But really they could send sentence or paragraph long chunks of text, it would be fine.

Seems like an artifact of the time when tokens-per-second were low enough that people needed to be informed that the machine was actually doing something.

Post reply on HN