JavaScript hydration is a workaround, not a solution

Slight nitpick, the equivalent for Google Docs would be Pages, and the equivalent for Numbers would Google Sheets.

i'll bet there is a possibility that resource heavy JS software "wastes" more energy than cryptocurrency

But not everything is a black or white good/bad fit for an SPA, and you don't always know upfront...

Building a list of blog entries? Sure, it doesn't need to be an SPA. Add a tag filter? Still doesn't. Then you eventually need more complex filters (by author, dates, whatever), plus a text filter, plus thumbnails, plus maybe a gallery view of the photos, and maybe you want all of that with realtime clientside filtering... hmm. You can rip out that part of the static HTML and make it a drop-in widget.

But what if you need to tie that into the logged-in state of the user to determine what they can see? Or you want to integrate comments and facilitate real-time discussions?

Having a split backend/frontend rendering system like that makes it pretty hard to reason about (it's how a lot of PHP sites were built, for example, with serverside HTML and a sprinkling of clientside JS, but coordinating the two gets tough with ugly hacks like using `window` or `data` props to pass variables to the client).

Ecommerce? You can build it entirely backend, entirely frontend, or some hybrid of the two. Look at a random Shopify example: https://nomz.com/ (suggested by their website, not sure if real) and a Next.js example (https://demo.vercel.store/product/quarter-zip). Try browsing around and looking at different products. The Next version is pretty much instantaneous while the Shopify version is slow and requires a full page load for any navigation.

Another example from a decade or so ago was the "real" desktop Gmail vs the light/mobile (and maybe WAP?) versions of Gmail (maybe still available at m.gmail.com). They both did the same basic things, but the desktop version was a lot faster, featureful, and usable once you let it load for 5-10 seconds at first. The light version shows you the inbox really quickly but then subsequent actions (navigating to a message, replying, etc.) are actually slower than the SPA version.

Even for just a moderately complex site, an SPA model can be slower upfront as it downloads a bunch of JS but then faster after that, speeding up all the subsequent interactions (with JSON content loads instead of full HTML pages, auto-detected image sizes, smart prefetches based on state, etc.).

AND it doesn't require a rewrite once your site gets "complex" enough. You can start with a simple SPA that may be overkill at first, but keep growing it organically and adding complexity without dramatically increasing the bundle size (with proper tree shaking, etc.) since the bulk of it was the framework.

With traditional serverside HTML sent to the client, yes a simple individual page may be smaller, but you quickly lose that benefit as you keep sending the header, footer, etc. on every page load, while still needing some sort of JS management system for the interactive parts.

For all but the very simplest site, that means you sacrifice a lot of the developer experience for a minor increase in performance. The user also loses out if you start thinking in terms of "how do I add interactivity to my dumb HTML" instead of "what's the best UI for this".

Safer (and usually better) to just start from an SPA unless you absolutely know upfront your site is going to stay really simple. It's a lot easier to optimize an SPA for better performance than to rewrite a hybrid backend/frontend rendering stack and migrate architectures, etc. (i.e., Jamstack over LEMP/Drupal/Wordpress/Rails)

> Yes when you open a desktop app that has to load the data from the internet it has to load first... You can't get around that fact unless you have zero data remote? Which defeats the purpose of a collaborative B2B app.

This could be true for data being loaded from the Internet, yes, though it assumes the premise that JS based applications will still do this faster. However, collaborative B2B apps existed before the JS craze and worked perfectly well (and faster) without it. They also don't strictly need to be querying data from the broader 'net but can be doing things like talking to a local database server, asynchronously retrieved local cache, etc.

> After that first load, strictly the first time you open the app, you never see another loading screen.

That's actually only half true. The "Loading" screen does indeed not popup. Instead, you just get broken empty UI until it eventually loads the record. What I observed was scrolling to the end and selecting any of the final few records there was a substantial and noticeable second-plus delay loading the record data into the view. Steps are: Load page -> scroll to very end using scrollbar -> pick last record.

For fun, I profiled it. According to the profiler it takes 3.8s for it to successfully load and process the record, of which 2.1s is just in one promise.

It's also a demo site and could easily cheat this (but to their credit appears as though they are not quite doing so at the expense of heavier page loads). It's not a compelling example of what you're talking about.

Rewritten as a horror story:

> COO invents cache invalidation