Speed for who?

Frameworks are often touted as something like “a lightning fast development experience” and that’s fine I guess, but the speed is in the wrong hands. Why not “a lightning fast experience for your users”?

Sure, some frameworks will claim to be very fast for end-users with some very meticulously, massaged data to “prove” that, but as Zach points out in this great post, it means nothing when the output bundle sizes are astronomical off the bat:

Well, wait. When you’re straddling the divide, you know that Remix (67.7 kB compressed) and Next.js (90 kB compressed) have not meaningfully reduced their bundle sizes at all. Measurement reveals that bundles are growing: Next.js was 72.2 kB compressed in 2021.

I’ve always found the focus on developer experience as a framework feature uncomfortable. The focus is all in the wrong place: spoiled developers vs people trying to use your website/app. I personally think developer experience is one of the least important aspects.

When I’ve mentioned that before, I often get a response like “yeh but because developer experience is better, we can do good work for users, faster”, but I’m yet to actually see that happening. Instead I see fad-chasing, like single page applications (SPAs), blockchain and now “AI” like Copilot and ChatGPT…

If a framework actually came along with a pure focus on user experience and thoroughly optimised output—something like a 99% reduction in output JavaScript vs current frameworks—I would be interested. As Dave pointed out in this article, that goes against the new framework trend.

Only recently too, the head-honcho of Vercel—who are responsible for the monstrously large output generating framework—Next.js, tweeted this rather cryptic tweet:

I personally think this is broetry that really translates to “remember how we consistently said that SPAs are much better and faster than real HTML pages? Guess what, we were actually grifting our framework and now we’re going to go against that original grift with a different grift for the same framework”.

I dunno, maybe I’m being salty, but it’s justified saltiness. I actually genuinely care about users, you see. It’s why I constantly prattle on about progressive enhancement. Mainly, that makes everyone’s experience better, but the most important thing for me is that data is expensive.

Sure, if you’re based in San Francisco and you go to your adult daycare—sorry, I mean startup office—with ultra high-speed broadband: that 90 kB baseline compressed output might not feel like a lot, but what about if you live in Saint Helena? At the time of writing, a gigabyte of data there costs around $41 USD.

Your initial response to that might be “there’s a lot of kilobytes in a gigabyte”, and yes, you’re right, but there’s also a horrendous amount of framework-powered sites that could be HTML and CSS. Also, remember 90 kB is the framework’s default compressed output. Absolutely shoddy stuff.

You might also be tempted to say “our users only live in ‘developed countries'” (god I hate that term), but that’s like saying “all of our users are on desktop“. It’s also a piss-poor excuse for not building for everyone.

I guess what I’m winding up to say here is developer experience really isn’t important—especially when frameworks haven’t even got the absolute baseline experience anywhere near where it needs to be to service a world wide web. A world wide web that’s accessed with slow, expensive connections and cheap, underperforming hardware. How about taking a bit of “DX” on the chin to focus instead on “why are we using this framework that potentially excludes the majority of users?”.

As Alex says: a lost decade. I couldn’t agree with that sentiment more, to be honest.