An SPA is significantly more complicated on the client side in exchange for some purported benefits, especially to the user (such as only downloading what you need). It's holding SPAs to a reasonable expectation for SPAs. I don't think it's holding SPAs to a higher standard.

(Apples platform, Apples riles one might say but as far as I have seen so far they didn't break any of the rules, so even by that rule Apple is in the wrong here until they change their rules to add something tvat allows them to do this.) Just because one is mostly nice doesn't make it OK to run an extortion racket on the side. I have a lot of nice things to say about Apple, but for cases like this where you wonder if it was Apple or Oracle who called you to extort money then Apple deserves all the criticism rhey get (and then some more if you ask me). The thing about Apple is less about attacking Apple and more about defending himself - and in the process a number of smaller devs - against abuse from Apple. I think the thing about PWA is less that he isn't interested in it and more that he wants things to just work across all browsers. He has been preaching against the hunt for unicorns for a decade or so I think, talking about sanity and sustainability. 'His' apps (obviously built together with others) were early examples of actually working Ajax. He is the guy who built Rails and inspired a huge number of other frameworks from Symfony and Laravel to parts of modern JavaEE. Let me paint a somewhat less strawman-y picture of DHH for the benefit of those who doesn't know him: > Moreover, it's clear that DHH is not interested in even something like basic PWA support, and will instead spend his time attacking Apple for not approving their app on the app store.

The latter is really annoying, yet it's the experience most SPAs give you. I don't know about you, but I'd rather wait 250ms once and then have the page arrive fully rendered over a transition that takes 2ms and then 200-400ms of multiple requests finishing and the page popping into place. They instead end up creating an experience that poorly emulates server side rendering, since now many page changes end up with a blank page or a loading indicator before the data arrives in a subsequent request. This real world example is a good representation of how most SPAs are built, and they lack the type of functionality you're describing. But the reality is that it usually is this way. You can say 'well it doesn't have to be this way' or 'this is just an example'. Click on an article and then go back to the feed? Every time you will see a blank feed for about 500ms and only then do the articles stream in. In virtually every implementation, every time you change pages, the app re-downloads everything it needs for that route. Take a look at the 'RealWorld' example SPA showcase (it's like a TodoMVC for SPAs), which has 43k stars on GitHub: Īnd go ahead and click on the demo site: With an SPA, it could be built to do this. With a SPA framework, it could add it to the local list of emails and push to the server in the background, so it would transition instantly regardless of connectivity.

Native mobile app wrapper rails