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

51–60 of 158 posts

Re: The browser's main thread is expensive

#51

Post by spockz »

jkhdigital wrote: post #22

This article concludes with the following statement: > So much of development is trade-offs, and you have to choose according to the situation, which ultimately comes down to the developer’s experience and judgment. It’s a great article, but I think it is a bit behind the ball in framing scheduling problems as a matter of “experience and judgment”. The problem of allocating work to a scarce resource is one of the old…

Well yes. But most of those studies assume/assert control over the environment. In this case you are running in the browser and you have to deal with the primitives it gives you. Both in compute management (threads/workers), communication (RPC, messages, shared memory, sockets), as scheduling (like having yield or not.

I’m not sure whether inventing a setup like green threads in JavaScript/workers would even be possible.

That is not to say that we should just forget about those learnings though.

Re: The browser's main thread is expensive

#54

Post by cafebabbe »

shevy-java wrote: post #30

So this is AI slop written? Why would anyone believe I'd want to read AI spam? Also, the issue I see is who controls browsers as much more profound. We need to find a solution here, as the browser is too important to allow private companies to keep mankind hostage. Edit: Wow, and the praise-accounts. Is that new on hackernews?

Honestly... i'm usually on the AI;DR bandwagon but this was actually good :/

Re: The browser's main thread is expensive

#55

Post by charcircuit »

prodigycorp wrote: post #42
mschuster91 wrote: post #21

> So what if off-screen posts were left as empty shells that only take up their height, and got filled with real content as they approach the screen? Yeah fuck everyone doing that, hello Reddit, Outlook for Web or Bluesky. It makes searching on such "feed" pages with the browser's search function an utter pain in the ass, made worse by the fact that the platforms' own search functions are outright braindead.

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.

Re: The browser's main thread is expensive

#56

Post by jcelerier »

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

Re: The browser's main thread is expensive

#57

Post by bob1029 »

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

Re: The browser's main thread is expensive

#58

Post by cryptonym »

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

It is a problem and plays a role, then the rest of the SPA interactions are as bad. Amplified by 100+ third party scripts.

Stop building SPA, go back to HTML. Re-assess every third party. For extra performance and scaling, implement cache. Relax and see web experience healing.

Re: The browser's main thread is expensive

#59

Post by phyzome »

prodigycorp wrote: post #42
mschuster91 wrote: post #21

> So what if off-screen posts were left as empty shells that only take up their height, and got filled with real content as they approach the screen? Yeah fuck everyone doing that, hello Reddit, Outlook for Web or Bluesky. It makes searching on such "feed" pages with the browser's search function an utter pain in the ass, made worse by the fact that the platforms' own search functions are outright braindead.

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.

Using a lighter weight DOM can help. There's always a point where it starts to bog down, but many pages are just unnecessarily heavy because they're relying on so many nested widgets and whatnot.

Re: The browser's main thread is expensive

#60

Post by amelius »

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.
Post reply on HN