> You're right, I should have been clearer. Emphasis on develop and maintain.
Did you ever think that you might want to put the user experience first?
Look at YouTube with their great SPA. If I'm on mobile and not using a flagship phone with 3gb of ram, it's just great: I scroll through my search results which are these idiotic incrementally loading page, then I select a video, watch it and want to go back. Surprise! I see the loading spinner again an my scroll position is lost. State seems so broken with SPAs that it only ever works in some demo apps that were solely built to prove that you can have SPAs with a working back button. Great, I already had that on YouTube in 2006 with a fancy and handy feature called pagination for the search results.
But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web.
This kind of terrible state management is super widespread and really annoying. I agree that lots of folks seem to have have spent the last few years thinking more about their build chain and tooling than about basic UX.
And this is why I like Parcel. It's by no means perfect but having pretty much zero config and still being able to jump into using pretty much whether system you want with a simple command is nice.
Frankly I thought jQuery was a horrific way of building stuff, and moving to a declarative approach like React is a huge step forward. Most complaints I've seen about it are due to incompetence or misunderstanding.
This specific example really just applies to all naive implementations of AJAX infinite scroll, which far predates the rise in popularity of SPAs.
Discourse, a forum written as a SPA in Ember, changes your URL as you scroll to each post. Even if you scroll down and let javascript load in more pages of content, the URL will reflect the post you’ve scrolled to, and will jump right to it if you go somewhere else then click Back, or just load the link:
> Did you ever think that you might want to put the user experience first?
I like react for SPA because it means It makes it easy to build a pretty solid user experience. The best example I had was when I was building the login + info portal for inflight wifi. We used server-side rendered React to give them an operational page without JS, and then enhanced it when the JS loaded in, and then precached additional content to make the pages load instantly.
The react + webpack ecosystem made this _really_ easy. Inlining the critical css for the base type + login form was stupid simple.
At the end of the day, there are lots of tools and its up to developers to find the best tools for the job. Sometimes, developers make the right choice. Other times, developers make the wrong choice. If you have a dysfunctional team/org, you're probably not going to build much great regardless of the tools you choose.
Whether pagination is saved (like ?p=6 in url) doesn't have anything to do with SPA vs SSR. Just like an SSR /search endpoint that uses POST over GET so you can't just save/share the query.
You're blaming SPA but as usual it's just people not caring about polishing application UX.
But in the YouTube case I don't even have pages! But anyways, When not going the SPA route I get all this for free. Navigating the search result pages automatically ends up in the history. 0 lines of Js required. Also since the whole page is generated server side even the scroll position within the result page is restored properly. Again 0 lines of Js. This already worked in the 90s. Today it doesn't, and we call it progress.
We had plenty of sites in the 90s breaking due to using POST on almost every navigation, or embedding a sessionid in the URL that would break the site when being bookmarked/shared
You could build even worse horrors using <form target="..."> to update frames/iframes... partial page updates without javascript. This still lives on in some oracle web applications...
> Did you ever think that you might want to put the user experience first?
As I've repeatedly explained in the comments, I'm not arguing that you should use an SPA, and I'm not arguing that SPAs have necessarily better UX. You still have to be a good dev.
SPAs are not footgun-protections and the issues you're listing are fairly easily solved. Maybe they're not natively solved by SPAs, but other approaches also have their natively-unsolved problems, so this is moot.
> But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web.
I don't even know what you're on about or how it relates to this discussion. Did you mean to post this on a different article?
> I don't even know what you're on about or how it relates to this discussion. Did you mean to post this on a different article?
Nope, that was just a small addendum in relation to my example since experience has shown that often times the back button is broken in different ways depending on browser. Having just one engine left would at least mean some more consistency here, but that's about the only advantage I can see in that.
Did you ever think that you might want to put the user experience first?
Look at YouTube with their great SPA. If I'm on mobile and not using a flagship phone with 3gb of ram, it's just great: I scroll through my search results which are these idiotic incrementally loading page, then I select a video, watch it and want to go back. Surprise! I see the loading spinner again an my scroll position is lost. State seems so broken with SPAs that it only ever works in some demo apps that were solely built to prove that you can have SPAs with a working back button. Great, I already had that on YouTube in 2006 with a fancy and handy feature called pagination for the search results.
But I guess once we kill Firefox this will become much better since Google will just do whatever the duck they want with the web.