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

321–330 of 637 posts

Re: SPAs Were a Mistake

#321

Post by ngcazz »

simonw wrote: post #314
krisrm wrote: post #308

Earlier quoted context omitted.

I always thought of the benefits of SPAs more as a separation-of-concerns thing. You can pretty effectively build a functional front-end web application and mock a set of back-end REST apis, while another team builds out a the back-end. There are absolutely tradeoffs, and being a good software engineer is about understanding where and when those tradeoffs apply.

That's definitely true at the organizational level, and it's an argument with some merits. In practice though, I've seen this backfire. You end up with the frontend team blocked because the API they need isn't available yet, and then the backend team gets blocked because they shipped the API but they can't use it to deliver value because the frontend team don't have the capacity to build the interface for it! My pref…

that sounds like a mismatch between the architecture and how work is getting planned no? if the backend is in the critical path to delivering the user value of a feature then the backend and frontend engineers need to be developing (and testing) the feature together

Re: SPAs Were a Mistake

#322

Post by rapind »

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…

It’s all about state management IMO. There are legitimate reasons to keep UI specific complex temporary state on the client that would be more complex (and slower) if the server needed to hold it. So an SPA or at least partial SPA in some situations does makes sense.

But it does tend to become a hammer for every screw over time…

Re: SPAs Were a Mistake

#323

Post by polished85 »

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?

Re: SPAs Were a Mistake

#324

Post by pl0x »

freedomben wrote: post #71
uhoh-itsmaciek wrote: post #41

Earlier quoted context omitted.

I think it's exciting to see frameworks like https://remix.run/ trying to temper the disadvantages of SPAs by relying on web standards and server-side rendering. It's pretty cool that this is a JavaScript framework that can work without any (client-side) JavaScript.

Honest question: why is remix the primary example for this now? Next.js has been doing this for years and is really amazing. It seems like a ton of people had no idea this was even a problem they had until remix came along, and now remix is the savior. Am I missing something with remix? Is there anything really novel that it does/introduces?

No post body was provided.

Re: SPAs Were a Mistake

#325

Post by jdrc »

the frustrating thing is that i rarely find a page that doesnt take at least 20 seconds to load, even if i only want to see an 100x100 image. This happens no matter how fast computer i use and it 's despairing

The term "server-side rendering" gives me giggles every time

Re: SPAs Were a Mistake

#326

Post by fuzzy2 »

timr wrote: post #313
fuzzy2 wrote: post #277

Earlier quoted context omitted.

Yes, even after POST. Why not try it, right here, on Hacker News. The comment form uses POST. I post this comment and go back and my text is still in the input box. In fact, browsers even have re-submit built-in: Just press F5 on a page that was retrieved using POST. That’s why so many sites use a redirect after POST.

Redirect after POST was a pattern created to bypass the warnings that (most) browsers emit on back-navigating after form submit, while still preventing double-submit (by redirecting to the GET): https://www.theserverside.com/news/1365146/Redirect-After-Po... It sounds like this warn-on-double-submit behavior is convention and not required, so maybe it has become more common for browsers to stop doing it. > Why not tr…

> When you back nav, you are seeing the response to a GET request to /reply?id=BLAH

With the text you previously entered, which the browser restored. If it did not for you, you have non-standard settings like disabled caching. I can assure you that it behaves the same on Firefox for Linux, Windows, macOS and Safari on iOS: go back, form content is restored.

In fact, the entire internet is full of people trying to get rid of this behavior.

Re: SPAs Were a Mistake

#327

Post by donatj »

I have in my life used a couple of SPAs where I thought "Man, this works really smoothly and quickly!" Like there have seriously been a couple really good ones.

They absolutely can be done right, I've built one I think is done right. I've built a couple. I don't think the average team has it in them to build a good SPA.

The majority of SPAs are user hostile hot garbage.

The 95% of other SPAs were full of minor frustrations that could have been easily avoided by not being an SPA including

  1. Completely unhandled errors with no indication anything is wrong. 
    - This is a majority of SPAs. Any request error on flakey internet? Don't bother tell the user, just break.
    - The sheer number of times I've needed to open inspector to see that something has gone wrong… At least an actual non-SPA request that fails will show you an error page.  
  2. Broken… native… everything 
    - 2.1 Especially "broken open link in new tab"/middle click - see next.
  3. Inability to run the site in multiple tabs.
    - State is entirely local so state gets broken *easily*.
    - Some just outright refuse and warn you.
  4. Adding everything I do to the browser history api
    - Makes it even worse than the back-button-not-working of old. Have to hit back a thousand times.
    - Scrolling SHOULD NEVER add things to my back button. NEVER.  
  5. High CPU usage on a site doing seemingly nothing
    - Looking at you, Medium.  
  6. Generally being way slower to use than the previous non-SPA website
    - Looking at you, Wells Fargo.
  7. LOSING MY POSITION ON HITTING BACK
    - The sheer number of times I've been scrolling down an infinite list for like 30-45 seconds, click on something, nope not what I wanted, hit back, returned to the top of the list is entirely unacceptable as a society.
    - This is very often combined with 2.1 and 3 to make for a truly infuriating experience
Like don't get me wrong, you can do a lot of this junk in a non-SPA but the failure state is almost always better.

Re: SPAs Were a Mistake

#328

Post by jdrc »

blunte wrote: post #8

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.

agreed. i dont think youtube needs to be an SPA and simple pages work better. For comparison: porn sites.

Re: SPAs Were a Mistake

#329

Post by com2kid »

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 for a number of reasons:

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.

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.

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.

I agree some sites shouldn't be a SPA, a site that is mostly text content consumption, please no. A blog doesn't need to be a SPA. Many forums, such as HN, don't need to be a SPA.

But if a site is behaving like an actual application, just delivered through a web browser, then SPAs make a ton of sense.

Re: SPAs Were a Mistake

#330

Post by rapind »

finniananderson wrote: post #303
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…

Totally agree. We built a product in ~5 months with real-time collaboration, extensive interactivity, Oauth, Stripe and Gmail integrations with a standard Ruby on Rails stack. It's rock-solid, performant, dead-simple and extremely productive to work with. Why're we throwing away years of learning to build unstable, complex and inaccessible applications?

One could argue rails is just doing a decent job of hiding a monstrous amount of unnecessary complexity from you for basic CRUD stuff. It’s good at this… until it isn’t. In the the whole ORM abstraction (not just in rails) is questionable.

The way most of us would handle authorization in something like rails is a leaky abstraction, especially when we’re usually backing onto postgresql which has very mature roles and permissions.

Post reply on HN