Mastodawn

Stuart Langridge Nov 27

RE: https://toot.cafe/@nolan/115622706069488954

Those of you who are not web devs (good choice) may not quite appreciate what this means.
You know how websites are loads slower now, and don't work without JavaScript? Well, one of the big (dubious) arguments made in favour of this transition was that you download a bunch more code first, but then it'll make everything faster once you're there. It's front loading.
What @slightlyoff has shown is that this is not relevant, because people don't stay on the sites long enough to get the benefit.

@sil @slightlyoff Typically SPAs aren't "sites", though. It's in the name, they're applications. Those are things you DO keep open for long periods; Calendars, email clients, forums, etc.

SPAs being shoehorned into sites and landing pages by teams that didn't know better at the time is unfortunate, but mostly mitigated by SSR these days anyway.

Also, let's not kids ourselves; it isn't SPAs that are the problem, it's React specifically. It's the slowest at DOM manipulation, has one of the heaviest runtimes, and seems to almost be designed to cause re-render issues.

Stuart Langridge Nov 28

@soviut @slightlyoff It is not true that SPAs are all long-running applications, not at all. Maybe that was the original goal, but it is considerably wider than that now.
Definition: a site is an "SPA" if clicking a link doesn't work without JS. (Having the link not even be there to be clicked without JS also counts.)
By this, a lot of newspapers are; most restaurant sites; most promotional sites: how are these things "sites I keep open for a long period"? All I want is to see the opening hours!

@sil @slightlyoff I acknowledged that some sites are SPAs when they shouldn't be.

Though, I'd argue that a restaurant site with any kind of online ordering capability is an application, just like UberEats, DoorDash, etc.

And even if a site is a SPA when it really shouldn't be, SSR solves that by giving you fast time to first paint before hydrating. So you can glance at the hours of operation. Most sites built as SPAs need SSR anyways for per-page SEO metadata.

That's the true indicator; if your project needs SEO, it's a site and if it doesn't it's an app (since most apps are behind a login anyways).

Alex Russell Nov 29

@soviut @sil Oh man, if only we'd been able to [ checks notes ] display a list of options and [ double checks ] build checkout flows before SPAs.

@slightlyoff @sil I wasn't being rude or sarcastic so there's no need for you to be; keep this civil.

I never said it was impossible to build those flows without a SPA, only that SPAs are intended to be applications, not sites. The examples I gave were just applications where a SPA could shine; not where it was somehow the only option.

Have sites been built as SPAs? yes. Is it the best use case for them? No. Just because a team chose the wrong tech to build something doesn't invalidate the tech.

I've built ordering systems back in the day as MPAs and their UX was never as nice as a stateful frontend app. And building a stateful frontend app is a lot nicer with Vue than vanilla JS. However, if I'm building a landing page, that's going to be Astro these days.

Alex Russell Nov 29

@soviut @sil But it's those same flows where this technology tends to fail most spectacularly. Go trace your local food delivery system w/ WPT or a low-spec device. Here in the US, the UIs of Grubhub, Caviar, Opentable, and many others have been totally destroyed by this tech.

I've been getting variations of "we need this to be built in a heavyweight JS framework because 'it's an app'" for years and years, and I'm not going to take the theory as valid when ~all of the practice cuts against it.

Alex Russell Nov 29

@soviut @sil That said, I agree that when things come in under specific budgets, this can be a better way to build certain classes of UI. I'm using elk.zone to post this, and it's wonderful. The YT PWA is pretty great. But these are exceptions that prove the rule: the set of teams that can be trusted to do a good job with an SPA stack could deliver a great experience without it.

@slightlyoff @sil I've worked several times with those teams who picked the wrong tech. They did so because they're cargo culting and would fare even worse with vanilla JS or an MPA.

The issue is many of them don't have deep web fundamentals. Not because of frameworks, but because the web is notoriously vast and constantly churning. I happen to like the churn but many find it exhausting and I don't blame them for that.

At the very least, Frameworks are well documented mostly static targets that let developers focus more on solving problems rather than fighting their browsers. Frameworks are solving a people problem more than a technical one.

Alex Russell Nov 29

@soviut @sil in my (now approaching a decade) of consulting around this, i depart from your analysis because the messes low-expertise teams make with vanilla/MPA are clearer and involve less JS. That's a structural advantage in the face of growing device inequality.

@slightlyoff @sil Not only have I seen way worse structural MPAs, but I've seen ones that are terrifyingly insecure as well.

The blast radius of a mistake in server side is so much worse. You see it now as server components and mixed client/server state accidentally leak because a convention got messed up.

These teams will exist no matter what and their impact will be worse the closer to the metal you put them.

Alex Russell Dec 2

@soviut @sil Again, from my experience of more than 100+ consulting engagements, this is not correct. Closer to the metal creates limiting factors. We saw this clearly in the evidence from SNAP sites:

https://infrequently.org/2024/08/object-lesson/

Reckoning: Part 2 — Object Lesson

SNAP benefits sites for more than 20% of Americans are unusably slow. All of them would be significantly faster if states abandoned client-side-rendering, and along with it, the legacy JavaScript frameworks (React, Angular, etc.) built to enable the SPA model.

Alex Russell

@slightlyoff @sil If closer to the metal limited factors, then PHP sites would be a lot less prone to issues. Instead, it took a framework like Laravel to remove a lot of the PHP "foot guns".

I'm not disputing that showing a loading spinner on a benefits site is ridiculous. If you need one before you can even interact then you've already failed.

Building performant frontends isn't a hard thing to do, just something you have to be aware of. In my experience, this mostly boils down to saying no to "grid" components and no to charts libraries, haha.

@soviut @sil PHP sites *are* less prone to these excesses. You can make messes there, sure, but they *tend* to end up in a lane that is less catastrophic because they are not failing to scale due to client-side resources and link-level constraints. There are counterexamples, but most of the last generation (as I note in that piece) are better than a lot of what current-era frameworkist nonsense produces on the regular. This is a numerate question, and current practices are *measurably* worse.

@slightlyoff @sil Less catastrophic? Every major data breach for nearly a decade was Wordpress sites getting hacked. Even popular open source maintainers couldn't secure their PHP.

All I'm saying is, call out the actual culprits; in this case, React. Vue and Svelte are both are more efficient and better citizens in the space.

Alex Russell Dec 2

@soviut @sil I'm saying "you should do more on the server, less on the client" and you're responding with "PHP bad!", and it *feels* like you're not engaging in good faith.

@slightlyoff @sil What I'm saying is the stakes are even higher in the backend. Those same inexperienced developers who made a bulky frontend are now able to create real security vulnerabilities.

This isn't me speculating, I've encountered it several times. I had to pause a project because I discovered over 5000 SQL injection vulnerabilities in their API. The only reason they hadn't been utterly pwned is because their host had some rudimentary injection prevention middleware.

Had they used a framework, they wouldn't have been able to produce those vulnerabilities (at least not as easily as they did raw dawging it).

To summarize, servers are a luxury and should be treated as such. If your team is struggling to ride a bicycle, don't give them a motorcycle.

Alex Russell Dec 2

@soviut @sil This is presenting a completely false choice, and I think you know it.

@slightlyoff @sil I don't believe that at all. Unskilled developers in the frontend are significantly less dangerous than when they're granted access to the backend.

Just look at all the accidental leaks that have happened in Next when those same devs have direct access to the database and secret keys with server actions and such.

That doesn't mean solutions like SSR aren't viable. You get much better time to first contentful paint, avoid loading spinners and don't have to heavily modify your frontend app to accommodate it.

Point being, yes, you can optimize at the server, but it comes with risks that pure frontends don't.

Alex Russell Dec 2

@soviut @sil Then let me say as a former webappsec professional and frequent collaborator with contemporary teams across the spectrum, you are not correct.