Live data from Hacker News

The browser's main thread is expensive

kciter.so

121–130 of 167 posts

Re: The browser's main thread is expensive

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

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

You are saying it as if there is some logical consequence.

Re: The browser's main thread is expensive

#122
post #105

Earlier quoted context omitted.

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

Which, again, aren't Infinity Blade graphics. Kudos on the work though.

[dead]

Re: The browser's main thread is expensive

#123
post #91

Earlier quoted context omitted.

https://playcanv.as/p/MflWvdTW/ This isn't new at all, just one of the first things I found by googling "webgl demo." WebGPU of course goes even further. I think the real gap is just that people by-and-large aren't building real games on top of Safari. It's more lucrative to use the app store with its low-friction payment system.

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

[dead]

Re: The browser's main thread is expensive

#124
post #105

Earlier quoted context omitted.

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

Which, again, aren't Infinity Blade graphics. Kudos on the work though.

[dead]

Re: The browser's main thread is expensive

#126
post #66

Earlier quoted context omitted.

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.

>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. That is because the latest framework always fixes everything that wasn't broken before.

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

Re: The browser's main thread is expensive

#127
post #66

Earlier quoted context omitted.

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.

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 be done natively with the datalist attribute.

Re: The browser's main thread is expensive

#128
post #73

Earlier quoted context omitted.

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

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?!

Re: The browser's main thread is expensive

#129
post #60

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.

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

#130

Earlier quoted context omitted.

The article acknowledges this in the very first paragraph: > For most of us it’s things like reducing network requests, shrinking the bundle, or making good use of the cache. These are likely going to be your first port of call for performance issues at your day job, but fixes like removing dependencies or making fewer network calls are pretty straightforward. I think the author chose to do a deep dive on the topic o…

I'm not sure the author realises _what_ a massive impact bundle size has on the main thread though, especially hydration. The majority of apps I've optimised over the years have the (often vast) majority of main thread time spent on the bundle parse/hydration (plus obviously network). Also, removing dependencies is not easy. I've seen many corporate that have a huge UI lib for example that everyone should use for bra…

All good points. Perhaps rather than saying the fixes are straightforward, I should have said it's a straightforward concept to understand. If your app takes forever to load because of a huge bundle, you need to figure out how to make the bundle smaller, somehow. (How exactly to do that is where it gets complicated, like you say.)
Post reply on HN