SPAs can be built to work well offline. I've written them myself. There is nothing inherent in an SPA that make it poor at this, quite the opposite. SPAs have excellent tooling for offline use.
A SPA's network dependency or robustness totally depends on the product's design. Some types of applications lend well to offline first (anything where the user owns their content/data, todo, notes, documents, pictures, etc). Others are much more dependent on fresh data. Which pretty much means anything big enough it's unreasonable to replicate it to the device.
I'm a fan of "offline first" design and have been a proponent at various companies. To the point where I can build the feature in at very little additional cost if it is considered and decided in the design phase. Bolt-ons patterns are messy.
However, the reality is that very few customers see this as a significant advantage. Which means that it doesn't really translate to market success. If budget is the #1 priority I can't in good conscience advocate for offline first unless it's going to offer a significant win for the company somewhere.
I’m asking this from a genuine place of curiosity, because last time I checked a few years ago the answer was “terrible”. Has the “save a file locally and load it again later” story for SPAs improved any?
I have implemented plenty of SPA (for years) that use the pattern of A) allow the user to download their current state as JSON/EDN and then B) allow the user to upload a new state from JSON/EDN file and continue from where they last downloaded their state.
This has been easy to implement for as long as I can remember, so not sure why'd you say it's terrible. What stopped you previous times?
Ok, so that’s kind of what I figured was the current state of things. Compared to being able to hit “Save” and have a local copy updated, that’s a pretty subpar workflow. I get why it’s like that (preventing a sandboxed website from being about to update files on the local filesystem) but...
A SPA's network dependency or robustness totally depends on the product's design. Some types of applications lend well to offline first (anything where the user owns their content/data, todo, notes, documents, pictures, etc). Others are much more dependent on fresh data. Which pretty much means anything big enough it's unreasonable to replicate it to the device.
I'm a fan of "offline first" design and have been a proponent at various companies. To the point where I can build the feature in at very little additional cost if it is considered and decided in the design phase. Bolt-ons patterns are messy.
However, the reality is that very few customers see this as a significant advantage. Which means that it doesn't really translate to market success. If budget is the #1 priority I can't in good conscience advocate for offline first unless it's going to offer a significant win for the company somewhere.
reply