The case for frameworks

Whilst I strongly agree SPAs are overused, let's take a moment to consider this sorry state of affairs. It's 2023 and when you ship some 50-200KB of executable code, you're in the red.

This is like 1/7th of a damn floppy disk, which I've lived through. Mobile apps are hundreds of MB in size, and we're supposed to compete with that using sticks and stones. Recently my Razor mouse had a driver update, it was 2GB in size. We learn about Unity on desktop, now able to render 17 trillion polygons per second yet we struggle to render some state and squares on the mobile web.

That's the real issue. Big parts of the mobile web are severely underpowered yet we still want to ship the "rich application" paradigm to them. Worse, without web standards offering anything remotely useful for this model.

That said, the idea that SPAs offer a superior experience that users are somehow demanding is bullshit when you consider how a typical SPA works. Consider a simple navigation action (route change) where the standard argument in favor of SPAs is that these are much faster compared to a traditional server-side page reload.

First, the SPA might need to load a new bundle, as tree shaking is the best practice where you lazily load per route code. This client code needs to be downloaded, parsed and executed, before anything even starts to happen. Next, the route-specific components mount. Many will require remote data, so at this point the page change may feel fast, it's useless and will remain useless until all remote network calls are resolved.

Compare this to a traditional, well-optimized MPA. You navigate to another route. The server will come back with ALL data/state resolved as well as all rendering (HTML) already done. And as this server response comes in, the browser is already working on the DOM layout/paint process, which is not true for a REST call. Plus, back/forward works reliably, scroll position works, memory leaks are no issue nor are stale tabs.

It's really debatable whether the SPA has the better experience or that users demand it. The point is to deliver meaningful content and interactions, that's the true value of whatever you are building. As such, I think the new wave of SSR/hybrid frameworks are a step in the right direction.

That path may or may not involve a framework. One common developer mistake is to use a framework not because it will save time, but because it's a brand name and they think it'll save them from having to learn about a particular problem space.

For example, any developer should be able to build a simple task queue in a couple of days. You can read about how they work, find a simple example or two, and code one. Will it have lots of features? No. Will it scale? No. Does any of this matter before you have product market fit? No.

Along the way you make sure you have good separation of concerns in your overall architecture, so that _if_ it turns out there are many actual humans who want to pay for this idea, you can swap out what you wrote and replace it with something better.

As a bonus, by the time this happens you'll understand task queues (and in particular what your product needs one for) very well. So picking and implementing the right framework will be easy.

If a framework is the easiest way to get to something the market can validate, use it! If it's not, don't.

It's really not that hard to understand how any of the common building blocks of a modern web app works. To understand it deeply, sure, that may take 20 years, but at PMF that depth is not critical yet.

Let's be honest - 80% of the time when we talk about doing things "right" we are really talking about concurrency and scale. Premature optimization is the root of all evil and so on...

This is the key right here. Very little else matters. Where a lot of companies get this wrong is they either go the route of picking a minimal framework and writing everything in-house only to have created a very unique monster that took a lot of time at the end or they go all in on frameworks without identifying the bottlenecks as they go along and they wait until its too late to make an easy transition.