[skylark]

The "website obesity crisis" is related to the rise of single page applications and the growing popularity of frameworks like React, Vue, and Angular.

Having worked on many SPAs in my career, I've noticed a similar pattern which has happened on essentially every project I've worked on. I call it the SPA descent into madness.

Initially, a SPA is probably the fastest way to start prototyping a UI. You don't even need a server - just throw some HTML, CSS, and JS onto the page, add some mock data, ReactDOM.render, and you're off to the races. All of the UI logic is handled by your frontend framework, and the backend exposes an API the frontend interacts with. Peachy.

But every non-trivial project hits an inflection point where things start to get tricky. In a classic server rendered website (e.g. Ruby on Rails, Django, etc.) you can add as many features as you want because the size of the server binary doesn't really matter. This isn't the case for SPAs - every feature and every additional dependency bloats the size of the JavaScript bundle.

To combat this, developers do route-based code splitting, but oftentimes this isn't sufficient - critical pages usually have the most features stuffed into them, which means they can't be reduced in size enough. Server side rendering can be effective, but now your data model needs to exist on both the client and server, so hopefully you took this into consideration. If not, it's common to run into situations where your application's model layer is partially duplicated across your client and server.

Are all of these problems solvable? Sure. There are great, performant SPAs with millions of lines of code. But let's be real - most organizations wont solve these problems due to lack of engineering ability, time, or politics. The path of least resistance with SPAs is to shoot yourself in the foot on performance, so that's what tends to happen. It's the reason you see these insane 3MB bundles on text based webpages. They started with good intentions, but never got the love necessary to make a large SPAs work well.

All this to say: Make sure you're picking the right tool for the job. SPAs have a low upfront cost, but can have unexpectedly high long term costs. A sprinkle of JavaScript on top of a server rendered page, with a few tricky components backed by a light framework like Inferno, Mithril, or HyperHTML, is oftentimes all that's needed.

[onion2k]

The latest version of React[1] + React-DOM[2] is approximately 32Kb gzipped. If SPAs are bloated it's not due to React.

[1] https://bundlephobia.com/result?p=react@16.5.0

[2] https://bundlephobia.com/result?p=react-dom@16.5.0

[skylark]

You're absolutely right - SPA bloat isn't directly due to the weight of the underlying frameworks.

I think what I was touching on more was the fact that SPAs generally encourage engineering practices which lead to more complexity and page bloat, and that many teams don't think about these maintenance difficulties when initially picking their tech stack (as proven by the number of bloated, slow SPAs on the internet.)

A well engineered SPA won't suffer from the issues I outlined in the original post, but getting to that point has a non-trivial cost which has to be considered. As usual, it's all about picking the right tool for the job - teams need to make sure they're getting a net benefit from using this sort of application architecture vs. a server oriented one.

[ktosobcy]

And... what problem do they solve? They create an application which you have to download over-and-over again instead of providing downloadable application which starts quickly. Then there is a boatload of problems (how to store data, how to refresh data) and then reinventing technologies to solve those problems that didn't exist in the first place. Supposedly the benefit is being portable and "independent" therefore we are required to install Chrome everywhere.

I recently toyed a bit with JavaWebStart and JavaFX and... this is quite nice actually - it allows easily distribute portable applications, that look good (IMHO) and they are cached well (or you can provide normal binary to download). And quite often they are smaller. The problem is - Java got this label of "slow and bloated" but nowadays Java apps are way snappier and start faster (and they are smaller) than JavaScript SPAs…

[pjmlp]

Another way to prototype UIs for the majority of typical web applications is just to use a CMS.

Most of them still rely on server side rendering instead of SPAs.