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

141–150 of 170 posts

Re: The browser's main thread is expensive

#141

Post by locknitpicker »

Spivak wrote: post #127
paulddraper wrote: post #109

Earlier quoted context omitted.

Bad take. HTML is abysmally lacking for any interactive (which is what this article is about). Decades later, even something as common as a combobox is unsupported. EDIT: Downvotes but no argument.

It comes down the web browser being used for two different use cases and two camps arguing past one another. Documents vs Programs The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. You are rightfully pointing out that VanillaJS is insufficient to build software in the browser. Where I imagine you lose some people is that comboboxes can…

> The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity.

Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript frameworks boils down to arguing where the complexity should be in place A or B.

Re: The browser's main thread is expensive

#142

Post by mrguyorama »

simpleintheory wrote: post #101
pjmlp wrote: post #91

Earlier quoted context omitted.

At the same level, as a commercial game, not a tech demo scene.

I made a project a while back to port Minecraft's desktop version to the web and it runs decently-ish on a good computer with WebGPU (but takes a really long time to load) [1]: https://owlcraft.raymondjxu.net

This was functionally enabled by default by Minecraft being java, including the part where it was popularized by a java applet of a very early version.

That ran well back in 2012 on shit hardware.

Re: The browser's main thread is expensive

#143

Post by odo1242 »

econ wrote: post #137
odo1242 wrote: post #103

Earlier quoted context omitted.

Cooperative multitasking isn’t universally a bad idea (in fact, Rust supports it)

I can't think of a better way to make simple things billions of times slower than they should be.

I'm just going to borrow a sibling comment:

> afiori: JavaScript's execution model uses cooperative concurrency to avoid a tons of data races, preemptive non-parallel concurrency would make all web development incredibly harder

Re: The browser's main thread is expensive

#144

Post by pjmlp »

locknitpicker wrote: post #141
Spivak wrote: post #127

Earlier quoted context omitted.

It comes down the web browser being used for two different use cases and two camps arguing past one another. Documents vs Programs The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. You are rightfully pointing out that VanillaJS is insufficient to build software in the browser. Where I imagine you lose some people is that comboboxes can…

> The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript…

It comes from a server designed at CERN.

Re: The browser's main thread is expensive

#145

Post by Spivak »

locknitpicker wrote: post #141
Spivak wrote: post #127

Earlier quoted context omitted.

It comes down the web browser being used for two different use cases and two camps arguing past one another. Documents vs Programs The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. You are rightfully pointing out that VanillaJS is insufficient to build software in the browser. Where I imagine you lose some people is that comboboxes can…

> The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript…

Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites. Static site generators are just the dev-centric version of that. The more common situation is that you're generating pages on the server and shipping a massive JS bundle just to display what could have been rendered once.

But even given your position you see no difference between shipping the user a binary and shipping source code plus a compiler in terms of the user's experience? Surely the existence of server side react points to the server doing the initial lift being an improvement.

Re: The browser's main thread is expensive

#146

Post by locknitpicker »

Spivak wrote: post #145
locknitpicker wrote: post #141

Earlier quoted context omitted.

> The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript…

Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites. Static site generators are just the dev-centric version of that. The more common situation is that you're generating pages on the server and shipping a massive JS bundle just to display what could have been rendered once. But even given your position you see no difference between shipping the…

> Yes? Users often prefer a nice GUI but CMSs are effectively what you describe and run the majority of content oriented sites.

I don't think you understood my question. I stressed the fact that complaining about the complexity of a page implemented with a JavaScript framework is a red herring, because said complexity doesn't go away by moving it to a server.

And the old "dynamic HTML" approach is not easier to maintain and developm. By far.

In the meantime, what goes away is performance and perceived performance. Your dynamic HTML pages need to travel all around the world until clients see an update, and a page reload is far heavier and time consuming than doing a fetch to get data.

Try to ask yourself this simple question: why do software engineers bother with JavaScript frameworks? Do you think everyone has absolutely no idea about what they are doing?

Re: The browser's main thread is expensive

#147

Post by stickfigure »

sgift wrote: post #138
w29UiIm2Xz wrote: post #126

Earlier quoted context omitted.

There is no good technical solution for rendering on the server and upgrading to an interactive experience on the client.

Ignoring for a moment that most websites don't need any interactivity: Even for those that need it, for almost any of them something JQuery-like is more than enough. You really, really, really don't need the latest super big framework.

> most websites don't need any interactivity

I dispute this. I don't have any statistics either, but my subjective experience is that most websites are not like newspapers or blogs. Even shopping websites have pretty heavy interactivity these days.

Also, most boring pure-information-presentation problems are mostly solved by ancient technologies like wordpress. If you're working in web development in 2026, you probably aren't making static websites or blogs. You're doing something novel that probably has much higher interactivity demands.

Re: The browser's main thread is expensive

#148

Post by amelius »

afiori wrote: post #129
amelius wrote: post #60

Earlier quoted context omitted.

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.

JavaScript's execution model uses cooperative concurrency to avoid a tons of data races, preemptive non-parallel concurrency would make all web development incredibly harder

Yes, I was talking from a performance/UX standpoint.

Of course, doing everything in one thread most of the time makes everything easier, because you're using the thread as the lock, so to speak. But using locks is bad for performance and latency and thus UX.

Re: The browser's main thread is expensive

#149

Post by toast0 »

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

I was using a laptop with windows 10 and 4GB of ram and an anemic CPU a few times a month two years ago. Even with a fast network, a laptop with no ram is gonna be slow to browse, and bloated pages are gonna be slower.

It will certainly help to download the bloat faster, but you've still got to do all the hydration as OP put it.

Based on my experiences with windows 11, that laptop seems like it will be quite a bit worse than the one I was using, even though mine probably has a much worse cpu.

Re: The browser's main thread is expensive

#150

Post by fpoling »

Spivak wrote: post #128
fpoling wrote: post #73

Earlier quoted context omitted.

In London in many apartment blocks one can only get wired internet via an old copper cable with speeds like 80mbit/s download in theory but in practice it can be below 30 with ping in 50ms range and much slower upload. And 5g does not help either as the signal can be very weak.

Okay so that's no excuse for whoever is providing your internet, coax can deliver 800+ Mbps no problem. And if you are actually saying you only get DSL through a phone line in London then holy shit I would be busting down the door of my landlord. They never in the last half a century got wired for cable?!

A phone line from before WWII works fine to make a call but absolutely sucks for DSL.

And in London many buildings are declared as historic making it hard to get a permit for any work. The best chance is to wait until old pipes bursts and digging has to be done in any case to put fiber along the pipes.

Post reply on HN