> SPAs will be slow no matter what.
Uh…no?
You’re presumably talking about specific terrible prebuilt frameworks - not someone building a nice vanilla SPA.
Uh…no?
You’re presumably talking about specific terrible prebuilt frameworks - not someone building a nice vanilla SPA.
especially when you’re writing your own stuff,
that’s when you know from the start that scaling doesn’t matter! =]
Related, and more powerful than my comments in this thread are going to be:
So you have to guarantee that your product will stay low users and low features forever or spend a very high effort to try to partially overcome that block when you change your mind.
And guaranteeing that it will stay low features is much harder than low users I think.
In exchange for that you get a better talent pool for recruiting but does that matter if your product has to stay low scale anyways?
It can work for some SaaS but if you stay low employee count, low users and you have a core feature used everywhere in the whole product and nothing else
Feels like a glaring omission =]
> Is it being used even sort-of in the right place / way?
It's a SaaS where users are mostly always logged-in, kind of an app so you would think it should work from the outside.
I think these are the full requirements I would put for a good SPA experience:
- low users
- low number of features / or a single main feature reused in different ways
- low number of employees
- it's an app and not a website
- you don't have any users living in remote places / poor internet connection
- users are all using modern browsers and can be asked to switch to another one if needed
And I think in my company we only have one of this list, making it painful.
at any point,
I’ll be checking back around later!
Until then: just talk smack about React!
None of these things you listed are critiques of single-page apps (SPA).
I'm sure counter examples of well managed SPAs do exist somewhere, it's just that it seems much easier to do the wrong thing compared to a traditional stack. This is why I'd not advise for it unless you have a very good reason.
The good stacks should make the good choices the natural way to do things, again my opinion.
Please stop changing the definitions of explicit words and phrases - to anyone reading this!
For example, a search function. For a MPA, each search query would be a new page. For a SPA, each query is a new logical page, served on the same real page.
Technically yes, a SPA may have minimal client side rendering. But then it’s not doing much of anything at all - it’s just a site. When people say SPA, they typically mean an application with client side rendering.
sigh
…does someone else want to finish this up?
To expand on what I mean, if the implication isn’t obvious: a SPA with no client side rendering is just a single HTML page. It’s a document, not an application.
So SPA naturally implies client side rendering.
The difference between a SPA and MPA isn’t the amount of pages, they both have about the same amount of logic pages. It’s about where those pages are rendered. Dynamically on the front end, or on the back end.
EDIT: okay okay to expand, my website has a contact form. With JS enabled, the form submit displays a little box that says “thank you for submitting”. With JS disabled, it navigates you to a “thank you for submitting” page.
Both are the same logic page, they have the same function. One page is just rendered client side, and one server side. Most websites or applications are hybrids. There’s very few true single page applications, and very few true multi page applications. Most SPAs have multiple real pages for different things. Most MPAs combine multiple logic pages into one real page.
> Most websites or applications are hybrids.
and some are emphatically not.
But…where were you going with that?
As soon as you, say, use JS to update the DOM or a canvas, I consider that client-side rendering. That you can do, and that would be a SPA.
But I’m curious, what are some examples, even hypothetical, of applications consisting of one HTML page? I don’t think I’ve ever seen it.
CSS (.css) JavaScript (.js) Plain Text (.txt) HTML (.html) SVG (.svg) Raster Images (.png, .jpg, .jpeg, .gif, .webp, .bmp) Audio (.mp3, .wav, .ogg) Video (.mp4, .webm) JSON (.json) PDF (.pdf)
plus bring in other source resources as needed.
To answer your question:
The installer for GrapheneOS / Google Pixel phones is an “SPA” (or “webapp”).
I’ve seen bespoke fitness trackers of all kinds,
appliance control apps,
budget and pace-tracking stuff,
basically all of what computer programs used to do - before we started dynamically loading a ton of extra stuff onto the screen that nobody needed to do the task they came to do.
So, they are truly inseparable IMO. You can’t have a SPA without some amount of client side rendering, your example demonstrates that. So, what makes a SPA a SPA is the rendering. A SPA is “single page”, but only in literal meaning. Logically, every SPA is many pages, you just render them purely client-side.
and none of this seems to have anything to do with the frontend being a single page.
Could you point out where you think the gotcha is? I can taste the tone.
Just because a bunch of engineers applied implicit meaning that didn’t exist to a very literal phrase for a few years doesn’t make it correct.
Doesn’t make webapps inherently bad.
Doesn’t make SPAs bad.
At this point, app pretty much implies React - ask an LLM for an app and see if that’s not what you get.