351–360 of 637 posts
Don't limit this to SPAs, include the Jamstack, which has all the same problems, and the false promise that if you can statically render a few pages or parts of pages and put them on a CDN, everything will be fast. It won't, because to load dynamic content, you still have to do a lot of work and talk to a (gasp) centralized API over the internet. SPAs and Jamstack favor developer convenience over end user experience.…
This is really, really important though.
Earlier quoted context omitted.
Have you tried to use a site that reloads all the data on every click, from a slow, distant (high latency), or metered connection? Same problem.
Of course, and it's usually not as big of a problem because everything you need comes in the page render. With SPAs it's not uncommon to have to click 5 or buttons/menus and then wait for data to load, then click again, and more data. That said there are plenty of SSR sites that are terrible too. It's not the technology that's at fault, but SPAs and common dev patterns in the community definitely enable and encourage…
How is that any different from SSR? Waiting for a full page reload is fine, but incremental loading is not?
Earlier quoted context omitted.
> Why're we throwing away years of learning to build unstable, complex and inaccessible applications? 1. Smart people seek out difficult problems. 2. Difficult problems drive the creation of complex, niche tools, that bear cultural associations with the smart people who made and use them. 3. People who want to be smart seek out complex, niche tools.
lmao yeah pretty much. I'm moving from a low code shop to Node/Vue because I can't keep people. They all want to pad their resume, so I'm going to build at 2x the cost just so I can keep the projects going.
Earlier quoted context omitted.
I pretty strongly disagree with this. The distinct advantage of an SPA is that, done correctly, cached data lets you render pages instantly. Who CARES if the SPA had to make 3xRTT in the background, if it can serve the next page up instantly because that data is already present and cached, it's a huge win. The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not. Still do…
> The server rendered app will ALWAYS have to wait at least 1xRTT for every new render. The SPA does not. Not necessarily. I think you're conflating caching/fetching and rendering here. You can cache rendered views in the same way you'd cache the data for those views. Turbo does this, for example. When you navigate to a cached page it will display the page from the cache first, then make a request to update the cache…
Sort of. There's been no shortage of vulnerabilities where user data has been exposed when an authenticated users request was cached and re-used for subsequent users. It's been my experience that most SSR apps disable caching for authenticated users, or rely on more explicit control of components for partial caching where possible.
Earlier quoted context omitted.
Well, the browser has certainly evolved past the point of SPAs being nothing but a hack. The browser has evolved into a heavily generalized application environment, as much as we may want to bemoan that. A good web client can surely demonstrate this. It's certainly true that you don't get to lean on built-in features like history support, but that's why you can now drive history with Javascript. And all sorts of othe…
> Rich client development is always hard—on any platform—, and you always make concessions for the platform you're on. I certainly have to when I'm building iOS apps. But I see no reason for this to dissuade you if you can push a better UX to the user. I think the difference is how much you as a developer have to "fight" the platform. Having to implement history management yourself very much qualifies as "fighting" t…
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…
> 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…
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…
> 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. 99% of SPAs break history related features in some way.
Most of the users I have to deal with still have problems with double clicking.
They don't understand basic browser features.
They don't understand that they can set preferred language in their browser.
History related features are not an argument in any way.
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…
> 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 a bit weird to me, in that I'd say that cuts in the opposite direction. State can exist in at least three locations for most applications: db, app server, and client. Keeping state consistent across all of them can be difficult in the best of times, but thin clients by their very nature carry less state, lessening the burden. Sometimes client state is necessary, for richer user interactions, but for all but the most cosmetic of purposes you're going to have to replicate that state on the backend anyway, to enforce business and security requirements.
Earlier quoted context omitted.
I feel like most people that hate SPAs never have to deal with this type of thing, or even only have to work on the backend. They just don't get it. Of course, if you're using a SPA for a static website, you're also doing it wrong but that doesn't mean SPA itself is a bad thing.
"They just don't get it" Believe me, I get it. I dealt with building these kinds of features for a full decade before SPAs became fashionable. Now I'm stuck here watching in frustration as people go all-in on SPAs because they didn't know how to solve these problems without them.
The assumption made in these posts is that you have total control over your entire application stack. Infra, Backend, Frontend, Ops, etc. In the real world, often times different companies are collaborating to build a final product for a client.
I worked at an agency that built an SPA because the frontend and backend were built by two separate companies at the same time. We’d meet to agree on what the APIs would look like and what shape to expect in the data payloads. Once we had some sample data, we could build a UI against that data.
When the real API was ready, we just switched the URL in the app config and everything started working.
If we didn’t build that as an SPA, we wouldn’t have been able to make the deadline the client was aiming for.
In a perfect world, would this have made sense to build as a MPA? Probably. But in the real world, you sometimes have to build things given some non-ideal constraints.