No, I'm talking about back end processing cost. If the main page of the app has a significant server cost in the determining what data is being sent, being able to just redisplay the data you have when you browse back to the main page instead of request it again, which could incur that large processing fee, is a large gain.
As a simplisit ecanple, imagine an app which on login has to do an expensive query which takes five seconds to return because of how intensive it is on the back end. If you can just redisplay the data that's already in memory on the client, optionally updating it with a much less expensive query for what's changed recently, then you're saving about five seconds of processing time (and client wait time) by doing so.
Yiu could use localStorage to do something similar without it being a SPA, but that's essentially opting into a feature that serves a similar need.
Client side caching is a strong point of SPAs, so it makes sense that a use case that can leverage that heavily will have benefits.
I find it hard to really agree that the backend of Gmail would be more involved with a thinner frontend. The "low bandwidth html" version sorta gives the lie, there...
I'm not sure what you're getting at. I'm not talking about bandwidth usage at all. I'm talking about CPU, memory and IO (as in disk, not client server transfer) usage.
I'd wager all of those things are still lower on their "low bandwidth" option.
Now, I will grant that it does less. Probably lacking a lot of the "presence detection" that is done in the thick client. Certainly lacking a lot of the newer ad stuff they are pushing at.
But the rest could be offset by a very basic N-tier application where the "envelope" of the client HTML is rather cheaply added to any outgoing message. And the vast majority that goes into "determining what data is being sent, being able to just redisplay the data you have when you browse back to the main page instead of request it again, [etc.]" will probably be more identical than not between the options.
Now, I grant that some of the newer history API makes some tricks a bit easier for back button changes to work. Ironically to the point, is that gmail is broken for back button usage. So... whoops.
> I'd wager all of those things are still lower on their "low bandwidth" option.
I would argue that Google has thrown a bunch of engineering talent at it to optimize the problem as much as it can be for a web interface, and that Gmail is a bad example of a a SPA mail client, as it's more a combined mail client and IMAP server (really a custom designed mail store) all rolled into one. Whether Gmail itself really uses more or not is somewhat irrelevant to whether a mail client in general leans into the benefits a SPA provides. This is what I was talking about here.[1]
That said, whether it uses less resources is a tricky question. Sometimes there's algorithmic wins that overall reduce the total work done, and I don't doubt Gmail leverages some of those, but it's also just a huge amount of caching, whether in the browser or in a layer underneath. The benefit of a SPA is that you can customize the caching to a degree for the application in the client without having to have an entire architectural level underneath designed to support the application. For anything at scale, having that layer underneath is obviously better (it's custom fit for the needs of the application and isn't susceptible to client limitations), but it's also very engineering intensive.
My guess is that Gmail puts a very large amount of cache behind most requests, and is just very, very good about cache invalidation. Or they've got the data split across many locations so they can mapreduce it quickly and efficiently (but tracking where those places are will necessitate some additional resource usage).
In the end, you need caching somewhere. You can do it on the server side so that you have full control over it but you have to pay for the resources, or you can do it on the client side with some limits on control and availability, but you don't use your own resources. SPAs make client side caching more reliable in easier to deal with in some cases, because the working state of the client isn't reset (or mostly reset) on every request.
As a simplisit ecanple, imagine an app which on login has to do an expensive query which takes five seconds to return because of how intensive it is on the back end. If you can just redisplay the data that's already in memory on the client, optionally updating it with a much less expensive query for what's changed recently, then you're saving about five seconds of processing time (and client wait time) by doing so.
Yiu could use localStorage to do something similar without it being a SPA, but that's essentially opting into a feature that serves a similar need.
Client side caching is a strong point of SPAs, so it makes sense that a use case that can leverage that heavily will have benefits.