Web Directions Year round learning for product, design and engineering professionals

“How did you go bankrupt?” Bill asked. 
“Two ways,” Mike said. “Gradually, then suddenly.”

Ernest Hemingway, The Sun Also Rises

Ezra Klein, the early blogger turned New York Times pundit and podcaster recently described the time we are living in now as ‘exponential time‘. He’s particularly referring to the experience in particular of the early weeks and months of Covid, and to the sudden explosion into popular consciousness of AI and Machine Learning–but don’t panic, that’s not what I’m here to talk about today!

I’ve been working on bringing together my thoughts around a much more niche topic, but one of relevant to many of our conference attendees. An area that has been evolving gradually, but we seem to be hitting the ‘then suddenly’ stage. 

But rather than continue to try and fail to distil these ideas into a clear coherent piece, today I’ll just share a number of related things I’ve read recently, that anyone working in front end dev, with an interest in how we architect our apps should find valuable.

Some of these pieces are quite opinionated, and don’t beat around the bush. But none I believe are in bad faith or delivered with malice. 
In short I do feel we’re on the cusp of a significant change in how we architect web applications, with the decade–long dominant paradigm of the Single Page App looking shaky–as Guillermo Rauch put it recently ‘SPAs were a zero interest rate phenomenon‘.  

The Market for Lemons
Alex Russell has earned the right to express his opinions about the state of the web and its technologies as mch as anyone. From his groundbreaking early work on Dojo (ask your grandparents) to work on Chrome and Edge, at the W3C on the TAG and various working groups and on TC39 (the folks who standardise JavaScript) he has helped move the web formard like few others.

His blog, Infrequently Noted carries many detailed, densely reasoned pieces on the, what Alex would call less than ideal state of the Web and how we build for it.

His recent The Market for Lemons starts

For most of the past decade, I have spent a considerable fraction of my professional life consulting with teams building on the web.
It is not going well.
Not only are new services being built to a self-defeatingly low UX and performance standard, existing experiences are pervasively re-developed on unspeakably slow, JS-taxed stacks. At a business level, this is a disaster, raising the question: “why are new teams buying into stacks that have failed so often before?”
In other words, “why is this market so inefficient?”

The Market for Lemons

Laurie Voss, one of the founders of NPM, another past speaker at our conferences, and another person whose work moving the Web forward we greatly admire responded to Alex’s piece

Today I read Alex Russell’s post The Market for Lemons and I found myself compelled to write a rebuttal. I am a big fan of Alex’s work in general but not of this post in particular.

The Case for Frameworks

Others have joined the fray. It may reflect the nature of the folks I follow (who probably skew toward more old school Web development, people who are often skeptical of the framework/library heavy approach of recent years, but I try very hard to break out of that echo chamber) but the majority of pieces I’ve read definitely align more with Alex’s point of view than Laurie’s.  

In The Great Gaslighting of the JavaScript Era Jared White pulls no punches, summarising the debate between Laurie and Alex, writing

The age of frontend JavaScript frameworks eating the web world didn’t happen simply because some well-meaning developers found great DX. It happened because we were fed a line.

The Great Gaslighting of the JavaScript Era

Simon MacDonald chimed in, asking Why does everyone “suddenly” hate Single Page Apps? He too summarises some of these recent articles, and asks ‘How did SPAs become popular?’–providing something of a history of how and why we got here, as well as asking ‘So should I still build SPAs?’–you’ll have to read to find his answer.

Cole Peters, also, like Simon from Begin, uses this controversy to focus on one of the key reasons for the rise of frameworks and the SPS–Developer Experience (or DX).

If I may risk verging on the idealistic, I would suggest that developer experience needs to pivot from a concept centered on feeling fast and living on the bleeding edge to one based on the enabling of developers to deliver reliable and first rate end user experiences — for as many users as possible, and for as long as possible. This doesn’t mean developers shouldn’t have great tools with which to carry out the crafting of great UX — but it does shift the narrative from one of ‘trickle down UX’ to something more honest, where the fruit of our labors is prioritized a little more above our labors themselves.

Addressing the obverse of this coin, Andy Bell asks ‘Speed for who?‘

Frameworks are often touted as something like “a lightning fast development experience” and that’s fine I guess, but the speed is in the wrong hands. Why not “a lightning fast experience for your users”?
…
I guess what I’m winding up to say here is developer experience really isn’t important—especially when frameworks haven’t even got the absolute baseline experience anywhere near where it needs to be to service a world wide web. A world wide web that’s accessed with slow, expensive connections and cheap, underperforming hardware. How about taking a bit of “DX” on the chin to focus instead on “why are we using this framework that potentially excludes the majority of users?”

Speed for who?

And then focussing on a different though equally important facet of the Web, Manuel Matuzović considers the impact, positive and otherwise of JavaScript and SPA on accessibility

Sometimes it seems like accessibility experts and other web professionals hate JavaScript. This might be true for some, but most understand that JavaScript can be useful for improving UX and even accessibility. JavaScript solutions are often more accessible than their pure HTML or CSS counterparts.

Why I’m not the biggest fan of Single Page Applications

Local Maxima

To finish up, I want to focus on a new  browser API, View Transitions, that just arrived in Chrome 111.

The View Transition API lets you update the DOM in a single step, while generating an animated transition between the two states.

SPA view transitions land in Chrome 111

One of the principal reasons for the SPA Architecture is to create more ‘app like’ experiences. View Transitions promise to bring such experiences to traditional multi page architecture sites, while making all such transitions more dynamic and engaging.

My instinct is SPAs were a local maximum, which helped the web face the challenge of the explosion of native mobile apps, and the sense the Web in such an age could become an irrelvancy–it’s 13 years now since Wired published ‘the web is dead‘.

Reports of the Web’s death appear to have been greatly exaggerated. With Project Fugu, innovations like View Transitions, and recent signals from regulators around the world they may well require Apple to allow other browsers to ship with their own bowser engines, I feel we are on the cusp not simply of a change in the architecture of Web apps, but a new age of innovation in web experiences. 

But change is challenging–as my old friend the Tao Te Ching puts it 

38. Ritual
Well established hierarchies are not easily uprooted;
Closely held beliefs are not easily released;
So ritual enthralls generation after generation.

Tao Te Ching

Think these issues are important? It’s precisely the sort of thing we consider at Web Directions Code​.