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

611–620 of 637 posts

Re: SPAs Were a Mistake

#611

Post by midrus »

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…

> they work if your connection is flaky,

Not saying it can't be done, but I haven't seen many SPAs that handles well flaky connections. Most stall with no indication to the end user, endless spinners or just broken in some random way.

Re: SPAs Were a Mistake

#612

Post by midrus »

horsawlarway wrote: post #45
zozbot234 wrote: post #14

Earlier quoted context omitted.

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

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…

> done correctly

Big assumption. This is what the whole discussion is about. Doing "correctly" an SPA is incredibly expensive.

I can also assure you that when an MVC application is done correctly you can have an equally good user experience.

> The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not.

This is an outdated idea of how server rendered apps work. See Unpoly, HTMX, LiveWire, Hotwire, etc.

I'm personally using Livewire. I make server request in only 2 situations. 1) When going to different pages (I'd need that anyway with an SPA given I need "SSR") and 2) When I'd need to write or read data from the server, which with an SPA would mean I need an API call anyway. Every other interaction is done with Alpine, 100% client side.

Re: SPAs Were a Mistake

#613

Post by midrus »

horsawlarway wrote: post #99
freedomben wrote: post #68

Earlier quoted context omitted.

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.

Yes - that's literally exactly what I talked about. I can tell you - My app renders immediately in these cases, precisely because I lean heavily on a cache. I preload basically all the data a user might need at startup (prioritizing the current page) and then optimistically render from cache. I'm very familiar with these kind of situations (I have developed software designed explicitly to handle offline-only cases, a…

This works great as long as it is not a first visitor though. For new visitors with a spotty connection this will be a nightmare. Also I assume any new update you release which might need to refresh the cache would also be a problem in this situation. I don't think it's that easy. Not saying that you're not doing it right, just that it is not a trivial thing and almost everyone else won't do this right.

Re: SPAs Were a Mistake

#614

Post by midrus »

midrus wrote: post #598
rrrhys wrote: post #456

Earlier quoted context omitted.

> Your arguments seem to be assuming a particularly bad implementation of a traditional backend. These weekly SPA complaint threads always assume a particularly bad implementation of a SPA as well though.

The key here is that if we consider equivalent good and robust implementations, equivalent capable teams, same UX, etc of an SPA and a traditional full stack MVC application with a modern ajax tool such as livewire, hotwire, etc the latter takes a fraction of the time and cost to build and the result is far less complex and easier to maintain. I've worked in both kinds of environments, and unless you're building an o…

*figma, not dogma. Autocorrect messed up and just noticed.

Re: SPAs Were a Mistake

#615

Post by midrus »

rtpg wrote: post #464
lolinder wrote: post #376

Earlier quoted context omitted.

Your arguments seem to be assuming a particularly bad implementation of a traditional backend. 1. A good server-generated-HTML backend will have no more state than a good server-generated-JSON backend. The client state is all stored in the client either way, whether in JS variables, HTML tags, or the URL. 2. A good server-generated-HTML backend doesn't do significantly more work just because its output is in HTML ins…

Multi-page forms without some front end stuff ends up with the very clunky either "rerender previous form pages over and over again, except hidden", or "have some token to track partial form data", or "build up a DB to store a partially complete form". With some frontend work you can have a multi-page form just work, with the data stored in the client up until final submission, and only sending in partial checks ahea…

> "rerender previous form pages over and over again, except hidden"

There are modern ways to do this, see Unpoly, HTMX, livewire, hotwire, etc. You're comparing with an outdated view of what an MVC application looks like. It's like to complain about SPAs because of backbone.js

> "have some token to track partial form data"

This is called "sessions", the token you refer to can be a cookie, which is done by default for free on any MVC framework. Doing this in any other way lead to either losing authentication on page reload or security vulnerabilities (storing a token in localstorage, etc).

> "build up a DB to store a partially complete form"

Again, you can store partial data in a session, for free. As it comes by default with any MVC framework.

One of the key points here is that with any of the popular MVC frameworks you don't need to rebuild the wheel and the car from scratch as with SPA frameworks, most of these things come for free, specially anything related to forms. This is something we're not used to have in the SPA world and everyone has a different way to deal with it.

> Multi-page forms without some front end stuff

Nobody says there shouldn't be any frontend stuff, you still need it of course. If fields are static between steps you can just render every step and toggle between different set of fields using something like Alpine, no need to reload from the server. If fields are dynamic and need some kind of database lookup between steps, Unpoly or livewire/hotwire make this trivial.

Please, let's stop comparing Next.js/React top modern SPAs to 20 year's ago struts MVC, it has not been like that since many years ago already.

Re: SPAs Were a Mistake

#616

Post by scrapcode »

porker wrote: post #481
coruja wrote: post #438

Earlier quoted context omitted.

I try to tell myself "don't get caught up in using a fancy frontend framework on this one," as I'm starting a new project, but I keep running into situations where my functionality would just work so much better. As an example, I was writing a tool the other day to automate some things that have to do with quotes for my 9-to-5. Being able to add inline functionality in Django to select a customer within the quote pag…

> Being able to add inline functionality in Django to select a customer within the quote page, or add / edit a new customer without having to leave that quote felt very 'hackish,' using the same jquery callback method used in Django Admin. Agreed. For form based apps I don't like to fall back to SPAs (bloat, the desire of every dev to reinvent forms in their framework, client and server side validation duplication),…

That is something I hadn't really taken the time to compartmentalize and articulate, but a js framework that focused on forms only would be wonderful. I'm sure that someone has taken a stab at it. Something like crispy-forms that added the ability to add components for variable data such as inlines...

I'm guessing that Vue.js may be a good drop-in for this, but it has been a while since I have used Vue.

Re: SPAs Were a Mistake

#617

Post by lolinder »

Graffur wrote: post #597
lolinder wrote: post #398

Earlier quoted context omitted.

We have a PHP app that doesn't reload the full page. We use jQuery's .load(), which has been around since 1.0: https://api.jquery.com/load/

Okay - build a complex site with JQuery and see how it goes..

That's what I'm saying: I maintain a complex web app that is built with PHP-templated HTML with jQuery sprinkled in as needed to make things more interactive. It's not perfect, but it's a far cry from the nightmare that people always seem to imagine when they think of "the jQuery days".

Would I use jQuery if I redid it today? No. But this app does prove to me that progressively-enhanced HTML is a valid path to an app today, it doesn't need to be an SPA.

Re: SPAs Were a Mistake

#618

Post by catlifeonmars »

recursivedoubts wrote: post #589
catlifeonmars wrote: post #447

Earlier quoted context omitted.

> perhaps that is wrong, but the web was pretty successful overall Since HATEOAS is rarely implemented fully in practice, it would be simplistic to point to it as the reason the web is successful. The web allows an incredible variety of different architectures —- Some more closely aligned to HATEOAS and some less so. Perhaps this is the reason for the success of the web?

HATEOAS was and is implemented widely and effortlessly in hypermedia , since Fielding was describing the existing web architecture. It has failed fairly dramatically in JSON APIs, because JSON is not a native hypertext. Early API designers tried to shoehorn HATEOAS concepts into their APIs, which was somewhat plausible when APIs were XML, which, when squinted at, looked sort of like a hypermedia. Once we kicked over…

I’m not arguing against that, just that huge chunks of the web break the HATEOAS abstraction, as it were, and yet, as you pointed out, “the web is pretty successful overall”. It’s not super clear to me that this is because of hypermedia or not in the sense that correlation is not causality.

Re: SPAs Were a Mistake

#619

Post by yencabulator »

int_19h wrote: post #580
littlecranky67 wrote: post #547

Earlier quoted context omitted.

because a database should not hold your business logic. It should hold your data, and that it can do well. See also my other post on parent for more reasoning.

Why shouldn't it? As noted above, database servers already have most of this (security) logic in them - likely tested much better than whatever you can write on top of the database yourself. And given how many apps are basically just CRUD, why reinvent the wheel every time?

Mostly because the tooling is so bad. Or do you have unit tests, lint, and easy version control for your stored procedures? Are they written in a way that matches at all what rest of your programming is? Can you import a randomly picked utility library?

Re: SPAs Were a Mistake

#620

Post by int_19h »

yencabulator wrote: post #619
int_19h wrote: post #580

Earlier quoted context omitted.

Why shouldn't it? As noted above, database servers already have most of this (security) logic in them - likely tested much better than whatever you can write on top of the database yourself. And given how many apps are basically just CRUD, why reinvent the wheel every time?

Mostly because the tooling is so bad. Or do you have unit tests, lint, and easy version control for your stored procedures? Are they written in a way that matches at all what rest of your programming is? Can you import a randomly picked utility library?

The next obvious question is, why is tooling so bad then? And would it have been so bad if we invested as much into RDBMS as we did into Node.js web-frameworks-of-the-day.
Post reply on HN