Hacker News Reader

Your arguments seem to be assuming a particularly bad implementation of a traditional backend.

Whenever someone says "this particular architecture is bad!" they're talking about a bad implementation of it.

The point is whether or not you're more likely to succeed at making a good app with an SPA or a multi-page site. For pretty much all brochure-styles websites and many SaaS webapps you're more likely to achieve success (for every common understanding of success) by using a multi-page architecture because they're usually simpler to implement, they work the way browsers expect things to work, and you don't need to implement some hard things yourself. You can make a brilliant SPA website for any purpose, but often people try and fail. Saying "you shouldn't have used an SPA" is shorthand for "You didn't understand or implement an SPA well enough, and now your web thing is failing to serve users as well as it should, and using a multi-page architecture would have avoided the problems your website has now."

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

You always have to fight with incompetency in any large codebase.

Incompetency exists the most in whatever the first thing that coders learn is.

I'm old enough to remember when that was c++, then it was java, php, ruby, jquery, now it's react.

It's always a trade-off. You can build things in the "cheapest" language (whatever the first one currently is) but then you'll inevitably get the cheapest code

That's really what this conversation is about in the long arc of coding

Skills and people are a pyramid. The more competency you demand the harder the people are to find.

We have this tendency to taint the tool by the users.

Incidentally after a language or tool loses "first learned" status it generally slowly regains its prestige.

We don't assume a c++ shop is a bunch of morons any more or that using php means you write nothing but garbage. One day vue/react/whatever will lose its first language status as well and I'll be here reading about something that might not have been invented yet being a trashy bad no good idea

Ultimately the technical merits are mostly cover for a conjecture of economic efficiency. There's a reason why people aren't defending things like applications built with Go/wasm bridges - those people are expensive

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 offline first app, dogma, or Google maps...SPAs make absolutely no sense from the engineering point of view.

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

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 ahead of time. This is qualitatively easier to handle, in my opinion.

It also seems extremely uncontroversial that sending data for a single item is going to require less text generation than sending over that data + the entire page.

These are all gradients, but people make absolute claims that don't hold up in these arguments.

"It also seems extremely uncontroversial that sending data for a single item is going to require less text generation than sending over that data + the entire page."

And yet... so many SPAs feel so much slower than MPAs. They suck down MBs of JavaScript, constantly poll for more JSON and consume crazy amounts of CPU any time they need to update the page.

If you're on an expensive laptop you may not notice, but most of the world sees the internet through a cheap, CPU and bandwidth constrained Android phone. And SPAs on those are just miserable.

Even if that is the case, is that your demographic?

Are those the people calling for an uber?

Are those people ordering off of doordash?

Furthermore, code splitting / lazy loading is available on many SPA frameworks so you don't have to download all the Javascript in one go.

I'm on expensive machine and notice a lot, too!

I also use a lot of "classic" websites where they fall over because of bad server-side state.

An example, a train reservation site, where I choose dates + a destination. The next page, it shows me some results. I decide to change the date. I hit the back button, and it falls over, cuz the state management on the server is messed up.

This happens a lot for me (this is mainly on Japanese websites), and it's extremely frustrating.

I don't like a lot of SPAs, I also don't like a lot of "classic" apps, but I do feel like SPA-y stuff at least demands less of the developers so the failure cases are a bit less frustrating for me. In theory.

And to the connections, the terrible websites with many megs of JS were likely terrible websites with many megs of HTML and huge uncompressed images before that... I don't want to minimize it (thank god for React, but old Angular bundles were the worst), just think comparing like-for-like is important.

EDIT: thinking about it more though, it's definitely _easier_ to send giant bundles on certain websites.

Given how many times this discussion happens on HN, I feel like instead of the hypotheticals, people should make a list of actual websites in both domains so that comparisons and proper critiques could be made...

> "I also use a lot of "classic" websites where they fall over because of bad server-side state.

An example, a train reservation site, where I choose dates + a destination. The next page, it shows me some results. I decide to change the date. I hit the back button, and it falls over, cuz the state management on the server is messed up."

any idea to not fall into a pit making an website/app/whatever?

I see your point, but managing state is not free on the client side either. Frontend frameworks usually come with some built in state management, but once it starts to be more complicated we often need to find a 3rd party library to manage it.

I agree that there are many cases where managing the state in the frontend is the preferred solution. Multi-page forms add complexity for both frontend and backend. Sometimes frontend is less complex, and other times the backend is simpler.

I'll add some comments on your statements regarding backend. I'm not saying it is a better solution than managing it on the frontend for all cases. My point is that although it adds complexity on the backend, it does not necessarily mean that managing state on the frontend is simpler. That depends on the use case, but I think a lot of developers "default" to handling state on the frontend that adds much more complexity than a simple backend solution.

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

In that case, you would only render hidden <input> fields with the values, and not the complete form. The code for receiving "step x" of the flow, would simply read the parameters from the request and include the values in the html code.

> "have some token to track partial form data"

Using <input> fields for this is much simpler. The final page would just read all variables as if they where posted from the same form, without requiring to generate/parse any tokens

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

Most frameworks have a built in "session" that abstracts this away. It may be stored in a database, file, memory etc. If you require distributed sessions, the framework often handles this transparently by just configuring the session manager to use something like Redis to store the data.

I've built a multi-page form in an SSR app with a tiny dash of JavaScript. The form's children are divs. The Next button hides the current div and shows the next one. The final Submit button is just a regular submit.

If you get into more than 3 pages, this isn't a great approach for various reasons, but you don't need to reach for a framework the instant you have a multi-page form.

The alternative to SPAs is not 90s pages reloads.

Nowadays you have livewire, hotwire, unpoly, htmx and several other modern solutions.

The alternative to SPAs is not 90s pages reloads.

Nowadays you have livewire, hotwire, unpoly, htmx and several other modern solutions.

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

Most SaaS developers aren't serving APIs to their clients, they are serving websites and web applications.

Applications have state. In order to render and deliver the application, the server needs to have some concept of what that state is.

> a bit of extra text

Doesn't really sound like an application, but a website.

In a web app it can happen that you use it for an hour without the backend doing a single thing.

> There are only fewer languages to deal with if you aren't in charge of writing backend code.

You don't have to deal with them at the same time

> Doesn't really sound like an application, but a website.

"text" here is as in "text/html", not as in "English-language copy".

> In a web app it can happen that you use it for an hour without the backend doing a single thing.

I would submit that this is an extremely rare case. The most involved web apps I interact with (say, Figma) are constantly syncing their state with the server. The simplest (say, TurboTax) save state as I move on to the next screen.

If you do have a case where you can pull that off, then by all means use an SPA. But it's weird to say that something isn't a web app unless it can go long periods of time without server interaction.

I haven't said that something isn't an app, unless it can go long periods of time without server interactions.

Generally, server interactions are arbitrary with SPAs, while SSR will happen all the time.

Going only a few minutes without server interactions in an interactive app is a big leap compared to SSR.

PS: I not only can pull that off, but I did. It's not too hard to think of apps like that. Consider e.g. Vscode

If the app is VSCode or anything like it, that's a great candidate for an SPA and I agree wholeheartedly that you made the right choice.

> Doesn't really sound like an application, but a website.

That's probably the key thing - most companies building SPA's don't really need an application but a website. There are many interesting products that need to be applications because of the functionality they need, but for every one such product there's at least a dozen that does not.

There is no black or white here. 98% of every site is in between those things and you could consider them one way or the other. Is reddit a website or an application? is a backoffice dashboar a website or an application?.

The problem with SPAs is not the technology or the architecture itself. The problem is everyone thinks, by your own definitions, they are building an "app" by default.

I've already worked for several teams which struggle to get almost anything done and everything takes ages to ship because of the fanaticism of using React for everything. God, some didn't even know you could submit a form without building a json API endpoint.

> Doesn't really sound like an application, but a website.

Yeah, well, from the name of it, doesn't that sound like what the Web is for?

I mean, we already have systems to run applications on; they're called operating systems.

Not only SPAs but "web applications" as a whole are a mistake IMO.

> isn't going to increase your CPU load in any meaningful way.

yes but it would be soul crushing for a developer

Why?

I’m not experienced with best in class tooling (probably with worst) but seems very quick, easy and native to render html using js.

> seems very quick, easy and native to render html using js.

Seems even quicker, easier and "more native" to render HTML as, you know... HTML.