Hacker News new | ask | show | jobs
by Aloha 1036 days ago
Who does need an SPA?
7 comments

People/stakeholders who want use the browser as an application platform.

Think data analysis tools, Intranet tools, e-commerce, and a host of B2B stuff?

I know, it all starts with a filterable list or a shopping basket, where page reloads or ajax "sprinkles" (regardless of what they're loading, HTML or JSON) are absolutely OK.

Especially the fully old-school approach with the page reloads - it can work and scale for simple and predictable requirements.

Until it doesn't - the first page with 5 interdependent autocomplete inputs takes weeks to develop and fix, the modals can't have routes without piles of jQuery hacks, and so on and ao forth

E-commerce is an example that clearly does not need SPA features. It needs great performance and SEO, not flying bells and whistles.

If a five input form takes week to fix, you have engineering problems beyond any choice of framework…

SSR and SSG+hydration are a thing though.
Excuse me while I go to my screaming room to imagine Google Maps as an MPA.
You don’t remember MapQuest?
I do, and that's why I moved to Google Maps as soon as it came out. The performance and UX of MapQuest was terrible.
That sounds pretty cool actually.
everything i built in the past few years only needed a generic CRUD backend, if it needed a backend at all. there is no application specific code in the backend, and the latest app i am working on is completely static as far as the backend is concerned. it could even be served locally via file://

all the application and interface logic is in the browser. this is only possible thanks to SPA.

Do you persist any data? Where does business logic reside? How do you validate inputs?
with a backend, data persistence is simply CRUD. for the backendless app, it's all in localstorage, and it can be downloaded into a file as backup. all the logic is in the browser, just like any desktop application. you should not need a server to manage personal data that is stored on your computer.

of course it is a tradeoff. if the user wanted to save their data outside the browser every few minutes then that would not be practical or if there is to much new data being generated so it doesn't fit into localstorage. i'd either need a server (even if running locally) that can save that data without user intervention or i should not use the browser as a development platform. in such cases a browser based SPA would have been the wrong choice. maybe electron, or a traditional desktop framework

My company does. It is a desktop level app written for the browser. And it is mostly done in Vanilla JS. No SSR since time to first load is irrelevant. They are about to sit down for an hour of solid work on a trusted platform, not buy a pair of shoes from an unknown site where waiting 500ms might make them change their mind.
Well, not long ago I made an in-browser WYSIWYG mouse-based diagram designer. I redefined a huge share of the default browser behavior.

It was also the first SPA I made, in a career of decades. I also think I do not regularly use anything that benefits from being an SPA (I don't regularly use that diagram designer either).

People who sell advertising for a living.
This is a joke, right?
No. From what I can tell the whole reason for a SPA is so that people don't leave your site. You throw away a lot of good things (like urls to content) so that you can push more ads at people.
Ah, I see your argument; SPAs are a preferred way to 'suck folks in' to a page and just have them stay there since they can't navigate in and out to the specific piece of content they want with URLs.

That about sums up everything wrong with our industry. Engagement over usefulness.

yes but none of that has anything to do with SPA as a technology.

the point of an SPA is so that i can share code and data for different pages in the browser without having to get it from the server for each new page.

it does not at all prevent me from using links to the outside or even within the site. (i just built an SPA where all navigation is done via regular links, each view has a different url, they all can be bookmarked, and history works too so you can go back and forth using the standard browser buttons, and links to certain resources take you out of the app)

> the point of an SPA is so that i can share code and data for different pages in the browser without having to get it from the server for each new page.

You still have to get it from the server for each new page, you just do it in the background.

Main side project of mine is a Strava-like web app to upload bike rides. It’s intended for personal use, so I don’t care how long it takes to load for random visitors arriving for the first time. I don’t care if search engines can properly load the page for content previews. I don’t care if someone’s ten year old Android device chugs on the JavaScript. I don’t care about dealing with the headache of making whatever JS library I’m using work with hydration.