This post is a (lightly edited) transcript of an internal chat we had about recent goings on in the tech industry.
kelly (Kelly Fitzpatrick): As we are (somehow already) a few months into 2023–and I am just coming back from PTO–I wanted to get all the RedMonk analysts together to catch up on what has been front of mind for them lately. Today’s topic: SPAs (single page applications).
@kate the first thing I read upon my return was your recent (and excellent) SPA Wars post, which everyone should read but (for those of us who did not do the homework), can you give a TL;DR?
kate (Kate Holterhoff): One of the coolest things about joining the RedMonk team was that I had full reign to talk about FE engineering. This was my former role before becoming an analyst, and I have SO MANY thoughts. This article really came out of the firestorm in the FE community on the subject of SPAs.
kelly: You do a great job in the post of cataloging some of the recent debates. Are there any that you’d put on a shortlist?
kate: Alex Russell’s The Market for Lemons really kicked the hornet’s nest, and Laurie Voss’s rebuttal are must-reads in terms of the debate, although there are more tempered responses from practitioners (Johan Halse’s What to expect from your framework is hilarious, fwiw). Here’s my summary of complaints against SPAs from the post:
When they first took off during the 2010s, SPAs were a revelation. However, the turn against them is accelerating. Critics point out that SPAs are difficult to build, requiring more experienced developers. They are expensive to run (both environmentally & monetarily). SPAs are prone to performance problems, largely caused by client-side rendering. SPAs prioritize the developer’s experience over that of the user, and can be especially frustrating for users with accessibility issues (older devices, poor networks). SPAs lack resilience owing to their dependence upon JavaScript. The browser can recover from HTML’s failure, but when JS fails everything crashes. They are overkill for many projects. While frameworks for creating SPAs including Angular, React, Ember, and Vue are excellent solutions for the use case of large, complex apps, most projects do well to avoid them.
kelly: and now for those of us who did not do the slack-chat homework: read away.
rachel (Rachel Stephens): This debate caught my attention because it really put user experience and developer experience as opposed forces.
We can dive into specifics about frameworks and the merits of the arguments, but that’s where I was most curious to get the team’s takes.
kelly: ok, @rachel clearly did all the the homework.
rachel: (meh)
(I get like a 50% 🙂 )
kate: It’s worth noting that I was unable to find any women who have written about the SPA Wars, although it’s entirely possible I just didn’t see any
kelly: Or is it possible that their thoughts were drowned out by reply guys?
kate: @kelly I hope that’s the case, and folks can point me to all the voices I missed.
monkchips (James Governor): Dear Lord the Alex Russell piece – The Market For Lemons – is really wonderful, in an absolutely screw you kind of way. So much shitposting in so many words. And such words! “Utterly Failed” “complexity merchants” “shoddy products” “sandy foundations”.
Over the last ten years, they have worked overtime to make frontend an evidence-free zone. The hucksters knew that discussions about performance tradeoffs would not end with teams investing more in their technology, so boosterism and misdirection were aggressively substituted for evidence and debate. Like a curtain of Halon descending to put out the fire of engineering debate, they blanketed the discourse with toxic positivity. Those who dared speak up were branded “negative” and “haters”, no matter how much data they lugged in tow.
Yes. Luckily this piece was not at all intended to rile people up. We live in an environment that prizes either outrage or confirmation bias above all else, and Russell shot his shot, and put it in our veins. Wooh!
kate: Worth noting that @monkchips shared Guillermo Rauch’s tweet in January
SPAs were a zero interest rate phenomenon
— Guillermo Rauch (@rauchg) January 29, 2023
sogrady (Stephen O’Grady): From what I can tell from Twitter basically everything is a Zero Interest Rate phenomenon at this point.
monkchips: True story. Hopefully all the shitty things will get fixed now.
kelly: Just going to ask for the folks who won’t: what is a “zero interest rate phenomenon”?
kate: +1
monkchips: That sounds like a question for our finance person.
kelly: Our brilliant finance person.
sogrady: @rachel: that one’s yours.
rachel: Pass.
kelly:
rachel: Fine. So as I understand it, the crux of “zero interest rate” arguments is that there was a decade+ of investment capital looking for a place to go because interest rates were artificially low.
kelly: So lots of free money?
rachel: Indeed. So the argument behind all these “zero interest rate phenomenon” tweets as I read it is that things received investment that otherwise might not have, which means that technologies proliferated that otherwise might not have.
Which, if that’s the correct interpretation, is an interesting thing for the founder of Vercel to tweet…
sogrady:
kelly:
kate: I think the “zero-interest” move also resonates with FE folks anxious about to the reckless expansion of JS, and the cost of shipping it, which is becoming less and less feasible in today’s market
— Plausible Sounding-Guff @[email protected] (@monkchips) February 3, 2023
monkchips: All the money that might have been usefully put in normal places has gone into VC pockets and crypto. That is the BS that is the zero interest rate phenomenon.
Screw You Web 3!
The understanding that SPAs suck is not new. My friend Fable has been bitching about them for the longest time. In fact back then they were called Single Page Web Apps. Always the ranting from Fable. Which is to say the complaints are not new. Folks have been complaining about SPAs for ten years at least.
Perhaps not surprising that a Rubyist of note would be shitposting about JS-based SPAs, but still.
kelly: @kate I want to hear more about the feasibility of shipping JS.
kate: Well, the idea of shipping more JS to the client is fine and dandy for folks with new devices and fast internet, but it makes for garbage UX for folks with older devices and slow connections. Luca Casonato from Deno summarizes the situation well:
client-side JavaScript is really expensive: it slows down the user experience, drastically increases power consumption on mobile devices, and is often not very robust.
monkchips: Garbage UX!
Like what if we just used HTML yo?
Bruce Lawson gave a great talk about the value of HTML at my conference Monki Gras in the before times, couching the JS problem in terms of a lack of accessibility.
kelly: but @monkchips even I can do HTML.
rachel: but can you do CSS?
sogrady: No one can do CSS.
kelly: It’s just sorcery?
kate: The Great Divide 😉
kate: The new gen of JS frameworks reduce the amount of JS shipped altogether, which is the real future of FE, imo
kelly: @kate you talk about this a bit in your post, but what are some of the new gen JS frameworks in your purview? and IYO, can they help bridge that gap between developer experience and user experience?
kate: Marko, 11ty, Fresh, Astro, and Qwik are all leading the charge in the effort to reduce the amount of JS being shipped through optimization techniques that improve performance. These include the use of compilers and what Qwik terms “smart preloading.”
monkchips: Taking a step back, as a front end person, @kate, say a bit more about your take on SPAs
kate: Well, as I argue in the post, React is top of mind when devs complain about SPAs (Voss and Bell make this point explicitly). Which leads me to say this of the future of SPAs:
If the future isn’t going to be built using React, then what will FE engineers use? All signs point to the next generation of HTML-first FE Frameworks, multi-page applications, and, frankly, being more selective when choosing a framework to fit the project.
kelly: And from what I can see from some of the reactions to your post, the Defense of React is a thing
monkchips: @kate So this is a good point. In 2023 is being anti-SPA just anti-React rubric?
React is super successful so it must be terrible, obviously.
kate: Yes, there is a lot at stake by threatening to displace React
It is one of the most popular, recognized, and established frameworks, and therefore has become a stand-in for SPAs writ large
kelly: So we are getting close to the end of our chat time: any last takeaways from the ongoing SPA conversation?
rachel: We never got to my initial question. This debate caught my attention because it really put user experience and developer experience as opposed forces. We can dive into specifics about frameworks and the merits of the arguments, but that’s where I was most curious to get the team’s takes.
monkchips: Which takes us back to Andy Bell’s post- Speed for Who – which argues that developer experience in JS frameworks is coming at the expense of user experience.
I’ve always found the focus on developer experience as a framework feature uncomfortable. The focus is all in the wrong place: spoiled developers vs people trying to use your website/app. I personally think developer experience is one of the least important aspects.
When I’ve mentioned that before, I often get a response like “yeh but because developer experience is better, we can do good work for users, faster”, but I’m yet to actually see that happening. Instead I see fad-chasing, like single page applications (SPAs), blockchain and now “AI” like Copilot and ChatGPT…
If a framework actually came along with a pure focus on user experience and thoroughly optimised output—something like a 99% reduction in output JavaScript vs current frameworks—I would be interested. As Dave pointed out in this article, that goes against the new framework trend.
So yes shitposting aside, we do seem to be at a bit of an impasse. DevX is obviously super important. but SPAs don’t always provide a great UX.
rachel: @sogrady I know you have a lot of conversations about the developer experience gap. does user experience ever come up in those conversations?
sogrady: Short answer is: not really. Devs are struggling so much that the user experience becomes something of an afterthought.
This is also an industry that tends to design software not only for the latest and greatest hardware, but with hardware capable of withstanding the typical temperature range of Cupertino.
Which is to say that low capability, low bandwidth use cases are not always given the highest priority, hence the tension mentioned above.
kate: @rachel & @sograd:y On the UX v DX note, I found this quote from sitepen is illuminating:
JavaScript ended up being so capable that we ended up creating entire applications with it, dynamically creating and destroying DOM interactively to users’ delight. Applications grew in complexity and so frameworks were created to tame that complexity, giving developers components, state management, routing, and so much more. The developer experience with frameworks proved popular enough that websites that didn’t need a framework for the end-user experience ended up being created with frameworks simply for the development and maintenance benefits provided by the framework. Unfortunately, the end-user experience is often degraded by delays, layout shifts, and unresponsive UIs. Frameworks have been feverishly working to undo these harms, but the solutions are complicated and often unsatisfying.
kelly: I think this UX vs DX debate is something we might take up again in the future. But for now we all have calls to get to. Thank y’all for your thoughts and your time today!
Disclosure: Vercel is currently a RedMonk client.
Image created by Kate Holterhoff with the assistance of DALL·E 2
No Comments