Live data from Hacker News

SPAs Were a Mistake

gomakethings.com

281–290 of 637 posts

Re: SPAs Were a Mistake

#281
One thing that I found working in a bigger organisation is just how well React encapsulates Design Systems. You can have a dedicated team of talented frontend engineers that builds a really solid design system, and then other folks building the actual user facing bits can use them, and everything will be nice and consistent across all the various apps.

For example look at how well this has been going for Uber.

Now this is certainly possible, and even relatively easy to do in server side frameworks, but as others have stated, its harder to make sure it works nice in all the various edge cases and visual flair that is required for end users, and keeping it all consistent and upgradable across the board.

React (and I'd wager other component based approaches) shine there - its low level enough that you can implement anything with it, but still allow you to build complex things fast. And then are free to implement the actual business logic of the backend with the technologies of your choice. Even better various teams can do that in their preferred language, without the end user being affected by the difference.

Throw in react native to make the styles transferrable to mobile apps and you have the perfect sweet spot for largish tech companies. And since those tend to be the more vocal ones, we get this, in my opinion largely deserved desire to build SPAs.

Smaller teams / startups of coarse don't have those incentives, so they will understandably not have the same cost / benefit analysis.

Re: SPAs Were a Mistake

#282

No shit, Sherlock. Of course, all of this was obvious to any of us with more than 5 minutes of industry experience, alas this field seems super prone to reinventing the same things over and over again, making the same mistakes and never learning from the past. Also, this article does not even mention the fact that SPAs are terrible for SEO. Of course, that's not an issue for YouTube, but it might be a huge issue for…

SEO for SPAs is a solved problem

Re: SPAs Were a Mistake

#284
If it makes you feel better, SPAs were a mistake when they were all the craze in Flash. Also way before that in Director.

In those two cases, they signified (or accelerated) the end of the useful lifespan of those languages.

SPAs, like frameworks, always make some things easier and some things harder. As long as you stay within the lines of what is easy, you are good. As soon as you stray outside those lines, you get punished.

Re: SPAs Were a Mistake

#286
It's been so frustrating watch this play out over the past decade.

I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs.

Inevitably none of these projects end up taking advantage of the supposed benefits of SPAs: there are no snazzy animations between states, and the "interactivity" mainly consists of form submissions that don't trigger a full page - which could have been done for a fraction of the cost (in development time and performance) using a 2009-era jQuery plugin!

And most of them don't spend the time to implement HTML5 history properly, so they break the URLs - which means you can't bookmark or deep link into them and they break the back/forward buttons.

I started out thinking "surely there are benefits to this approach that I've not understood yet - there's no way the entire industry would swing in this direction if it didn't have good reasons to do so".

I've run out of patience now. Not only do we not seem to be learning from our mistakes, but we've now trained up an entire new generation of web developers who don't even know HOW to build interactive web products without going the SPA route!

My recommendation remains the same: default to not writing an SPA, unless your project has specific, well understood requirements (e.g. you're building Figma) that make the SPA route a better fit.

Don't default to building an SPA.

Re: SPAs Were a Mistake

#287
post #7

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…

This is what jQuery solved. It made it ridiculously easy (compared to not using jQuery at that time) to add a little sprinkle of progressively enhanced JavaScript to a page. It still works today (and you don't even need jQuery now, as browser standards have mostly caught up), but everyone seems to have forgotten how to do it!

Re: SPAs Were a Mistake

#288
post #73
post #7

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…

I feel like most people that hate SPAs never have to deal with this type of thing, or even only have to work on the backend. They just don't get it. Of course, if you're using a SPA for a static website, you're also doing it wrong but that doesn't mean SPA itself is a bad thing.

"They just don't get it"

Believe me, I get it.

I dealt with building these kinds of features for a full decade before SPAs became fashionable.

Now I'm stuck here watching in frustration as people go all-in on SPAs because they didn't know how to solve these problems without them.

Re: SPAs Were a Mistake

#289
post #7

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…

Did you have a look at https://htmx.org/ ? I think it solves the "just a tiny bit of interactivity on an MPA" kind of thing.

Re: SPAs Were a Mistake

#290

I hate SPAs. I would never do another SPA again if it were up to me. It just adds too much mental context switching and overhead. I can develop fully server-side apps that are lighter, run faster, and at least 20% less development effort (I actually compared that for the same task: https://medium.com/@mustwin/is-react-fast-enough-bca6bef89a6 ). So why would I ever do an SPA again if it were up to me? I would use http…

Template based UI programming is like going back to the year 2007. Your views should be reactive. Elm, Flutter, React, Et Cetera understand this. Having a function that takes data and returns a view is much better.

We can debate syntax but a Go or Python based template language is not conceptually any different to JSX based syntax. Both are essentially functions that take some input data and return the data formatted in HTML.
Post reply on HN