& what it's serving you in the end doesn't feel like it's heavy lifting in this day & age — a subject line & preview of your first N emails — I think the site could be much more responsive if they had a JS enhanced page (e.g. using it for their predictive text) rather than an SPA.
Page load time is one dimension. We get really hung up on it.
I'm always hazy on the term amortized, but my understanding of it was the opposite — in that, you should try to chunk up as much as possible. If you are using Gmail for a longer period, having to wait for functionality like advanced search or predictive typing is less annoying as the extra time you need to wait is a smaller portion of your session overall. Plus, these things may have lazy loaded by the time you come to use them.
On the other hand, if you just wanted to reference an email quickly — e.g. I often need to dip into email quickly, for example, if I've travelling and have booking confirmations / QR Codes / PNRs etc. in starred messages in the inbox — you'll notice any extra load time so much more.
So to me, feels preferrable to have as small as possible initial load time, then extra functionality progressively loaded in the background.
I do agree for something like Netflix for example that a 'big load up front' is probably preferrable. I'm 'in for the long haul' as I'm going to be watching something that's at least 30minutes up to a feature length film, so a few seconds extra load time is negligble.
I’m having trouble comprehending some of your sentences (there’s some running on going on). So I don’t understand what you mean by “waiting for advanced search” - is that better or worse in the multi page world? I think it’s worse. With an SPA, all of the UI navigation can happen on the client, which is as quick as possible (no server round trip). The actual searching in an SPA would be via an API and you get a nice spinner in the meantime, again with no page load. All smooth UI transitions which indicate to the user what exactly is happening. No blank page while a new page is computed without knowing what exactly is going on.
What I was trying to get at was that there are lots of "optional extras" that seem to get loaded up front at the moment that would be better if they were progressively loaded.
I think you see that a lot with SPAs in a way that you didn't when JS was used to 'progressively enhance' sites rather than for all interactions.
I don't think it's a problem of SPAs by definition — you could engineer an SPA to progressively load what's needed, and make the first load very slimline & then only load additional features while idle or on request, which is why I think GMail is a bad example. For example, I've just tried logging into Gmail in a fresh Firefox window (no cache) that I set to throttle to a "regular 3G" connection speed in the browser. It took literally 30s to load (with one email in the inbox).
Though it's more or less static feature wise, if it weren't for the updated logo you'd never be able to tell it was written within the last decade.
Yes, but a lot of the benefits of SPAs and the libraries needed to work on them accrue to the developers, not the users.
But I suppose you're right that the average developer is their own damn person with their own interests which can only ever partly align with their customer's.
I suppose there are actually three parties, all distinctly interested: the programmer, the employer, and the end user. The programmer wants to get paid and do "good work". The employer is actually a multipart entity: management and investors, each of which have distinct interests. The end user is not a single such person but a mass of individuals, each with a different set of interests.
This is getting messy!
Parents / caregivers / guardians and their charges, who can be further split in to children, teens etc etc.
You simply can’t do that with server rendering (barring hacks like Turbolinks, which are just approximating SPAs).
This is Google we’re talking about.
Does fit the caricature.
I believe there may have been some major changes to the way it did the client-side rendering a few years after it launched. The original version was more ad hoc, since it was pretty much the first time anyone (at Google, at least) had built a real SPA. Later they built tools and libraries, and developed a more systematic way of doing things. (I was at Google during that time period, but never worked on Gmail.)
The idea of an SPA is only strange in the web dev community. An SPA is equivalent to a native app client - they are long running, stateful processes that communicate with a backend. That architecture has worked for decades, and there are things that you can do as a result of having that stateful process that you simply can’t do with server rendering, like caching response data to share with totally unrelated view components later on in the application. You also get to use a real programming language to design your front end instead of living within a template language, which no one acknowledges as the biggest hack of all time. Template languages exist precisely because HTML is not a sufficient UI tool in all cases.