Your weekly reading from Web Directions
Another big week at Web Directions this week.
First up, we streamed Performance Now Live from Amsterdam. If you’d like to catch up with the videos, you can do that on Conffab for a very reasonable price. Why not consider a Conffab Premium account? You can get access to all of our conferences live, including Performance Now and CSS Day, conferences like Clarity and a whole bunch more that we have planned for the platform in the coming year.
We built you a time machine, or at least the next best thing
We’re just under three weeks away from our developer summit and next conferences for this year. A year from now, both what we build and how we build it—as developers, designers, and product professionals—will have profoundly shifted. (In reality, it already has.)
AI and large language models aren’t just transforming what we will build, but the long-standing processes by which we do so.
Imagine having a time machine to skip forward to the end of 2026 and get a sense of what that landscape will look like.
We can’t give you that. But we can give you the next best thing.
We’ve spent the best part of the year bringing together speakers who will show you what’s coming and how to get there, based on what’s happening today.
- Next is for Product designers, product professionals an everyone delivering digital products.
- Developer Summit is for front and end full stack teams.
That’s it. That’s all I’ve got to say.
You can attend online or in person. I guarantee you won’t regret it.
Are you a carpenter or a surgeon?
This week, inspired by one of the articles you’ll find below, I asked the question, “Are you a carpenter or a surgeon?”.
TL;DR: We’ve been using the wrong metaphor for AI in development. It’s not just a power tool that makes us more productive—that’s a sustaining innovation mindset. The better analogy is the surgeon: someone with deep foundational knowledge, embodied expertise from thousands of cases, and the judgment to make critical decisions. As AI handles more of the execution, what matters isn’t typing speed but knowing which data structures to use, understanding how systems connect, and maintaining mastery of constantly evolving platforms. Your expertise isn’t obsolete—it’s more essential than ever.
Now on with this week’s reading!
AI & Development Tools
Will AI Agents Kill the Web as We Know It?
AI autonomous agents Design LLMs
The way we interact with the web today is surprisingly manual. Want to book a flight? You’ll probably head to a familiar airline’s website or open Google and type in your dates. If that site also offers hotel and car rental options, great—you might stay and book everything in one place. But more likely, you’re picky. So you go off searching for that perfect boutique hotel or the restaurant you’ve read about. Click by click, tab by tab, you stitch your trip together.
Source: Will AI Agents Kill the Web as We Know It? | Andy Budd
For better and for worse, the web is not simply for humans anymore. The reality is, bots have long been the most important visitors for most websites—in particular, Google’s bot, which indexes your site and has been for decades the most important source of traffic for most successful websites. And then many sites have APIs, which are interfaces for machines or code rather than for humans. Even if most of the time that interaction is mediated through the API, ultimately it was driven by a human.
If the promise of agentic AI is real, then while a human might ask an agent to complete a task for them, and that task might involve interacting with your website, the actual interaction won’t be with a human—even if it is in service of them. There are many who are aghast at this idea. But it is increasingly a reality. So it is something you should be paying attention to if you develop websites.
Here, Andy Budd reflects on the implications, and it’s something we cover at our upcoming Developer Summit and Next conferences from both a developer and more of a product design and product management perspective. And if it’s interesting to you, I highly recommend you check out the upcoming book by Katja Forbes, who is speaking at both those conferences.
Performance Debugging With The Chrome DevTools MCP Server
AI MCP performance software engineering
A few weeks ago, Google launched the Chrome DevTools MCP server. It allows you to integrate AI models with a Chrome browser instance.
In this article we’ll explore what the MCP server can do and how you can use it for performance debugging.
Source: Performance Debugging With The Chrome DevTools MCP Server | DebugBear
If you’ve been thinking about how MCP servers can help you in your work as a front-end engineer—or even if you haven’t—take a look at this article from DebugBear, which explores how you can use the built-in Chrome debugging tools via an MCP server.
Measured AI
AI AI Native Dev LLMs software engineering
As a former full-time engineer, I really enjoy coding with AI tools and the tradeoffs are worthwhile for me. AI assistance shortens my time from idea to working code, and using it has strengthened my ability to express what I want the code to do and how. But I view AI-generated code as a first draft that has much room for improvement, so I delete or refactor a good deal of it. I don’t “vibe-code” so much these days, as I prefer to fully understand what I’m building.
Source: Measured AI | Note to Self
We continue to collect these first-hand accounts of how established and experienced engineers are working with large language models. We certainly don’t have a standardised approach to this, and perhaps we won’t ever do so. But I think it’s really valuable to see how the lessons that very experienced software engineers are learning and sharing.
Code like a surgeon
AI AI Native Dev LLMs software engineering
A lot of people say AI will make us all “managers” or “editors”…but I think this is a dangerously incomplete view! Personally, I’m trying to code like a surgeon. A surgeon isn’t a manager, they do the actual work! But their skills and time are highly leveraged with a support team that handles prep, secondary tasks, admin. The surgeon focuses on the important stuff they are uniquely good at.
Source: Code like a surgeon
We collect quite a few reflections like these from software engineers about how they work with large language models and how they think about that work. I think this analogy of a surgeon is actually very interesting and possibly quite helpful. Surgery is increasingly automated and supported. A surgeon is surrounded by experts with anaesthetics, surgical nursing teams, very often using robotic arms and devices and using magnifying technology rather than their unaided eye. And yet it’s ultimately the knowledge and specific skill of the surgeon that leads to successful outcomes.
Glimpses of the Future: Speed & Swarms
AI Native Dev LLMs software engineering
Last month, I embarked on an AI-assisted code safari. I tried different applications (Claude Code, Codex, Cursor, Cline, Amp, etc.) and different models (Opus, GPT-5, Qwen Coder, Kimi K2, etc.), trying to get a better lay of the land. I find it useful to take these macro views occasionally, time-boxing them explicitly, to build a mental model of the domain and to prevent me from getting rabbit-holed by tool selection during project work.
The takeaway from this safari was that we are undervaluing speed. We talk constantly about model accuracy, their ability to reliably solve significant PRs, and their ability to solve bugs or dig themselves out of holes. Coupled with this conversation is the related discussion about what we do while an agent churns on a task. We sip coffee, catch up on our favorite shows, or make breakfast for our family all while the agent chugs away. Others spin up more agents and attack multiple tasks at once, across a grid of terminal windows. Still others go full async, handing off Github issues to OpenAI’s Codex, which works in the cloud by itself… often for hours.
Source: Glimpses of the Future: Speed & Swarms
Along with Simon Willison, Geoff Huntley, and a handful of other folks, I find Drew Breunig’s insights and shared experience of working with large language models as a software engineer very valuable. Here, Drew reports back on a month of intensive use of multiple models and applications.
The takeaway from this safari was that we are undervaluing speed
Drew examines the swarm pattern for working, particularly with slower models, and predicts what the future of working with large language models as a software engineer might look like.
CSS & Frontend Development
Inlining Critical CSS: Does It Make Your Website Faster?
Inlining critical CSS can make your website super fast. But it’s not always easy to implement, and there are some downsides.
In this article we take a look at how you can optimize stylesheets on your website, and take a look at some common challenges.
Source: Inlining Critical CSS: Does It Make Your Website Faster? | DebugBear
We’ve long been advised that inlining critical CSS is a performance-enhancing technique. But there are definitely some gotchas there. So the folks from DebugBear give us more detail on what to do and what not to do.
Start implementing view transitions on your websites today
CSS CSS Animation View Transitions
The View Transition API allows us to animate between two states with relative ease. I say relative ease, but view transitions can get quite complicated fast. A view transition can be called in two ways; if you add a tiny bit of CSS, a view transition is initiated on every page change, or you can initiate it manually with JavaScript.
Source: Start implementing view transitions on your websites today – Piccalilli
Yes, more on View Transitions. The API we should have had about a decade ago, when it might have saved us from a lot of rabbit holes and dead ends. Here you can get up and running with View Transitions with Cyd Stumpel, who gave a fantastic talk at CSS Day on the possibilities of View Transitions that I highly recommend (it’s right here on Conffab).
Start using Scroll-driven animations today!
animation CSS CSS Animation scroll-driven animation
To celebrate scroll-driven animations finally landing in Safari 26, here are some things you probably want to know before using them.
Source: Start using Scroll-driven animations today! | Blog Cyd Stumpel
Scroll-driven animations are something that we’ve long needed JavaScript to implement, but that’s now changing with native support for scroll-driven animation in browsers here or coming soon. Learn more from the mega-talented Cyd Stumpel.
Solved By Modern CSS: Section Layout
The following design might be simple to create in a tool like Figma, but getting them to work fluidly in the browser is a different story. It’s not complicated, but there are a few things that we need to consider.
Source: Solved By Modern CSS: Section Layout
Another great worked example by Ahmad Shadeed. Ahmad has a series of these where he shows step-by-step how he solves problems with modern CSS.
JavaScript & Web Architecture
React and Remix Choose Different Futures
AI Native Dev architecture react remix
I attended Remix Jam two weeks ago, then spent this past week watching React Conf 2025 videos. I have spent the last decade shipping production code on React and the last two years on Remix. Now both ecosystems are shifting, and what seemed like different approaches has become incompatible visions.
React Conf’s technical announcements were incremental: React 19.2 APIs, View Transitions experiments, the compiler getting more sophisticated. The message was clear: React is listening to the community while accepting complexity on your behalf. Stability, Composability, Capability: those are the values. The Remix team announced something else entirely: they’re breaking with React. The mental model shifts introduced by use client and the implementation complexity of Server Components forced a choice. And Remix 3 chose Simplicity. Remix 2 users pay the price; there’s no upgrade path.
That choice, to sacrifice Stability for Simplicity, makes explicit what was already true: these values cannot coexist.
Source: React and Remix Choose Different Futures
A really interesting reflection on where React and Remix are headed as they diverge, and how the values embedded in each are quite distinct. I feel we’re at a time of real disruption when it comes to how we architect for the web—something I’ve been saying for the last year or so. React and Remix are diverging around this, but we also need to consider the impact of large language models on how we architect for the web.
If, as I think is likely, we increasingly rely on LLMs to do a lot of the heavy lifting when it comes to writing code, the key question becomes: what kind of code works best with those models? Some people argue that React does, because there’s so much training data—so much React code on the web that models will have learned from.
But as one interviewee on the AI-Native Dev podcast a little while ago observed, a lot of that is just pretty average React code. And how much is enough? We don’t actually know.
When I work with LLMs on web technologies and ask them to generate web content and applications with functionality using “vanilla” JavaScript, CSS, and HTML, they do a very good job. They’re very steerable. I think they know enough to do that very well. The web platform fundamentals are meticulously documented, and that documentation is typically very high quality, which helps.
It’s a complicated and challenging time. Pieces like this are valuable in helping us think through and reason about where we go from here.
Write Code That Runs in the Browser, or Write Code the Browser Runs
architecture front end JavaScript performance
I’ve been thinking about a note from Alex Russell where he says: any time you’re running JS on the main thread, you’re at risk of being left behind by progress. The zen of web development is to spend a little time in your own code, and instead to glue the big C++/Rust subsystems together, then get out of the bloody way.
In his thread on Bluesky, Alex continues: How do we do this? Using the declarative systems that connect to those big piles of C++/Rust: CSS for the compositor (including scrolling & animations), HTML parser to build DOM, and for various media, dishing off to the high-level systems in ways that don’t call back into your JS. I keep thinking about this difference: I need to write code that does X. I need to write code that calls a browser API to do X.
There’s a big difference between A) making suggestions for the browser, and B) being its micromanager. Hence the title: you can write code that will run in the browser, or you can write code that calls the browser to run.
Source: Write Code That Runs in the Browser, or Write Code the Browser Runs – Jim Nielsen’s Blog
Back in 2009, I ran a competition at a conference called “No-Bit Sherlock.” The premise was simple: as SVG was gaining browser support, we should minimize—or ideally eliminate—our reliance on bitmap images on the web. By “bits,” I mean raster graphics. At the time, web pages were littered with images of text, typically saved as JPEGs or PNGs. Illustrations that could have been rendered as vectors were routinely served as bitmaps instead.
While SVG adoption has increased dramatically since then, the unnecessary use of bitmap images remains surprisingly common. It’s become an instinct—a default we reach for without questioning. So what does this have to do with the article I’m discussing? It’s about instinct too.
This piece captures a crucial distinction between two approaches to web development: one mindset is “write code that does X.” The other is “write code that calls a browser API to do X.” Is this a difference without a distinction? Absolutely not. These represent fundamentally different philosophies about what we do as front-end engineers.
Our instinct should be to understand the browser’s capabilities first, then write the minimal code necessary to leverage them. Animation illustrates this perfectly. Fifteen to twenty years ago, web animation barely existed beyond hover states. Any movement, change in appearance or transformation required JavaScript manipulating DOM properties directly. With JavaScript as our only tool, we blocked the main thread with every animation.
Fast-forward to today. Browsers offer rich built-in animation capabilities we can trigger with JavaScript or even CSS alone, keeping the main thread clear and performance smooth. View transitions represent the latest iteration—essentially the holy grail. We can now animate page transitions without implementing the animation ourselves. We simply declare what we want, and the browser handles it.
The result? High performance, better developer experience, and progressive enhancement. In Firefox (where multi-page view transitions aren’t yet implemented as of October 2025), users simply get traditional page transitions—no breakage, no compromise.
The pattern repeats across features: form validation, layout systems, accessibility features. There’s extensive built-in functionality we can enhance with JavaScript when needed, rather than replacing entirely.
Our job as professional front-end developers is to know the platform’s capabilities and use them fully. The browser will always be orders of magnitude more performant than our custom implementations. But this requires stepping outside the comfort zone of your preferred framework or library to understand the web platform itself—the foundation everything else is built on.
Web Platform & Browser News
V7: Video Killed the Web Browser Star
So I thought I knew as much as I needed to know about the HTML element, and as usual, I was wrong
Source: V7: Video Killed the Web Browser Star | Rob Weychert
Why don’t you know that you don’t know about the video element in HTML? Rob Weychert thought he knew the element well. Turns out there was still more to know, and he shares that here.
The present and potential future of progressive image rendering
image compression image optimisation performance
Progressive image formats allow the decoder to create a partial rendering when only part of the image resource is available. Sometimes it’s part of the image, and sometimes it’s a low quality/resolution version of the image. I’ve been digging into it recently, and I think there are some common misconceptions, and I’d like to see a more pragmatic solution from AVIF. Let’s dive straight into the kinds of progressive rendering that are currently available natively in browsers.
Source: The present and potential future of progressive image rendering – JakeArchibald.com
Back at the dawn of the web, in the mid-90s, if you think performance is an issue now, then ah well, I’ve got a history lesson for you. In an era when hundreds of megabits, even gigabits per second, of download speed are far from rare, imagine 5 kilobits per second. Imagine a time when 10 kilobits per second was a fast shared download at an educational institution.
And imagine the kinds of techniques you’d need to come up with to manage performance, particularly of images, which could take many seconds or longer to download. In that era, the progressive JPEG, which rendered a very low-resolution version of the image relatively quickly and then filled in the details over time, was a godsend. Progressive image formats are not just a thing of the past. Here, Jake Archibald looks at the current state and future direction of these image formats.
Web Components & Modern Development
Lots to shout about in Quiet UI
As President of Web Components, it’s my duty to publicly comment on every Web Component library and framework that exists. Today I’m taking a look at Quiet UI, a new source-available web component library soft-launched by Cory LaViska, the creator of Shoelace WebAwesome. You might be asking “another UI library? But why?” and that’s a good question, I’ll let Cory tell you in his own words…
Source: Lots to shout about in Quiet UI – daverupert.com
When Quiet UI came out a few weeks ago, we gave it a mention here. Looks like an amazing and really valuable library of web components without any dependencies. Here, Dave Rupert looks at what it has to offer in more detail. Highly recommend you check it out.
Design Systems
3 practical ways LLMs can support design systems teams today
When AI and LLMs started creeping into the design systems discourse, the loudest use cases were about generating components and docs. But the truth is that for many teams, those aren’t actually the hardest problems to solve. At the end of 2024 and start of 2025, the attitude across the design systems community was flat-out negative toward AI. The DS space seemed deeply skeptical of claims that AI could do anything useful for us. At the time, the only examples I ever heard were: It can write components, and it can generate documentation. It can: But I don’t think either of those is actually a good use case for LLMs in design systems.
Source: 3 practical ways LLMs can support design systems teams today – zeroheight
How can large language models help teams work with design systems? Given there certainly seems to be a lot of benefit for software engineers in working with large language models, what carries over to design systems—a practice certainly adjacent to and overlapping with engineering—and what doesn’t work? Here, Elyse Holladay looks at where large language models might not do the job and where they may be valuable.
Big Ideas
Founders Over Funders. Inventors Over Investors.
I’ve been following tech news for decades, and one of the worst trends in the broader cultural conversation about technology — one that’s markedly accelerated over the last decade — is the shift from talking about people who create tech to focusing on those who merely finance it.
Source: Founders Over Funders. Inventors Over Investors. – Anil Dash
I have essentially nothing to add to this. This is very strongly my feeling as well. And I guess my hope—and I know a lot of people are rather skeptical about AI—but my hope is that AI makes those people who make stuff and do stuff, who build things, more productive, and less needful of financing, and ultimately gives rise to a new and extraordinary kind of flourishing.
Because right now we are optimizing for the kind of people who can seek funding, the kind of products and businesses where funding makes sense from the VC perspective, not from the product perspective—and where’s that led us over the last fifteen or twenty years? I think a very moribund, boring place, far less interesting than the web of let’s say 20 years ago. So go and read this, and if you’re the kind of person who likes to build things, think about what you can build in this new era of large language models.
Great reading, every weekend.
We round up the best writing about the web and send it your way each Friday.
