SPAs Were a Mistake
gomakethings.com
SPAs Were a Mistake
1–10 of 637 posts
Re: SPAs Were a Mistake
#2SPAs are a pattern that's been applied too broadly IMO, but it's going a bit far to call them a mistake. The aims of an SPA are pretty noble - the idea of essentially removing the network round trip when a user clicks on something is not a bad one. It means things are faster, they work if your connection is flaky, they can do things like offline support. Those are good features.
They might not be actual requirements for a blog or a brochure site but it's not totally unreasonable for someone to want their website to work that way. The question is not whether or not an SPA is a good or a bad thing, but whether or not the cost (more code, more complexity, potentially a series of background requests after the initial page load) is worth paying in order to get the benefits.
When either an SPA or a multi-page site is done well most users can't tell which sort of site they're looking at. That should be the goal. Make stuff where the user forgets about the tech. Make a website that just works, that's fast enough for users not to think 'this is a bit slow', and that's coded in a way you can maintain and work on for a long time. If you get those things right then no one can reasonably criticise what you've made no matter how you've made it.
Re: SPAs Were a Mistake
#3This ship has sailed. SPAs shortcomings are widely known and addressed by frameworks.
Whatever MPA alternative you bring will need to address other shortcomings. There will always be something quirky due to building applications in a technology designed for hypertext documents.
Re: SPAs Were a Mistake
#4Anyone else encountered NG routing locking up upon return to the web app with Safari back button?
Re: SPAs Were a Mistake
#5[deleted]
Re: SPAs Were a Mistake
#6Most major frameworks do that. Barring some devs who navigate using onClick over a link despite having that option.
Outside of some lasting mistakes made a decade ago, is this still an issue?
On top of that, “SPA” is a misnomer, as many frameworks give you a hybrid anyway.
Re: SPAs Were a Mistake
#7I think one of the unsolved problems of client-side interactivity on websites is how difficult it is to add it just a little bit of extra client-side functionality to a traditional server rendered website. For example, recently I had to deal with photo uploads on a Rails app, which works fine out of the box at first, until you want to show progress bars and uploaded previews etc. Then you add a couple of client-side Stimulus controllers, maybe a Turbo frame here and there and it works, but then you get to browser navigation and you're screwed, because none of this works if somebody were to submit the form, then navigate back. Now you have to implement lifecycle handling to account for navigation and once you're done, you've basically implemented a SPA, except it's broken into a mix of tightly-coupled Javascript, Ruby and ERB templates.
Re: SPAs Were a Mistake
#8I don't disagree with most points here, but I did chuckle at this one:
> YouTube is a great example. Being able to keep a video playing while you explore other videos is fantastic.
I hate that (mis)feature. When I click something else, my attention is on the new thing. Having to go find the little still-playing video window to close it is a hassle.
Re: SPAs Were a Mistake
#9SPAs were a good solution when page load/rendering times were longer. However with todays internet speeds, edge caching, HTTP3/Quic as well as todays chips and browser implementations page reloads are barely noticeable so you get all the goodness the browser gives you out of the box creating MPAs.
There are still some examples were SPAs are useful such as replacing complex desktop applications but 95% of web apps don't need it.
Re: SPAs Were a Mistake
#10At this point most articles like this or tools addressing the problem discussed here replace one local optima with another, I'm holding out for something radically different, maybe something like makepad or bevy like ECS with good support for UI.