JavaScript is great. I love using it, and it does amazing things. But maybe it’s time we stop repeating these same patterns of development over and over again. Maybe we can use JavaScript more responsibly, and focus more effort on HTML and CSS.
I don’t agree with all of these takes-of-varying-spiciness, but Rich Harris is always worth paying attention to.
This isn’t an opinion piece. This is documentation.
You can’t JavaScript your way out of an excess-JavaScript problem.
I guess the biggest criticism here is that it feels like people who believe in the superiority of single page applications and the entire ecosystem focus more on developer experience (DX) than user experience. That sounds like a dangerous blanket statement, but after all these years, I never had the feeling that the argument “better DX leads to better UX” was ever true. It’s nothing more than a justification for the immense complexity and potentially significantly worse UX. And even if the core argument isn’t DX, other arguments like scalability, maintainability, competitive ability, easier recruiting (“everyone uses React”), and cost effectiveness, in my experience, only sound good, but rarely hold up to their promises.
Imagine the web is a storefront, React is a hot dog car, and here’s Create React App dressed as a hot dog:
HTML is the cornerstone of the web — so why does creating a “React app” produce an empty HTML file? Why are we not taking advantage of the most basic feature of the web—the ability to see content quickly before all the interactive code loads? Why do we wait to start loading the data until after all the client-side code has finished loading?
When I wrote about my hopes and fears for the View Transitions API, a few people latched on to this sentiment:
If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.
But I also wrote:
If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.
I think it’s worth focusing on that.
Part of the problem is that I gave my hopes and fears an equal airing. But they’re not equally likely.
Take the possibility that the View Transitions API only ships for single page apps, but never ships for regular page transitions. The consequences of that would be big—the API would act as an incentive to build single page apps. But the likelihood of that happening is small. In fact, according to Jake, there’s already an implemention for page transitions in the works at Chrome.
Now what if the View Transitions API ships for pages? The consequences would be equally big—the API would act as an incentive to ditch single page apps and build in a more performant, resilient way. Best of all, the chances of that happening are very large indeed (pretty much a certainty now, given Jake’s update).
So I made a comparison between both of the consequences, which are equally large, but I didn’t make a corresponding comparison of the likelihoods, which are not equally large. Mea culpa!
I should’ve made it clearer that, although the consequences would be really bad if the View Transitions API only supports single page apps, the actual likelihood of that is pretty slim.
That’s probably my negativity bias showing through. (The reason I have a negativity bias is because I am a human. Like, have you ever noticed that if you get feedback on something and 98% of it is positive, you inevitably fixate on the 2%?)
Anyway, the real takeaway here is that if the View Transitions API ships for pages, then the consequences will be really, really good! It would be another nail in the coffin for monolithic JavaScript frameworks slowing down the web. And best of all, the likelihood of this happening is very high!
So let me amend my closing sentences from my previous post:
If the View Transitions API only works for single page apps—which is very unlikely—it could be the single worst thing to happen to the web in years.
If the View Transitions API works across page navigations—which is very, very likely—it could be the single best thing to happen to the web in years.
The glass is half full and it’s only going to get fuller. Time to start planning for a turbo-charged web now.
If you’ve got a website with full page navigations, start thinking about how you’ll be able to apply the View Transitions API as a progressive enhancement to improve the user experience.
If you’ve got a single page app, start thinking about how to ditch a whole bunch of uneccessary dependencies to make a more lightweight foundation of HTML instead of JavaScript, and still get all those slick transitions you get in a single page app!
I am simultaneously very excited and very nervous about the View Transitions API.
You may know it by its former name—Shared Element Transitions. The name change is very recent.
I’ve been saying for years that some kind of API like this would be brilliant:
I honestly think if browsers implemented this, 80% of client-rendered Single Page Apps could be done as regular good ol’-fashioned websites.
Miriam Suzanne describes the theory of View Transitions succinctly:
Shared-element transitions are designed to work with standard web navigation across multiple page loads, as well as page transitions in ‘single-page’ apps (often called SPAs).
This all sounds brilliant. But the devil is in the implementation details. Right now, the API only works for single page apps. This is totally understandable. For purely pragmatic reasons, single page apps are a simple use case to solve for. It’s going to take a lot more work to get this API to work for multi-page apps (or as we used to call them, websites).
If we get a View Transitions API that works across page navigations, it could potentially turbo-charge the web. It will act as a disencentive to building single page apps—you’d be able to provide swish transitions without sacrificing performance or resilience at the alter of a heavy-handed JavaScript-only architecture.
But if the API only ever works for single page apps (which is the current situation), then it will act as an incentive to make any kind of website into a single page app, regardless of whether it’s actually the appropriate architecture.
That prospect has me very worried indeed.
I’m making my feelings on this known just in case any of the implementators out there are thinking, “Hey, maybe it’s fine that this API only works for single page apps—I’m sure most people would be happy with that.”
If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.
If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.
Update: Jake says:
We’re currently landing code in Chrome for the MPA version.
Very happy to hear that! It’s already in the spec, but it’s good to hear that the implementation isn’t going to lag too much.
Also, read this follow-up.
I’ve smelt the same change in the wind that Chris describes here—there’s finally a reckoning happening in the world of JavaScript frameworks and single page apps.
I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.
But Brad makes the interesting point that, because they were incubated when profligate client-side JavaScript was all the rage, web components may have ended up inheriting the wrong mindset:
So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.
The primary benefit of Progressive Enhancement is not that “your app works without JavaScript” (though that’s a nice side-benefit) but rather that the mental model is drastically simpler.
I think that’s the primary benefit to developers. The primary benefit to users is that what you build will faster and more resilient.
Anyway, this is a really good deep dive into different architectural choices for building on the web. Although I was surprised by this assertion in the first paragraph:
The most popular architecture employed by web developers today is the Single Page App (SPA)
Citation needed. Single Page Apps do indeed dominate the discussion, but I don’t think that necessarily matches the day-to-day reality.
The problem I’ve regularly encountered in my work is that I don’t get to do my job the way I think is best for both me and my employer or client. The employer, who isn’t the web development expert, almost always has a clear idea of what real web development is supposed to look like: Single-Page-Apps and React (or React-like frameworks).
An intimation that it wouldn’t be the right solution for this particular problem is taken as an admission of incompetence.
I’ve experienced this. And I think this observation is even more true when it comes to recruitment.
While I’ve always been bothered by the downsides of SPAs, I always thought the gap would be bridged sooner or later, and that performance concerns would eventually vanish thanks to things like code splitting, tree shaking, or SSR. But ten years later, many of these issues remain. Many SPA bundles are still bloated with too many dependencies, hydration is still slow, and content is still duplicated in memory on the client even if it already lives in the DOM.
Yet something might be changing: for whatever reason, it feels like people are finally starting to take note and ask why things have to be this way.
Interesting to see a decade-long perspective. I especially like how Sacha revisits and reasseses design principles from ten years ago:
- Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.
Verdict: 👎
It’s since become apparent that you often do need to send HTML over the network, and things seem to be moving back towards handling as much as possible of your HTML compilation on the server, not on the client.
At the risk of grossly oversimplifying things, I propose that the core of the debate can be summed up by these truisms:
- The best SPA is better than the best MPA.
- The average SPA is worse than the average MPA.
I’ve got the same hunch as Nolan:
There’s a feeling in the air. A zeitgeist. SPAs are no longer the cool kids they once were 10 years ago.
And I think he’s right to frame the appeal of single page apps in terms of control (even if that control comes at the expense of performance and first-load user experience).
This is very convincing.
This is a really excellent four-part series on web performance that really dives into the technical details and asks all the right questions:
The headline is a little misleading because if you follow this advice, your multi-page apps will be much much faster than single page apps, especially when you include that initial page load of a single page app.
Here’s a quick high-level summary of what I do…
That’s an excellent recipe for success right there!
Browsers give you a ton of stuff for free, built right in, out-of-the-box. SPAs break all that, and force you to recreate it yourself with JavaScript. Most developers do it wrong, and for the ones who do it right, it results in a ton of extra code to recreate features the browser already gave you for free.
This is a terrific and nuanced talk that packs a lot into less than twenty minutes.
I heartily concur with Rich’s assessment that most websites aren’t apps or documents but something in between. It’s a continuum. And I really like Rich’s proposed approach: transitional web apps.
(The secret sauce in transitional web apps is progressive enhancement.)
I keep seeing Single-Page-Apps with huge JS files that only, in terms of concrete User Experience (UX) benefits, deliver client-side validation of forms plus analytics. Apps rarely leverage the potential of a Single-Page-App. It’s still just the same ‘click, wait for load’ navigation cycle. Same as the one you get with Multi-Page-Apps. Except buggier and with a much slower initial loading time.
When you look at performance, cross-platform and mobile support, reliability, and accessibility, nearly every Single-Page-App you can find in the wild is a failure on multiple fronts.
Replacing those with even a mediocre Multi-Page-App is generally going to be a substantial win. You usually see improvements on all of the issues mentioned above. You get the same general UX except with more reliable loading, history management, and loading features—provided by the browser.
Before you dismiss Baldur as a hater based on what I’ve just quoted, you should really read the whole article. The issue he points to is not with the technical architecture of single page apps, but with management.
Single-Page-Apps can be fantastic. Most teams will mess them up because most teams operate in dysfunctional organisations.
A lot of what he says really resonates with me. Over and over again I’ve seen projects where the technical decison around which monolithic client-side JavaScript framework to use has been made even before a problem has been defined.
Baldur’s conclusion chimes a lot with what I’ve been saying in conference talks this year: the biggest challenges facing the web are not technical in nature.
The biggest hindrance to the web’s progress isn’t non-expert developers, tooling, libraries, Single-Page-Apps, or Multi-Page-Apps.
It’s always humans.