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

81–90 of 637 posts

Re: SPAs Were a Mistake

#81

Post by salt-thrower »

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.

This reads like a Reddit comment. Let's try to be better than that here.

Re: SPAs Were a Mistake

#82

Post by efdee »

Closi wrote: post #59
hombre_fatal wrote: post #17

Earlier quoted context omitted.

Exactly. I've been in the position various times where I'm embedding a JS app on a page to help the user do something highly interactive, usually creating/editing content. And then as it's expanding to integrate with other things on the site, I start to wish more of the site was in the JS-app side of things. Sometimes I realize a SPA would have simply served the user better, and it doesn't necessarily take much to be…

I think the fundamental issue with SPAs is that it's building on multiple levels of technology that fundamentally weren't designed to support being a single page application. The browser multiple pages paradigm is pretty much how the web evolved, so SPA's just end up being one giant hack to get everything working. UWP/WPF/any other desktop app framework demonstrates how easy developing a 'single page application' can…

In my opinion, UWP/WPF/aodaf makes it easy because it just doesn't implement the things a user is used to in a browser (bookmarkability, back button, ...).

If you ignore those things in your SPA, much of the "cruft" is negligible.

Re: SPAs Were a Mistake

#83

Post by uhoh-itsmaciek »

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?

I don't know. I'm not very familiar with Next.js (I'd heard about it but never really looked into it much). Your response inspired me to investigate, and I found an article by a Remix founder about the differences [1]. It's obviously biased, but maybe still interesting. It looks like there was an HN submission and a bit of discussion, too.

There's a bunch of other comparisons out there, too.

[1]: https://remix.run/blog/remix-vs-next [2]: https://news.ycombinator.com/item?id=29983950

Re: SPAs Were a Mistake

#84

Post by hinkley »

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 in the real world. If 1 is bad that doesn’t mean 200 is better. If 200 was bad the solution is not 1. The best answer is probably three.

Re: SPAs Were a Mistake

#85

Post by eithed »

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…

Those are very good points - I wonder how the author would see, for example, Google Sheets implemented as not a SPA

Re: SPAs Were a Mistake

#86

Post by vangelis »

aminerman wrote: post #39
softwarebeware wrote: post #29

I'm not clear why the author thinks that "media sites, really" are the only SPA use case. Have they never used webmail (like GMail), map apps (like Google Maps), or social networks (like Twitter)?

Quoted post unavailable.

Don't be an asshole.

Re: SPAs Were a Mistake

#87

Post by vinceguidry »

They were necessary from a perspective of "we need a way to develop a company's web presence in a way we can send kids to code camp to get the gist of." Of course they weren't a wonderful thing in terms of actually building sustainable infrastructure, but what's that to stand in the way of business's need to go to market yesterday?

Code camps don't have time or resources to educate their students so we got the reinvent-the-world half-solution that is the SPA. SPA frameworks won't ever go away but you'll get the chance eventually to go work on something better-architected than your run-of-the-mill NodeJS shitshow.

Re: SPAs Were a Mistake

#88

Post by elchief »

Lame opinion, but I miss the (pre-license-change) ExtJS days

Unified library of tools. An actual GUI designer to design layouts in.

Now everything's just a mess

Re: SPAs Were a Mistake

#89

Post by efdee »

zozbot234 wrote: post #14
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…

> the idea of essentially removing the network round trip when a user clicks on something is not a bad one. Practical SPA's have many more network roundtrips than the equivalent server-rendered web interface. Every AJAX request is an extra roundtrip, unless it can be handled in parallel with others in which case you're still dependent on the slowest request to complete. With SSR, you can take care of everything with…

If you can do it in a single GET/POST in an SSR, you can do it in a single XHR call in an SPA. There's no reason it has to be split up in separate XHR calls.

You just have to want to do it.

Re: SPAs Were a Mistake

#90

Post by efdee »

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.

In case of slow internet, SPAs are much easier to make responsive than an SSR application.
Post reply on HN