6 ms·
Who does need an SPA?
by Aloha 3y ago
Who does need an SPA?
- soperj 3y agoPeople who sell advertising for a living.
- gortok 3y agoThis is a joke, right?
- soperj 3y agoNo. 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.
- gortok 3y agoAh, 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.
- em-bee 3y agoyes 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)
- soperj 3y ago> 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.
- em-bee 3y agoi don't need to get the code. nor the markup. that's already loaded in the browser. if i need to get anything, it's raw data. i also don't need to send anything back so i can manage state. being able to load data in the background can also improve the user experience. and for those apps that don't need a backend, i won't need to get anything ever after the first load. SPAs can, if written right, function completely offline, once loaded.
- soperj 3y ago> also improve the user experience It doesn't. Most users don't actually notice.
- marcosdumay 3y agoWell, 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).
- moritzwarhier 3y agoPeople/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
- ricardobeat 3y agoE-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…
- moritzwarhier 3y agoSSR and SSG+hydration are a thing though.
- em-bee 3y agoeverything 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.
- brtkdotse 3y agoDo you persist any data? Where does business logic reside? How do you validate inputs?
- em-bee 3y agowith 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
- afavour 3y agoExcuse me while I go to my screaming room to imagine Google Maps as an MPA.
- dullcrisp 3y agoYou don’t remember MapQuest?
- satvikpendem 3y agoI do, and that's why I moved to Google Maps as soon as it came out. The performance and UX of MapQuest was terrible.
- notpachet 3y agoThat sounds pretty cool actually.
- quickthrower2 3y agoMy 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.
- ecf 3y agoMain 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.