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

71–80 of 637 posts

Re: SPAs Were a Mistake

#71

Post by freedomben »

uhoh-itsmaciek wrote: post #41
onion2k wrote: post #2

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…

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?

Re: SPAs Were a Mistake

#72

Post by hinkley »

clivestaples wrote: post #52

I think SPAs were the best solution we had at the time and I enjoyed trying to build good UX with them. Yes, React started fresh and ended up driving me back to Rails because I'm just not smart enough. That said, I am really excited about Django w/HTMX, Rails w/ Hotwire, and Next and Remix with React. Particularly Remix.

I can get good at a lot of things, but most of them (including half the ones I’m good at) really just aren’t worth my time and energy.

Ain’t nobody got time for that is more often closer to the mark. But anything that requires hypervigilance is eventually going to make you look dumb. Just don’t let them put “human error” on the RCA. Yes, You screwed up, but We put you there in the first place.

Re: SPAs Were a Mistake

#73

Post by mattwad »

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 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.

Re: SPAs Were a Mistake

#74

Post by hinkley »

lambda_dn wrote: post #9

SPAs were a good solution when page load/rendering times were longer. However with todays internet speeds, edge caching, HTTP3/Quic as well as todays chips and browser implementations page reloads are barely noticeable so you get all the goodness the browser gives you out of the box creating MPAs. There are still some examples were SPAs are useful such as replacing complex desktop applications but 95% of web apps don…

It was a big day for me when I realized the CSS perf tool had been removed from my browser because the clock resolution was no longer sufficient to make it work. Everything was Bloom filters for CSS were a huge deal, and the CSS load and apply times are one of several things SPAs were trying to amortize.

Re: SPAs Were a Mistake

#75

Post by zozbot234 »

tonyedgecombe wrote: post #50
onion2k wrote: post #2

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…

>It means things are faster, they work if your connection is flaky, they can do things like offline support. Those are good features. Yet the reality seems to be the opposite. If my connection is flaky (which it often is) then SPA's seem to fail more often and it isn't obvious what is going wrong. They don't seem to be faster either, long pauses between pages is common.

Right. The typical SPA doesn't recover at all from network failures, and you end up poking random buttons hoping that it will reach some sort of consistent state. Then you find that doesn't help and you need to refresh anyway, which is a reboot for the whole 'app'. So much for saving page loads.

Re: SPAs Were a Mistake

#76

Post by wrs »

coding123 wrote: post #11

SPAs were not a mistake, SPAs were an attempt to make the front end work like front ends have ALWAYS worked. 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.

Not so. IBM mainframe systems (3270 terminal based) that ran most of commerce for a long time are basically the same paradigm as a web browser. Send a form to the smart terminal (GET), wait for the response with the field values (POST), send another form.

In fact there are adapters that literally turn these applications into websites by translating the forms into HTML. Commonly seen when you need to do something like change the beneficiaries on your health insurance.

“Client-server” paradigm came out in the 90s when PCs became powerful enough to run a “thick client” application, and was considered revolutionary.

In other words, the eternal cycle continues… :)

Re: SPAs Were a Mistake

#77

Post by lp0_on_fire »

aminerman wrote: post #35
slashdev wrote: post #24

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…

Quoted post unavailable.

Instead why don't you let us know why you think that position is incorrect rather than resorting to reddit-tier insults?

Re: SPAs Were a Mistake

#78

Post by gowld »

RHSeeger wrote: post #69
onion2k wrote: post #2

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…

> When either an SPA or a multi-page site is done well most users can't tell which sort of site they're looking at. And therein lies the problem. In the _vast_ majority of SPA sites I've been to, they are not "well done" by this definition. It is commonplace for things to break, like the back button as the quintessential example, because the developer(s) didn't spend the time to make sure things work correctly. With…

You're just saying that bad software is bad. That's tautological.

Without SPA you have horrific 10page forms and the challenge of maintaining state as you go back and forth to make edits.

The hard part is managing state, and there is no way to avoid it if your product is not purely readonly. SPA is one strategy, and a pretty good one.

Re: SPAs Were a Mistake

#79

Post by hinkley »

midiguy wrote: post #43

Every week someone posts some half-baked blog ramble about how SPAs are bad (except for media sites!). How about this - I am just as or more efficient working with SPA frameworks such as React as working with server-side-rendering. I have invested in a skill and toolset that can deliver any sort of website or web application from blogs to Youtube to Figma. I don't see any reason I would invest in learning an MPA fram…

Why are wood shops loaded to the rafters with tools? Because there is no Golden Hammer, only people who think they’ve found one.

You’re saying you’re doubling down on a single solution, which is probably not actually true, but you are surrounded by younger developers who will copy what you seem to be doing rather than what you’re actually doing.

All of these unresolved arguments are about team dynamics, not technology, which is why they never get resolved. Because we talk about our experiences or “objective” things like logic.

Re: SPAs Were a Mistake

#80

Post by gowld »

freedomben wrote: post #68
horsawlarway wrote: post #45

Earlier quoted context omitted.

I pretty strongly disagree with this. The distinct advantage of an SPA is that, done correctly, cached data lets you render pages instantly. Who CARES if the SPA had to make 3xRTT in the background, if it can serve the next page up instantly because that data is already present and cached, it's a huge win. The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not. Still do…

Have you tried to use a heavily SPAed site from a slow, distant (high latency), or metered connection? A SPA that works and feels great from a big city quickly becomes unbearable when internet access isn't as ideal. There are ways to handle this nicely, but maybe 5% of devs actually think about and test that, and no PM will allocate sprint time for it.

Have you tried to use a site that reloads all the data on every click, from a slow, distant (high latency), or metered connection? Same problem.
Post reply on HN