Comment by martinald
20 hours ago
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 have multiple SPAs stacked inside of them.
If you're on a slow internet connection and/or CPU the page is basically unusable for many tens of seconds and no amount of yielding post bundle hydrate will really solve that.
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.
5 replies →
I expect soon each website will have its own browser, compiled as WASM which will be launched in order to render the JavaScript and HTML on the website.
Basically Flash 2.0.
This is actually plausible as a way to prevent adblock.
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.
4 replies →
Hence CSS.
> 99% of the time those sites could be plain HTML and CSS
Some of that css and html doesn't run reliably and consistently on all browsers. A visit to sites such as canIuse helps build up an idea of the extent of the problem.
Also, you seem to ignore the fact that JavaScript frameworks use said html and CSS extensively, and provide the necessary abstractions to bridge the unreliability gap in addition to introducing features that html and css do not support.
What I really find funny about this issue is the fact that this type of claim implies that virtually all software engineers who for some reason aren't html+css purists are utterly incompetent and completely unable to assess any technical tradeoffs. Imagine yourself walking around with the belief that an entire field is manned by people who don't have a clue about what they are doing.
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 on freeing up the main thread because there's such a wide variety of approaches and many of them may not be obvious.
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 brand consistency. But it's many MBs of JS, because it has to cover every possible use case.
This doesn't even get into 3rd party vendors who _also_ ship react et al and have other bundles.
I'm not saying the article is wrong, but if you want to free main thread time especially at the most critical point (when the user has initially loaded the page) you _probably_ will find that most of the opp is in bundle size and hydration improvements.
I would think, or hope, a UI library like that could benefit from webpack and tree shaking such that only the needed components end up in the final bundle.
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.)
1 reply →
NoScript is a remedy for this. When a site is broken I whitelist a few domains likely to be necessary. After a few attempts I bounce. If I see a dozen plus domains I don't even bother. This cuts down on the volume of garbage sites I waste time on and shields me from novel trackers not on any block list.
The web is much faster when useless JS is taken away.
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.
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.
There's definitely trade-offs. I actually prefer a proper SPA to pure HTML when on a slow connection and interacting with a site a lot.
Especially when trying to buy something. I much prefer to have a longer initial load and then have everything just work instead of waiting as I navigate between pages, the multi stage checkout, confirmation etc.
But yeah, if I'm just trying read a single article on a blog, preloading everything is pointless. A hybrid site with the initial page being server side rendered + progressive enhancement afterwards is theoretically optimal in my opinion.
1 reply →
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.
Try 10mbit/s down for a copper connection 30 min drive from Auckland (NZ) CBD Thank God for StarLink and other wireless options.
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?!
2 replies →
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.
> 【Processor】AMD Processor
> 【Graphics】 Intel Graphics
And this is why you don't buy laptops from Amazon. At best, the seller has no idea what they're doing, at worst, this is fraud.
my point is that as programmers we have to take into account that the average human today has a computer that likely struggles to open Win11 notepad. I don't buy random laptops from amazon, but an astonishingly high amount of people do and we have to work with that
Try it yourself on a gigabit internet. Put CPU throttling in devtools to 10x slowdown (assuming you have a fast computer) and see how fast it is even with super fast internet.
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.
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.
9 replies →
ES 2.0
1 reply →
[flagged]
1 reply →
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.
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.
2 replies →
You are saying it as if there is some logical consequence.
1 reply →
It predates Windows 3.1.