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

341–350 of 637 posts

Re: SPAs Were a Mistake

#341

Post by somishere »

polished85 wrote: post #323
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…

I initially thought part of the appeal was offloading the workload to the front end, where your processing power scales infinitely with each user's device. Maybe the benefit turned out to be negligible, I'm not really sure. Can server costs be reduced by offloading the work to the front end?

> Can server costs be reduced by offloading the work to the front end?

I would say yes. One significant benefit of SPAs is that you can produce fairly complex applications without any server logic, only static hosting. The workload is essentially offloaded to the build process and the front-end. You still need to carefully consider the effect on e.g low powered and js-disabled devices ... but these are straightforward considerations.

Re: SPAs Were a Mistake

#342

Post by pkilgore »

hinkley wrote: post #84
Jenk wrote: post #18

It should be obvious why SPA/PWA frameworks were developed by the likes of facebook and Google: Offloading their content rendering to the client. 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.

First lead dev offered me advice for the rest of my career. Most of what you are going to see people argue about are cyclical fads. A pendulum. We try A and it doesn’t work. So we try !A. And when people forget why we stopped doing A someone tries it again over and over. How are things different this time should be your second question. Your first question is what is the middle ground? Boolean logic falls on its face…

So I ran across a shit ton of your comments in this thread, like how you think, you should hit me up if you're ever hiring.

Re: SPAs Were a Mistake

#343

Post by craigkerstiens »

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…

Hi Simon, why'd you pull me in ;)

We recently went a rewrite of our frontend for https://www.crunchybridge.com from SPA to more "basic" request response app and couldn't be happier. Previously was SPA with React and we rebuilt from scratch with request/response using Node. In places we still leverage react components for re-usable frontend bits, but no more SPA and state management.

As you've mentioned in some of your other threads on this, the state management and sync between the API team and the front end team just caused velocity to slow down. It took longer to ship even the most basic things. While we want a clean and polished experience, the SPA approach didn't really accomplish any of that for us.

The rewrite was under 8 weeks of an app that had been built up over a couple years and we quickly recouped all that time in our new found velocity.

Re: SPAs Were a Mistake

#344

Post by Graffur »

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…

That just sounds like poor performing developers to me. You don't need snazzy animations between states. Just not reloading the full page is a benefit.

Re: SPAs Were a Mistake

#345

Post by pier25 »

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…

I think the best solution for this is just doing fullstack dev with SSR + partial hydration.

The issue is that, so far, we haven't figured out how to have a good fullstack DX.

Remix is probably one of the best attempts so far, but it still leans heavily towards being a very sophisticated renderer for the front end. The proof is you probably would not use Remix to create a 100% backend project with no front end. Same with SvelteKit or Next.

Until fullstack frameworks get more serious about the backend, we will be in this weird limbo.

In my current project I use Fastify as my main backend framework, and then use Svelte for SSR + hydration. I loose a lot of the frontend sophistication that SvelteKit brings to the table, but OTOH I have an amazing backend framework and total control and flexibility.

Re: SPAs Were a Mistake

#346

Post by the_gipsy »

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.

99% of SPAs break history related features in some way.

Re: SPAs Were a Mistake

#348

Post by somishere »

gnlrtntv wrote: post #336
polished85 wrote: post #323

Earlier quoted context omitted.

I initially thought part of the appeal was offloading the workload to the front end, where your processing power scales infinitely with each user's device. Maybe the benefit turned out to be negligible, I'm not really sure. Can server costs be reduced by offloading the work to the front end?

They absolutely can, if your workload is ideal for this situation, but unfortunately, the most "expensive" (in terms of time, money, computing power, you name it) part of giving a user information is typically the filtering and collation of that information from a much larger pool of information — almost always a pool of information that is far too big and too private to just send to the client to sort through locall…

Dynamic loading of content is a feature of SPAs, but it's not a defining feature, nor unique. In fact, one defining feature of SPAs is the offline capabilities (service workers, caching, etc.), which sits at a bit of a tangent to database considerations like this.

Re: SPAs Were a Mistake

#349

Post by freedomben »

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…

I agree with all your points, but I think it's worth pointing out that those benefits you mentioned are largely for the developers. As a consumer I love a well-written SPA when the problem set calls for it, but most of the SPAs I have to use are garbage. I don't fault the tech for that, although I suspect that a lot of those SPAs were created by "me too" people that just wanted to build a SPA. When React was in the pre 1.0 days, I did that, and several people on my team as well (so I'm not casting any stones here, just trying to state facts).

Last time I bootstrapped a React SPA I don't think cra includes a router ootb.

Re: SPAs Were a Mistake

#350

Post by simonw »

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…

"A website has to go out of its way to mess this up."

I know it's supposed to be easier, but I keep seeing teams mess this up.

Post reply on HN