Your weekly reading (and more) from Web Directions
Before we get started, a couple of quick announcements. This week, we announced the full programme for two upcoming conferences: UX Australia (end of August in Melbourne) and Engineering AI (September 12th in Sydney). So if either of those sound valuable to you, take a look at the full lineup now, and both are in-person as well as online on our streaming platform, Conffab.
If it hasn’t been clear before, a pattern has been emerging with these weekly reading lists. There’s typically a bunch of articles around the more traditional Web Directions areas of focus—frontend development, design—and then articles about, broadly speaking, AI.
But if we look a bit more deeply at those AI-related articles, they fall into 3 subcategories:
- The changing nature of the practice of software engineering in the face of LLMs (our upcoming Engineering AI conference focuses on this)
- The challenges and opportunities of designing and developing products with AI/LLMs as an enabling technology, and ‘design material’ as Josh Clark puts it. Our conference Next focuses on this as do several of the talks at UX Australia.
- AI Engineering, in the sense that Shawn Wang originated the term.
What I hope is to stay as clear as possible from the vapid, hype-oriented, hand-wavey content when it comes to this topic. The ones that use terms like ‘game-changing’, and the word ‘imagine’ a lot. I call these the ‘future of whatever’ talks and articles. Our focus with everything we’ve done over the lifetime of Web Directions has been to always try to focus on the actionable and substantive (with a little inspiration thrown in).
That said I also feel—and this is a sentiment shared by many very long-time folks in the fields of software development and design I speak to—that this really is a period of transformation unlike any we’ve seen for decades, and at a pace that is genuinely unprecedented. I find it exciting and, more than a little, anxiety-inducing. If you feel anything like that I can assure you are not alone.
Want more like this in your inbox each Friday?
We deliver this straight to thousands of inboxes each Friday. So if you find this interesting, we’d love you to sign up.
Frontend Development
This week on the front end side we cover CSS, JS, DOM APIs, front end architecture, WebAssembly and more.
An Introduction to Scalable Vector Graphics (SVG)
Source: An Introduction to Scalable Vector Graphics (SVG) – HTML + CSS + JavaScript
An introduction to SVG, the first part of a promised series of videos from Rob Larson. Hot on the heels of Josh Comeau’s A Friendly Introduction to SVG, perhaps an excellent companion or alternative if video is more your thing?
CSS Hyphens, Words, Syllables, and Languages

There’s a newish CSS feature called hyphens that specifies how you want words to be hyphenated when the text wraps. But if you use it (and really you should), you’re going to need to make sure you’re also correctly identifying the language. And to understand why that matters, we need to talk about words and syllables.
Source: CSS Hyphens, Words, Syllables, and Languages – Frank M Taylor
HTML and CSS give us the ability to work with hyphenation—but to use them properly, we need to understand quite a bit about language, as Frank M Taylor explains here.
How to Discover a CSS Trick

Do we invent or discover CSS tricks? Michelangelo described his sculpting process as chiseling away superfluous material to reveal the sculpture hidden inside the marble, and Stephen King says his ideas are pre-existing things he locates and uncovers “like fossils in the ground.” Paragraph one is early for me to get pretentious enough to liken myself to those iconic creative forces, but my work on CSS-Tricks feels like “discovering,” not “inventing,” secret synergies between CSS features, which have been eyeing each other from disparate sections of the MDN web docs and patiently waiting for someone to let them dance together in front of the world.
Source: How to Discover a CSS Trick | CSS-Tricks
Douglas Crockford, of JSON fame, says he didn’t invent JSON, he discovered it. Over the years many unintended uses of CSS have been uncovered—like the decades-long approach of using float to create page layouts. This great article by Lee Meyer explores how to think about CSS to discover novel uses and capabilities hidden perhaps even in 20-year-old features.
It’s time for modern CSS to kill the SPA
SPA speculation rules View Transitions

At some point during the scoping process, someone says the words. A CMO. A digital lead. A brand manager. And with that single phrase, the architecture is locked in: it’ll be an SPA. Probably React. Maybe Vue. Almost certainly deployed on Vercel or Netlify, bundled with a headless CMS and a GraphQL API for good measure. But the decision wasn’t really about architecture. It wasn’t even about performance, scalability, or content management. It was about interactions. About how the site would feel when you click around. The assumption was simple: Seamless navigation requires us to build an app. That assumption is now obsolete.
Source: It’s time for modern CSS to kill the SPA – Jono Alderson
Jono Alderson says the quiet part out loud. The SPA architecture has had a good run, but perhaps its day is behind it.
The many, many, many JavaScript runtimes of the last decade
edge computing history JavaScript

This last decade has seen an inundation of new JavaScript runtimes (and engines in equal measure), enabling us to run JavaScript in all manner of contexts with precise fitness for task. Through these, we’ve seen the language spread to the Cloud, the edge, Smart TVs, mobile devices, and even microcontrollers.
In this article, we’ll explore what’s driving this diversity, and why no one runtime or engine suffices for all purposes.
Source: The many, many, many JavaScript runtimes of the last decade • Buttondown
A fascinating and detailed history of JavaScript runtimes over the 30 years of its existence. Just about anyone would be surprised at just how widely adopted JavaScript has been and how many runtimes there have been and still are for it.
When Is WebAssembly Going to Get DOM Support?
DOM JavaScript WASM web assembly
Is WebAssembly (Wasm) really ready for production usage in web applications, even though that usage requires integration with a web page and the APIs used to manipulate it, such as the DOM?
Simultaneously, the answer to this question is that “Wasm might never get direct DOM access,” and “Yes, Wasm is ready for all kinds of web-integrated uses, having supported calling out to the DOM (with a little indirection) since day zero.” Let me explain.
Source: When Is WebAssembly Going to Get DOM Support? – ACM Queue
WebAssembly is a decade old now, but there’s no direct access to DOM APIs for WASM code. So is it really ready for production use in web apps? Daniel Ehrenberg explains why it is, and how in this detailed article.
Web Serial: The Only Reason I’ll Admit JavaScript Isn’t All Bad
Device APIs JavaScript WebSerial

However, I must give credit to where credit is due: I really like what Web-serial has turned out to be. I had strong opinions about sandboxing javascript to stay in the browser and not reaching out to interact with the system that the browser runs on. However, after seeing how web serial enables users to easily upload firmware to USB devices, I become pretty excited. Web-serial is an extension, mostly supported on Chrome, that came from standards body to help build up support for talking to serial devices.
Source: Web Serial: The Only Reason I’ll Admit JavaScript Isn’t All Bad
The Web has many powerful device-level APIs. Most folks will know about the Geolocation API, but there’s Web Bluetooth, Web NFC, and others including Web Serial. These are standards, but Apple and Mozilla remain opposed to supporting them and so remain Chrome only for now (and because Webkit is the only browser engine available on iOS devices, these aren’t available in any way on iPhones). Here’s a bit more about it from Steven Hicks (we also have a great talk on Web Bluetooth on Conffab).
More Fun with Invoker Commands and Web Components
So I thought it would be fun to revisit the Invoker Commands API (MDN) which is available in Chromium-based browsers and hopefully coming soon to Safari and Firefox (both are currently in testing). I’ve talked about this API before on the blog, and I continue to feel pretty excited about it since it’s the first truly declarative “click and see something happen!!” API we’ve ever seen on the web other than forms. I mean, think about it for a moment…isn’t it quite odd that there’s never been a way to write HTML (not JavaScript!) which says “when you click this button, do that thing”?!
Source: More Fun with Invoker Commands and Web Components | That HTML Blog
More on invokers, as they inch toward widespread support.
AI & Development Tools
Why “Context Engineering” Matters
AI AI Engineering LLMs software engineering
When the term “context engineering” arrived, after Karpathy knighted it, there was a fair amount of push back. “Another marketing term,” some people said. One HN commenter called it, “A month long skill, after which it won’t be a thing anymore.”
I don’t think this is the case. In this presentation I’ll argue not only is “context engineering” here to stay, but the terms arrival will accelerate the development of the field, culture, and community.
Source: Why “Context Engineering” Matters | Drew Breunig
Two or so years ago prompt engineering was the thing, a term that’s largely faded into obscurity. Earlier this year Andrej Karpathy’s neologism ‘vibe coding’ exploded into use (and now we have “vibe” everything), but it’s a term that’s become almost meaningless in its imprecision (Karpathy meant something quite specific when he coined it, but the street finds its own uses for things I guess). Hot on their heels is context engineering. Another meaningless marketing term? Or a concept of more lasting value? Drew Breunig argues the latter in this presentation.
Enough AI copilots! We need AI HUDs

In my opinion, one of the best critiques of modern AI design comes from a 1992 talk by the researcher Mark Weiser where he ranted against “copilot” as a metaphor for AI. This was 33 years ago, but it’s still incredibly relevant for anyone designing with AI.
Source: Enough AI copilots! We need AI HUDs
I’m sure I’m not alone at being surprised about the metaphor of AI as a co-pilot being decades old. Or that criticisms of this metaphor are as old as that. Here Geoffrey Litt picks up the thread and explores AI as heads-up displays (HUD) as a better metaphor for designing with AI.
AI Is Just the Latest Frontend Killer. Don’t Panic.

AI coding assistants are great at scaffolding UIs, rewriting code, even generating decent boilerplate for common components. But they don’t know why one pattern is better than another. They don’t care about CLS or INP or how something feels when a user taps it on a laggy phone. They don’t push back when 300kB of JavaScript bloats the homepage.
Frontend engineering isn’t just building. It’s choosing. Tuning. Diagnosing. Holding the line when product wants “just a quick popup” and you know it’ll tank performance.
Source: AI Is Just the Latest Frontend Killer. Don’t Panic. — Den Odell
Authoritative coding LinkedIn posts to the contrary, no one knows how LLMs will impact software development. But it is a topic worth considering (so much so we have an upcoming conference on the topic). Here Den Odell explores the potential impact of LLMs on frontend development.
A RedMonk Conversation: How Shawn (swyx) Wang Defines the AI Engineer
In this RedMonk conversation, Shawn (swyx) Wang discusses the evolving role of the AI Engineer with Kate Holterhoff. They chat about the definition of an AI Engineer, the differences between AI Engineers and traditional software developers, vibe coding, frontend observability, and the AI Engineer World’s Fair.
Source: A RedMonk Conversation: How Shawn (swyx) Wang Defines the AI Engineer – RedMonk
Shawn Wang is the originator of the term “AI Engineer” in his now ancient (OK barely 2-year-old) article, The Rise of the AI Engineer, that I recommend everyone read. I also really recommend this interview (video, audio and transcript versions for however you might like to consume such things). Fun fact, Shawn before his ascent to super stardom helped program our Global Scope JavaScript conference in 2022 and spoke at Global Scope in 2021.
elements | AI Focus

As much as struggle with on-device processing and the quality of its output compared to server models, I am excited by some of the APIs that are being built into browsers that are backed by LLMs and other AI inference models.
For example, the prompt API, along with a multi-modal version that can take any arbitrary combination of text, image, and audio and run prompts against them. These APIs are neat but not yet web-exposed and many developers struggle to know what to do with a generic prompt. It’s not a solution that is natural to many people yet.
Source: elements | AI Focus
We’ve covered on-device AI inference already quite a bit at our events, and share Paul Kinlan’s sense that this is going to be an increasingly important technology for developers to take advantage of (and which helps address several of the most significant concerns people have about LLMs, including energy use, and privacy.) Paul shares some examples of the kind of use this might be put to, and inspiration for you to explore more.
Teaching MCP Servers New Tricks: Challenges in Tool Discovery

You’ve probably noticed a pattern when you try new LLM-backed or adjacent tools, especially in the developer space. Once you get oriented, the first few interactions are delightful. You start to gain an instinct for what the tool can do. Then you begin to explore the boundaries, either out of curiosity or necessity, and you find them faster than you’d like. Suddenly, the delight wears off, and the boundaries feel a bit constraining.
I felt this way writing an MCP server for a CLI tool I recently built. Having used a few and gone through Anthropic’s quickstart tutorial, I still wasn’t 100% sure what to expect. I found the process equal parts magical and frustrating. I want to share a few things I learned along the way that might help anyone approaching MCPs for the first time.
Source: Teaching MCP Servers New Tricks: Challenges in Tool Discovery – AI Native Dev
Whether you’re still contemplating your first MCP server, or have been exploring the possibilities already, Macey Baker’s piece will provide food for thought about the value they can deliver and how to achieve it.
Accessibility
Designing for User Font-size and Zoom

When I tried setting my browser font-size preferences, I found it broke more sites than it improved, and I quickly moved back to the default. So what went wrong, and how can we fix it?
Source: Designing for User Font-size and Zoom | OddBird
Browsers are also known as ‘user agents’ (hence ‘UA strings’—the UA stands for ‘user agent’). In the W3C’s ‘priority of constituencies‘, users’ needs come before those of any others, like web and browser developers. Many users with vision impairment (which includes most people as we age) rely on this principle to interact with websites, setting their own preference for font sizes, and even fonts, in some cases creating their own user style sheets. But how does that work in practice? Not so well it turns out. Here Miriam Suzanne explores why and what we can do about it.
Why I don’t trust WCAG 2.2 and what I’m hoping from 3.0
a11y accessibility wcag WCAG 2.2

In this day and age, we must also consider the negative impact that a brand incurs when it fails to be accessible, which inevitably comes with its own losses. Still, WCAG 2.2 (released in 2023) deserves some blame here. It leaves too many gaps. That brings us to the point of this blog. What’s wrong with WCAG 2.2 — and how will WCAG 3.0 improve things?
Source: Why I don’t trust WCAG 2.2 and what I’m hoping from 3.0 – LogRocket Blog
Daniel Schwarz has thoughts on the shortcomings of WCAG 2.2 and what will hopefully be addressed with the upcoming 3.0.
WCAG in Plain English
Making accessibility standards easy to understand, one success criterion at a time. Friendly reminder: This is a beginner-friendly guide, not a replacement for the official WCAG. See our full disclaimer.
Source: WCAG in Plain English – AAArdvark
An approachable, searchable well-structured plain language guide to WCAG.
Great reading, every weekend.
We round up the best writing about the web and send it your way each Friday.