SPAs Were a Mistake • Hacker News Board

Re: SPAs Were a Mistake

#391

Post by apatheticonion » Thu, Mar 03, 2022, 12:14 AM UTC

simonw wrote: post #286

It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…

I really view it as the opposite.

Prefer the writing of an SPA or serverless MPA.

If you consider that native desktop and mobile applications are siloed applications that coordinate with an API to achieve tasks - this is basically how SPAs or serverless MPAs work.

Part of the reason this is effective is because of the low cost nature of deploying applications like this.

For example; I can write a calorie counter that stores records in the client via indexeddb.

Given all the work is processed on the client, using an http server would be an unnecessary maintenance burden as it would simply server static files.

Rather than host the web application via a self managed http-server, I can just put my html files on S3 making hosting it free and unmanaged.

Should I decide I need to add user accounts and cloud storage - well I can then create a backend that exposes API endpoints to facilitate the tasks.

Those endpoints are then compatible with native applications, should I decide to write native mobile and desktop variations of my web application.

Furthermore, with Web Assembly expanding to offer the ability to write web applications using languages like C++, Rust, C#, Golang and the browser expanding access to OS subsystems like filesystem access - what we are seeing is that the browser is becoming a sandboxed UI toolkit, much like GTK or QT (except without native styling).

If there was anything that would empower Linux Desktops to be compatible with productivity software - it's progressive web applications.

Consider that Photoshop and Office are accessible on Linux via web today.

Re: SPAs Were a Mistake

#392

Post by lolinder » Thu, Mar 03, 2022, 12:14 AM UTC

polished85 wrote: post #323

simonw wrote: post #286

It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…

I initially thought part of the appeal was offloading the workload to the front end, where your processing power scales infinitely with each user's device. Maybe the benefit turned out to be negligible, I'm not really sure. Can server costs be reduced by offloading the work to the front end?

If you can actually offload substantial CPU cycles to the client, yes, you'll save server costs. But the SPA hype has led to a lot of SPAs that work like this:

> User clicks a tab. A request to server fetches the JSON data for the tab. Client renders it to HTML. User fills in some fields and clicks submit. A request to server sends the JSON form data and gets a JSON response code. Client shows a confirmation screen. ...

In this case, you're not saving much by templating JSON on the server instead of just templating HTML.

Re: SPAs Were a Mistake

#393

Post by KwisaksHaderach » Thu, Mar 03, 2022, 12:21 AM UTC

prmph wrote: post #167

dlisboa wrote: post #155

Earlier quoted context omitted.

The problem is the mixing and matching of state management. In a traditional web app all of the state is in the back end, in a SPA all of the state is in the front end. When we share state in between the two it's often messy. To me the answer feels like it should be "traditional web app for most things, components-as-first-intended for some things". The simplest React example is just one component that abstracts pres…

Exactly, the best approach seems to be where the app is composed of traditional pages with server navigation between them, but each page is implemented as an SPA. This approach eliminates the need for a client-side router, keeps any centralized page state small, and improves the SEO and bookmarkability of the app. I have implemented this architecture in several projects, and it’s effective

JS frameworks with a small footprint are suitable for this.

Re: SPAs Were a Mistake

#394

Post by lolinder » Thu, Mar 03, 2022, 12:21 AM UTC

gefhfffh wrote: post #390

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…

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

Re: SPAs Were a Mistake

#395

Post by gefhfffh » Thu, Mar 03, 2022, 12:22 AM UTC

tracker1 wrote: post #378

simonw wrote: post #350

Earlier quoted context omitted.

"A website has to go out of its way to mess this up." I know it's supposed to be easier, but I keep seeing teams mess this up.

I can say I've seen a lot of state management issues with SPAs... more with Angular than React, and almost none when using React+Redux well. I think a part of this is that a lot of developers simply don't desire, want to, get to or otherwise take the time to understand the framework they are using... It has been true forever... I can't tell you how many times I've seen stuff copy/pasted from StackOverflow, by devs th…

Tried ngrx?

Re: SPAs Were a Mistake

#396

Post by emteycz » Thu, Mar 03, 2022, 12:27 AM UTC

Closi wrote: post #381

emteycz wrote: post #108

Earlier quoted context omitted.

At least since HTML5 and CSS3 and ES6 (so many years already) these technologies are made for SPAs. There aren't many better UI frameworks, and WPF isn't that by a long shot.

I wouldn't really say that - CSS3 was made in 1999 so was hardly made for SPAs. Additionally HTML5 wasn't really ' made for ' SPAs, it added features to HTML which could help support SPA's but it's main design decision was to be 100% backwards compatible with the older HTML spec. HTML5 is made for SPAs the same way that a stretched limo is made for commuting.

SPAs are old though. Their popularity is modern, but I was making SPAs in 2005 - and it most definitely was a concern of HTML5 and CSS3; it was a concern even before, during the DHTML days. You're right it wasn't the primary concern - that's backwards compatibility, after the XHTML blunder - but that doesn't mean HTML5/CSS3 wasn't made with SPAs in mind.

Re: SPAs Were a Mistake

#397

Post by pphysch » Thu, Mar 03, 2022, 12:28 AM UTC

apatheticonion wrote: post #391

simonw wrote: post #286

It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…

I really view it as the opposite. Prefer the writing of an SPA or serverless MPA. If you consider that native desktop and mobile applications are siloed applications that coordinate with an API to achieve tasks - this is basically how SPAs or serverless MPAs work. Part of the reason this is effective is because of the low cost nature of deploying applications like this. For example; I can write a calorie counter that…

That's a lot of interfaces to create and maintain. The principle value of backend/MPA frameworks like Rails & Django is that they give you nearly all these interfaces for free in a neat package, which ends up being "good enough" for many use cases below Google-scale.

Re: SPAs Were a Mistake

#398

Post by lolinder » Thu, Mar 03, 2022, 12:33 AM UTC

Graffur wrote: post #344

simonw wrote: post #286

It's been so frustrating watch this play out over the past decade. I keep seeing projects that could have been written as a traditional multi-page application pick an SPA architecture instead, with the result that they take 2-5 times longer to build and produce an end-result that's far slower to load and much more prone to bugs. Inevitably none of these projects end up taking advantage of the supposed benefits of SPA…

That just sounds like poor performing developers to me. You don't need snazzy animations between states. Just not reloading the full page is a benefit.

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/

Re: SPAs Were a Mistake

#399

Post by gefhfffh » Thu, Mar 03, 2022, 12:33 AM UTC

lolinder wrote: post #394

gefhfffh wrote: post #390

Earlier quoted context omitted.

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

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

Re: SPAs Were a Mistake

#400

Post by sjs » Thu, Mar 03, 2022, 12:35 AM UTC

s17n wrote: post #370

com2kid wrote: post #329

Earlier quoted context omitted.

> And most of them don't spend the time to implement HTML5 history properly, so they break the URLs - which means you can't bookmark or deep link into them and they break the back/forward buttons. The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up. That aside, SPAs are great…

This is missing the real reason that people write SPAs, which is that React solved web components, which are hugely beneficial for almost 100% of web sites, and thus became the standard for building web sites, and with React it's easier to make an "SPA" than to make a "traditional" site and users don't know or care either way.

Users care they just don’t know why many modern websites are bad websites. Every website is now an app whether that actually makes it better UX or not.