Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SPAs Were a Mistake

gomakethings.com

Post reply on HN
Print view View original

361–370 of 637 posts

Re: SPAs Were a Mistake

#361

Post by tepitoperrito »

com2kid wrote: post #329
simonw wrote: post #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 SPA…

> 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. The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up. That aside, SPAs are great…

> The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up.

They might not mess up history when using a standard routing library, but I've seen plenty of devs forget to add unique titles to different pages which is frustrating for a user with multiple tabs going.

On SO the accepted answer for react-router looks like "create a custom Page component with title as a prop"[0]. At work I just ask folks to use react-helmet.

[0] https://stackoverflow.com/questions/52447828/is-there-a-way-...

Re: SPAs Were a Mistake

#362

Post by jeremyjh »

the_gipsy wrote: post #346
com2kid wrote: post #329

Earlier quoted context omitted.

> 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. The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up. That aside, SPAs are great…

> The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up. 99% of SPAs break history related features in some way.

97% of statistics cited on HN are made up on the spot.

Re: SPAs Were a Mistake

#363

Post by sdegutis »

Traditional dynamic web servers can solve a lot of the same problems that SPAs and event front-end frameworks like React solve, by just applying software engineering principles to the whole stack. That's what Novo Cantico[1] does, and a lot of what I've been trying to say in my blog posts[2] that explain Novo Cantico.

[1] https://github.com/sdegutis/Novo-Cantico [2] https://www.novocantico.org/blog

Re: SPAs Were a Mistake

#364

Post by bob1029 »

The fundamental conclusion I reached is that all of the pain originates by having your state divided between client & server, and then being forced to synchronize the two.

Doesn't really matter what technique or framework is involved. The worst trip I've had is with angular 2, trying to put humpty dumpty back together again via tons of janky API calls.

The best solution I have used so far is probably Blazor. In server mode this gets you pretty damn close to 100% state lives on the server. I've had to write some javascript, but even then the abstractions for interop make it very clean throughout. I use eval to dynamically run methods against the client. This allows me to avoid having to serve any custom javascript source (aside from the blazor client js).

Re: SPAs Were a Mistake

#365

Post by jeremyjh »

kitsunesoba wrote: post #246
hombre_fatal wrote: post #230

Earlier quoted context omitted.

Well, the browser has certainly evolved past the point of SPAs being nothing but a hack. The browser has evolved into a heavily generalized application environment, as much as we may want to bemoan that. A good web client can surely demonstrate this. It's certainly true that you don't get to lean on built-in features like history support, but that's why you can now drive history with Javascript. And all sorts of othe…

> Rich client development is always hard—on any platform—, and you always make concessions for the platform you're on. I certainly have to when I'm building iOS apps. But I see no reason for this to dissuade you if you can push a better UX to the user. I think the difference is how much you as a developer have to "fight" the platform. Having to implement history management yourself very much qualifies as "fighting" t…

It comes for free in mature SPA routing frameworks as well. Who is implementing history management themselves?

Re: SPAs Were a Mistake

#366

Post by austincheney »

ravenstine wrote: post #154

Nah, they weren't a mistake, at least not in isolation. Much of modern software development is a mistake, generally speaking. When you look at it that way, SPAs only failed in the sense that Object-oriented Programming failed, as well as the failure of various design patterns, microservices, write-once-run-anywhere, test-driven development, decentralization... I can go on and on with the number of engineering and com…

> SPAs only suck as much as we suck.

We suck pretty bad. SPAs are often the default because that is what the framework dictates and nobody trusts a JavaScript developer to delivery any kind of quality product without some epic massive framework, including ourselves. This is the standard for hiring, performance, and delivery and nobody dares deviate. If its not an NPM package written by an anonymous stranger or an API on the framework its not an option. We don't trust each other and management doesn't trust us, so let the framework dictate our every decision.

Re: SPAs Were a Mistake

#367

Post by [deleted] »

gls2ro wrote: post #203
k__ wrote: post #183

While Web2 is moving to SSR, I think SPAs will be a huge part of Web3. SPAs are perfect for decentralized infrastructure like IPFS and friends. Same goes for mobile apps.

What exactly from SPA is making them good for decentralized?

[deleted]

Re: SPAs Were a Mistake

#368

Post by Pensacola »

dlisboa wrote: post #155
Zanfa wrote: 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…

The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts pres…

> The problem is the mixing and matching of state management.

This. But IMHO the right solution is to make the back-end stateless and manage all client state on the client. Each request authenticates itself, and (if you're ReSTful about it) the back-end is simply a database connector/augmenter.

In this paradigm, the SPA is basically a desktop app that retrieves data from a server, built to run within a framework, which happens to be a web browser.

In case you're jumping to conclusions, know that I'm a late-comer to the SPA party, having resisted from its inception until about a year ago, for all the obvious reasons, including those bemoaned by the OP.

Why did I relent? SPA frameworks like React now handle pretty much all the heavy lifting for you. OP, you should check out React Router, which can render this post's examples irrelevant. I'm surprised that in 2022, someone writing to the web UI layer would bother to create code to manage the address bar when there are a thousand ways to not have to.

Re: SPAs Were a Mistake

#369

Post by bcrosby95 »

com2kid wrote: post #329
simonw wrote: post #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 SPA…

> 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. The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up. That aside, SPAs are great…

> 1. You aren't mixing state across server and client. Single Source of Truth is a thing for a good reason. If you have a stateful backend, and your front end naturally has the state of whatever the user has input, you now have to work to keep those two in sync.

If this were true, you wouldn't need a REST API. I don't understand what you're trying to say here. When you make a REST call to get data, you instantly have two different sets of state: the client and the server. It's no different from SSR, it's just transmitted in a different data format (json vs html).

> 2. You need a beefier backend. A SPA backed by REST APIs is super easy to scale. nginx can serve up static resources (the JS bundle of the site) LOLWTF fast, and stateless REST apis are easy peasy to scale up to whatever load you want. Now you just have to worry about backend DB, which you have to worry about with non SPAs anyway.

You do the exact same thing with SSR. Stateless shared nothing app tier instances. Been doing it for 15 years now.

> 3. Less languages to deal with. If you are making a modern site you likely have JS on the front end, so with SPA you have JS + HTML. With another backend framework you now have JS+HTML+(Ruby|Python|PHP|C#|...), and that back end code now needs to generate HTML+JS. That is just all around more work.

You can use JS on both the frontend and backend. Or ClojureScript. Or TypeScript. I'm sure there's others. But yes, for many languages this is a potential negative of SSR.

Re: SPAs Were a Mistake

#370

Post by s17n »

com2kid wrote: post #329
simonw wrote: post #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 SPA…

> 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. The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up. That aside, SPAs are great…

This is missing the real reason that people write SPAs, which is that React solved web components, which are hugely beneficial for almost 100% of web sites, and thus became the standard for building web sites, and with React it's easier to make an "SPA" than to make a "traditional" site and users don't know or care either way.
Post reply on HN