11–20 of 637 posts
Back before the web people made C++ and VB user interfaces that interact directly with the data source. SPAs are an attempt to make the web closer to that well known paradigm. POST REDIRECT REFRESH cycle was an insane programming paradigm that wasn't found in any previous edition of programming.
Really though, this is a dead horse. SPAs are just a tradeoff like everything else in engineering. We trade the simplicity of a monolith for the ability to parcel out work efficiently between large disparate teams of frontend/backend engineers.
I 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…
SPAs 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…
Practical SPA's have many more network roundtrips than the equivalent server-rendered web interface. Every AJAX request is an extra roundtrip, unless it can be handled in parallel with others in which case you're still dependent on the slowest request to complete. With SSR, you can take care of everything with a single GET and a single POST no matter what. Images load in parallel of course, but those are non-critical.
Most 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.
I 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…
Sometimes I realize a SPA would have simply served the user better, and it doesn't necessarily take much to be in that predicament.
Too many people hate on SPAs by, presumably, just imagining static read-only content like blogs and news. Though I'm also a bit tired of "SPAs suck amirite, HN?"
Put the user first, consider the trade-offs that work towards that goal, and see what shakes out.
Instead of Google/Facebook CPU cycles being spent on rendering their content, it's now the client devices, while the Google/Facebook infrastructure is "just" serving the data.
I 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.
This 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.