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

241–250 of 637 posts

Re: SPAs Were a Mistake

#241

Post by midiguy »

hinkley wrote: post #79
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 technolog…

> All of these unresolved arguments are about team dynamics, not technology

No, it's definitely about technology. Let me simplify this for you. Technology A can do thing 1 very well, and thing 2 decently. Technology B can do thing 2 well, but can't do thing 1 at all.

In reality, people who only do technology B claim technology B is necessary to do thing 2 and go to great extents to write blog posts claiming such, while people who only do technology A get on with doing things 1 and 2 without feeling the need to rant.

Re: SPAs Were a Mistake

#242

Post by 3np »

candiodari wrote: post #193
bastawhiz wrote: post #139

Earlier quoted context omitted.

> 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. This is largely solved with innovations like GraphQL (which you don't need a SPA to use). Pages that require multiple API calls can show their UIs progre…

What they're meaning is that the total time is longer for the SPA if you don't go all out (and nobody does). SPA: 1. get html from server (1 roundtrip) 2. get resources (js/jpg/movies/gifs/favicon/...) from server (1 roundtrip) 3. get ajax calls from server (1 roundtrip) 4. process answer from server + update page (not a roundtrip, but not zero) Vs traditional: 1. get html from server (1 roundtrip) 2. get resources f…

The more something behaves like an actual application and the higher the number of user interactions per visit, the more sense the SPA approach makes IMO. This is because the initial load overhead of an SPA gets amortized over subsequent interactions.

Blog or corporate/news website on one end and an interactive game or video editor in the other, with a site like FB somewhere in the middle.

It’s not a hard rule and I can already think of counter-examples but this line of thinking is useful when architecting a new project.

Re: SPAs Were a Mistake

#243

Post by remram »

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.

And if you don't, you're probably going to open in a new tab. Too many webapps are designed with complete disregards to the fact that browsers have tabs.

Re: SPAs Were a Mistake

#244

Post by acdha »

gowld wrote: post #78
RHSeeger wrote: post #69

Earlier quoted context omitted.

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

If one style of writing applications is far more prone to having “bad software”, consider that this is a valuable signal about the difficulty of using that style effectively. SPAs require you to take on ownership of more hard to debug challenges and that's an important factor to consider when selecting tools.

Re: SPAs Were a Mistake

#245

Post by [deleted] »

zippergz wrote: post #109
mattwad wrote: post #73

Earlier quoted context omitted.

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.

I'm living proof that it is possible to simultaneously hate SPAs and understand why they are popular. I've built and worked on a number of them, I don't have a better alternative to recommend, and yet I still hate them because I think they are a clunky solution to the problem. We need something better, but I'm not smart enough to come up with what that should be.

[deleted]

Re: SPAs Were a Mistake

#246

Post by kitsunesoba »

hombre_fatal wrote: post #230
Closi wrote: post #59

Earlier quoted context omitted.

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…

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" to some extent in my eyes… continuing with native platforms as an example, that sort of thing just isn't necessary in most cases – like with iOS, 99% of your "history" management comes for free with some combination of UINavigationController and view controller presentation, assuming the use of UIKit.

Re: SPAs Were a Mistake

#247

Post by horsawlarway »

NoGravitas wrote: post #235
horsawlarway wrote: post #129

Earlier quoted context omitted.

Look - I understand that I'm making a tradeoff here, and I'm very clear that not all sites are the right fit for an SPA. But yes - I explicitly handle offline-only use cases, and god-damned terrible connections (think They call in excited as all get out when they realize they only have to wait once with my application, and not once every page load. It's the difference between having a chance to grab a coffee at the s…

Your application seems to be a magical unicorn (not being sarcastic!). Most SPA websites I use on a regular basis end up having to reload all of their page components every visit, and frequently on every 'back'.

I'll be really honest here - it helps that it was a direct requirement from day one, and we have financial incentives aligned with handling the offline-only case.

If you handle offline up front - you mostly get bad connection speed wins by default.

It also helps that our app really isn't intended for casual use - ex: we have very few users who just load a page or two and then leave. Mostly they'll be interacting with the page for a duration of between 30 minutes and 2 hours (sometimes as often as once a second).

So yes - very much not a "blog" or "news" or "social media" site, and I think the value proposition for most companies might be harder to sell.

But I personally find it very, very nifty that we can do this at all in a browser. 10 years ago it would have required an installed application, or a port to each mobile platform. Which is sadly still a hard sell in some of the particularly poor school districts we worked with (mostly computers from the early 2000s, if you're lucky a really cheap tablet - like a kindle - floating around)

Re: SPAs Were a Mistake

#248

Post by wrs »

dboreham wrote: post #158
wrs wrote: post #76

Earlier quoted context omitted.

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…

GUI application patterns predate the 90s (Mac, X11, Apollo Domain, Xerox Star, etc)

Of course yes, GUIs go all the way back to Sketchpad in 1963. The PARC work was more about putting files on a server than putting the application logic on a server. X11 put all of the application on a server (or as X11 calls it, a client…). Based on my bookshelf, the “client-server” paradigm of putting the UI part and a substantial portion of the related logic on the client, but with most of the business logic on the server, reached mainstream adoption in the 90s.

Re: SPAs Were a Mistake

#249

Post by bastawhiz »

candiodari wrote: post #193
bastawhiz wrote: post #139

Earlier quoted context omitted.

> 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. This is largely solved with innovations like GraphQL (which you don't need a SPA to use). Pages that require multiple API calls can show their UIs progre…

What they're meaning is that the total time is longer for the SPA if you don't go all out (and nobody does). SPA: 1. get html from server (1 roundtrip) 2. get resources (js/jpg/movies/gifs/favicon/...) from server (1 roundtrip) 3. get ajax calls from server (1 roundtrip) 4. process answer from server + update page (not a roundtrip, but not zero) Vs traditional: 1. get html from server (1 roundtrip) 2. get resources f…

> For instance you need a separate "GetListOfUsersAndDetailsOfFirstUser()" (or more general "getEverythingForPageX" calls). You can't do "GetListOfUsers()" and "GetUserDetail()" separately.

This is literally a core use case of GraphQL. But you probably also want to fan out to preload all of the other user data in one API call: that's the whole point of doing it on the client. If you are trimming the handful of kilobytes on the first request, you're paying the price for that on each subsequent load.

> I know react can do it, but does anyone other than facebook actually do that?

Yes. Every job I've worked at professionally since 2016 (when this became mainstream) has done this. I do it in my side hustle. It's really not that hard.

> 2. get resources (js/jpg/movies/gifs/favicon/...) from server (1 roundtrip)

This doesn't go away with traditional sites.

Post reply on HN