Your weekly reading: The Punctuated Equilibrium of Web Development
The naive understanding of evolution is that species are continually evolving. This idea held sway for the first century or more after Darwin first published his theory of evolution. But the orthodox view of evolution today is of punctuated equilibrium—the idea that for most of their existence, species remain remarkably stable, punctuated by periods of rapid change.
If we apply this as an analogy to web development, we see a similar pattern of long, relatively stable periods followed by sudden shifts.
The Three Epochs of Web Development
The first decade or so of the web was characterized by presentational HTML. With the arrival of modern browser engines like Internet Explorer 5 for the Macintosh, CSS-based development came to replace the grab bag of techniques we developed to enable presentational HTML to do much more than it was designed for. During this period, like mammals in the fossil record, JavaScript first started to make significant inroads into front-end development—something accelerated by the arrival of jQuery.
For the last fifteen years or so, we’ve been living in perhaps the third epoch of web development, characterized in no small part by our dependence on frameworks and libraries.
How Transitions Really Happen
Looking back at these earlier transitions, would they have been obvious at the time? Since I lived through all of them, while I may not be entirely reliable, I am at least a witness to how they unfolded.
These weren’t sudden transitions where overnight all practices were abandoned and new ones became best practice. Instead, developers who had learned a certain approach and developed capabilities around it adhered to those methods long after new approaches started taking hold, Or indeed had become evidently better suited. It was largely a new set of people who became champions of each new approach, while existing experts held out. A Verse from the Tao Te Ching which I’ve quoted before elsewhere comes to mind.
Well established hierarchies are not easily uprooted;
Closely held beliefs are not easily released;
So ritual enthralls generation after generation.
AS does this line from Hemingway’s “The Sun Also Rises” where one character asks another:
“How did you go bankrupt?”
“Two ways. Gradually, then suddenly.”
That’s how these transitions seem to occur. They can bubble away in the background for years, but then suddenly, with what feels like a single stroke, they become the state of the art.
Slowly
For the last fifteen years, in this third epoch of web development, we’ve relied increasingly on frameworks and an associated ecosystem of tools and processes. A developer from 2010, awoken after cryogenesis, would be baffled by the complexity of the systems we’ve built to deliver what is, If you squint, very similar to what we were delivering back then.
That complexity didn’t happen overnight. It came gradually, incrementally. At each step, it may not have seemed that what we were doing had become dramatically more convoluted. And yet here we are, fifteen years later, with a development landscape almost entirely unrecognizable from 2010.
Then suddenly
When you read as many posts and articles, listen to as many podcasts, and try to keep up as much as I do, you perhaps notice things that aren’t entirely obvious in isolation. Things that may seem relatively trivial or not overly significant on their own, but when pieced together, something else emerges.
At Web Directions, we’ve covered several emerging technologies at our conferences and in our newsletter over the last couple of years. We’ve flagged the potential importance of speculation rules—how browsers can speculatively prefetch and preload web content to make visiting new pages essentially instantaneous. We’ve highlighted the increasing sophistication of offline web technologies and local-first architecture. We’ve focused on view transitions and how they could usher in a whole new approach for developing the front-end. And we’ve focused extensively on generative AI, particularly its impact on software development practices.
Punctuation
What do these seemingly disparate elements have to do with punctuated equilibrium? In 2010, the web platform’s capabilities were far less powerful than today. We often needed JavaScript for sophisticated layout and animation because the platform lacked primitives for these tasks.
To compete with the sophisticated interaction patterns of native iOS and Android applications (Something people were obsessed with at the time), we invented an entirely new architecture: the single-page application. There’s a direct analogy here to the earliest days of web design. Before CSS and modern layout systems, we created hacks like using tables to create page layout. To work around the web’s typographical limitations (which essentially didn’t exist), we’d render text in Photoshop and embed those images in our table-based layouts.
In hindsight, these approaches might appear laughable or baffling. But at the time, if we wanted sophisticated typographical pages that could compete with print, these were the tools we had.
As the Web platform matured, it gained features that allowed proper page layout and sophisticated typography. It was a gradual process—one that required not only changes to platform capabilities but changes in our approaches and thinking. It took the better part of a decade for table-based layouts and image replacement techniques to die out.
The web’s fourth epoch?
I think we’re in the midst of a similar evolution today. Just as we no longer need tables for layout now that we have platform primitives for that purpose, do we still need the single-page application architecture? We now have platform primitives like view transitions and speculation rules. The emerging local-first architecture, enabled by Service Workers and sophisticated client-side storage (often SQL-based), makes increasing sense.
But the rise of frameworks like React, Next.js, Vue, and Angular wasn’t simply about providing capabilities the platform lacked. It was about developer experience. However, as I’ll argue in depth in an upcoming piece, generative AI is becoming the developer experience now.
Well established hierarchies
With widespread CSS layout support, we no longer need tables for positioning. With embedded fonts, image replacement techniques became obsolete. As the web platform adds new capabilities, we don’t just remove legacy technologies—we sometimes need to fundamentally rethink how we build.
Are we at a period of punctuated equilibrium in web development? Even when all conditions for change exist, transformation isn’t inevitable. But I don’t think I’m alone in sensing we’re nearing a fourth great change in developing for the web.
The question we as developers must ask ourselves is: “Will we still be clinging to tables and image replacement techniques when something far better has come along?”
Because it was only after we made those earlier transitions and adopted new technologies that we could see the bigger picture. It was still some time after that transformation before we got responsive web design—a development that was only possible because we had first embraced the platform’s evolving capabilities.
The signs are there. The question is whether we’re ready to read them. Or shall we continue to be enthralled by ritual?
Now on with this weeks reading.
Web Platform
Using the Custom Highlight API
The Custom Highlight API came to my attention recently as Firefox recently started supporting it (Firefox 140, June 2025), which brought support across all the major browsers. With it, you can apply (some) styling to text that you get your hands on in JavaScript via the Range() class. I would say text that you select, but there aren’t really normal selectors involved here, making it rather unusual to work with for a CSS guy like me.
Source: Using the Custom Highlight API – Frontend Masters Blog
Traditionally, to style a part of a web page, we would need a document fragment to apply that style to. An exception to this is the custom highlight API which enables us to identify a word or a range within a specific document element to apply style to. This article explains how to work with it and some use cases for where it may be valuable.
The Power Of The Intl API: A Definitive Guide To Browser-Native Internationalization
Internationalization Intl JavaScript
Internationalization isn’t just translation. It’s about formatting dates, pluralizing words, sorting names, and more, all according to specific locales. Instead of relying on heavy third-party libraries, modern JavaScript offers the Intl API – a powerful, native way to handle i18n. A quiet reminder that the web truly is worldwide.
Internationalization is about a lot more than simply translation or using localized language depending on the user’s language preferences. There are date formats, number formats, and, as I constantly grapple with, currency formats as well. The web has great support for internationalizing things like this. As this fantastic article details. We also have quite a few presentations on Conffab on the topic, so if it’s of value to you, why not check out some of those?
CSS & Frontend Development
There’s no such thing as a CSS reset
CSS resets are a technique nearly as long lived as the modern CSS era itself, stretching all the way from the CSS Zen Garden days to inclusion in mass-market current-day tools like Tailwind. Resets are a staple in the CSS toolkit. But here’s the thing; there’s no such thing as a CSS reset. Now, to be clear, I’m not suggesting some kind of long-running mass hallucination. I’m suggesting CSS resets don’t do what the name says. The word “reset” implies an objective default state that you’re restoring to, but the only objective default state is what browsers ship. You cannot “reset” browser styles by addition. Resets are inherently subjective, which means in practice, you are not so much resetting as you are defining default element styles for a website.
Source: There’s no such thing as a CSS reset | Adam Stoddard
Adam Stoddard here doesn’t so much suggest that we don’t have CSS resets but we rethink what they are doing.
Cascading Layers of !mportance
Cascade Layers CSS CSS Architecture
The Cascade is the underlying algorithm that applies our styles the web, and a main target of frustration when our styles go bad. But why is it there, how is it changing, and why should we care? Cascade Layers are now widely available, with the potential to fundamentally change how we think about the cascade – and how we collaborate across design systems, component libraries, and third-party tools.
Source: Cascading Layers of !mportance – Miriam Suzanne
The way we architect CSS has always been a bit of a pain point of the language. As the uses we put it to have become more complex, that complexity has been reflected in the CSS we produce. Ultimately, we end up with challenges around specificity, inheritance, and the cascade that can be very challenging to manage. A solution that has emerged for CSS is Cascade Layers. It’s actually been around for a few years now and it’s well-supported but not widely adopted. Here Miriam Suzanne discusses cascade layers and how we can use them. And make sure you check out some other talks on Conffab around the same topic as well.
JavaScript
How To Improve INP: Yield Patterns
Core Web Vitals INP Interaction to Next Paint
In the following, we’ll go over different patterns we can use to yield to the main thread to improve the Interaction-to-Next-Paint (INP). Knowing how to improve INP is more important than ever, as it’s a metric reflecting User Experience (UX) and has recently been added to the Core Web Vitals (CWVs) – which are used by Google’s search ranking.
We’ll take a look at which part of INP we’re targeting, how browser scheduling and yielding works, pros and cons of each pattern and where we can make use of those.
Source: How To Improve INP: Yield Patterns | Jacob ‘Kurt’ Groß
Interaction to Next Paint (INP) is a newer Core Web Vital that is more challenging to get right for many applications. Here Jakob Gross looks at patterns for improving INP. This is something Nishu Goel spoke about a couple of years ago at one of our conferences, and you can watch that here.
JavaScript isn’t the problem. Replacing the browser was.
Architecture JavaScript React SPA
We spent a decade rebuilding the browser by hijacking routing, manually syncing state, rebuilding forms and transitions in JavaScript to match native app expectations. Now the browser has caught up. It’s time to stop the hacks and build on the web again, but properly.
Source: JavaScript isn’t the problem. Replacing the browser was. | RedwoodSDK
The era of heavy client-side JavaScript driven frameworks may be coming to a close. Despite their shortcomings, there were very solid reasons for this approach. But those reasons with the maturity of the web platform and features like view transition and speculation rules mean that many of the reasons for these architectural choices are no longer as significant. As Peter Pistorius observes:
We can finally stop fighting the browser. We can stop re-implementing it. And we can start building on top of it, natively, progressively, and with confidence. JavaScript isn’t the problem. Replacing the browser was.
AI & Software Development
Talking Postgres with Claire Giordano | AI for data engineers with Simon Willison
AI Native Dev Generative AI LLMs Software Engineering
It’s always a good day if you see a pelican. In Episode 30 of Talking Postgres with Claire Giordano, open source developer Simon Willison—creator of Datasette and co-creator of Django—joins to explore how AI is useful for data engineers today. We move past the hype and boosterism to dig into example after example: structured data extraction, alt text and accessibility, safety and security (aka the fiddly bits), and why Postgres’s fine-grained permissions are such a good fit for AI-powered workflows. Also: Pulitzer-worthy data tooling, the science fiction of the 10X engineer, agents, MCP, RAG, the multitude of models, and why Simon spends so many waking hours on the jagged frontier of AI.
Source: Talking Postgres with Claire Giordano | AI for data engineers with Simon Willison
Over the last three years or so, as generative AI has had a very significant impact on the practice of software engineering, someone whose sensible, experienced, and thoughtful writing on the topic I have followed closely is Simon Willison. He writes almost every day about his experiences and thoughts, and he is a frequent go-to for interviewers and as a speaker at conferences. I recommend anything he writes or any interview he does. Here’s a recent one that you might find valuable for your next commute or dog walk.
The Future Of Software Is Small
AI Architecture LLMs Software Engineering
AI makes time very, very, very cheap. It’s not unreasonable to expect that within ~5 years, we’ll have consumer-grade hardware with onboard capabilities that rival current state-of-the-art models (Claude 4, etc.) that are also faster and cheaper than those models are today. This is an absolute sea change in terms of capability at an OS level; Custom applications will become the norm, not the exception. Why try to grapple with fitting my life into Notion (or whatever) when I can just have the computer build me bespoke applications that work on all my devices and are catered to my precise needs? Why do I need planet-scale infrastructure to share baby photos with, like, 5 people?
Source: The Future Of Software Is Small – aparker.io
While it’s typically attributed to Bill Gates, the observation that we tend to overestimate what technology can achieve in a short time frame and underestimate the impact in a long time actually originates with a Stanford academic Roy Amara in the 1960s, and doubtless others had observed it before. Especially at the beginning of transformations, we can get swept up in the excitement of new technologies. As we’ve seen in the last two or three years, extraordinary claims have been made about the impact of Generative AI in the very short term. Here, Austin Parker thinks about the medium-term consequences of these technologies and predicts that the capabilities of those frontier models have today will be running on our smallest devices within a few years. What are the consequences of that? What does software look like? These are the sorts of things that if you design, develop, or otherwise deliver digital products, you really should be thinking about right now.
No One Knows Anything About AI
I want to present you with two narratives about AI. Both of them are about using this technology to automate computer programming, but they point toward two very different conclusions. The first narrative notes that Large Language Models (LLMs) are exceptionally well-suited for coding because source code, at its core, is just very well-structured text, which is exactly what these models excel at generating. Because of this tight match between need and capability, the programming industry is serving as an economic sacrificial lamb, the first major sector to suffer a major AI-driven upheaval.
…
But, if you read a different set of articles and quotes from this same period, a very different narrative emerges
Source: No One Knows Anything About AI – Cal Newport
The celebrated Hollywood screenwriter William Goldman, writer of such classics as “Butch Cassidy and the Sundance Kid” and “The Princess Bride,” famously quips about Hollywood that nobody knows anything. That’s something I’ve said once or twice myself about our current wave of generative AI. And Cal Newport has been thinking something similarly as well. His conclusion?
Tune out both the most heated and the most dismissive rhetoric. Focus on tangible changes in areas that you care about that really do seem connected to AI—read widely and ask people you trust about what they’re seeing. Beyond that, however, follow AI news with a large grain of salt. All of this is too new for anyone to really understand what they’re saying. AI is important. But we don’t yet fully know why.
Developers, Reinvented
A vital shift is underway in software development, one that redefines how we build, but also who we are as developers. In recent interviews we spoke with 22 developers that already use AI tools heavily in their workflow, and learned how they got there, how their craft has changed, and where they see things going.
Source: Developers, Reinvented
Let’s start by acknowledging that this is from the CEO of GitHub who clearly has a huge investment in developers using AI as part of their development process. And this is a very small sample size that is selected from those most enthusiastic about the use of large language models in that process. But I do think there are some valuable insights in this that might help people chart their own evolution with working with these technologies. Some of the insights certainly reflect my own experience of working with large language models over the last three years or so as a software engineer.
Vibe code is legacy code
Despite widespread confusion, Andrej Karpathy coined “vibe coding” as a kind of AI-assisted coding where you “forget that the code even exists.” Legacy code: We already have a phrase for code that nobody understands: legacy code. Legacy code is universally despised, and for good reason. But why? You have the code, right? Can’t you figure it out from there? Wrong. Code that nobody understands is tech debt. It takes a lot of time to understand unfamiliar code enough to debug it, let alone introduce new features without also introducing bugs.
Source: Vibe code is legacy code | Val Town Blog
As we’ve observed before here at Conffab, and as folks like Jeremy Howard have observed, a lot of software has always been written by non-professional developers. It’s been spreadsheets, Visual Basic, and Microsoft Access. But that doesn’t make this software any less useful or any less important in many respects. Software like this is not battle-hardened, it’s not security-tested, but it serves a purpose within an organization. And vibe coding or using code generation without really understanding or caring about the output is something that will I think replace this kind of software development. Of course, as observed here, if we’re developing production software and yoloing it when it comes to the code, we’re going to have security issues, performance issues, and all kinds of technical debt building up. So vibe code away for your disposable stuff like I do all the time, but when it comes to the durable stuff, as Charity Majors puts it, I think we better pay closer attention to the code that we generate, whether with the support of LLMs or in the good old fashioned two-finger pecking out on the keyboard way.
The web isn’t URL-shaped anymore
Half of your website’s audience isn’t human. Search engines, crawlers, bots and agents likely already consume more of your site than people do. And they don’t experience it the way humans do. Humans load a page at a URL and absorb the whole thing: design, content, messaging, intent. Machines treat that URL as an envelope – something to tear open, strip apart, and mine for meaning.
Source: The web isn’t URL-shaped anymore – Jono Alderson
Websites have long had audiences other than humans, typically search engines. But it’s likely we’re going to see an explosion in not just large-scale agents run by organizations and search companies, but individual agents operating at the behest of individual users. From both an engineering and a design perspective, we are going to have to start thinking about how we serve the needs of those users as well as our human users. Here Jono Alderson thinks deeply about the implications of this. It’s definitely a topic I see us covering more at our events, and one I think that whatever your role in designing and developing for the web, you should start paying attention to.
Design Systems & Development
Automating Design Systems: Tips And Resources For Getting Started
Design systems are more than style guides: they’re made up of workflows, tokens, components, and documentation – all the stuff teams rely on to build consistent products. As projects grow, keeping everything in sync gets tricky fast. In this article, we’ll look at how smart tooling, combined with automation where it makes sense, can speed things up, reduce errors, and help your team focus on design over maintenance.
Source: Automating Design Systems: Tips And Resources For Getting Started – Smashing Magazine
From the ever-excellent Smashing Magazine, an article on how as the complexity and size of our design systems grow, we can maintain them using automation.
Avoiding the hidden costs of leadership debt
Technical debt is well recognised. But the same logic of ever-shifting organisational needs – and therefore the debt accrued by standing still – applies to leadership too. As a leader, your skills, models and culture operate as a system of their own, determining how well your organisation is able to adapt and respond to change.
Source: Avoiding the hidden costs of leadership debt
We tend to think quite a bit these days about technical debt and even the idea of product debt. But here Oli Lovell asks us to consider leadership debt.
Accessibility & Standards
The Web Is About to Get Better for Everyone, Everywhere
The next big thing in web development isn’t a framework. It’s a piece of legislation.
Starting summer 2025, the European Accessibility Act will require digital products provided in the EU to meet actual, enforceable accessibility standards. Not “we added some alt text” accessibility. Real accessibility. The kind you can be sued over.
And that means the internet is about to get a lot more usable.
Turns out “do the right thing” works better when it’s legally enforced.
Source: The Web Is About to Get Better for Everyone, Everywhere – Den Odell
Accessibility requirements are legal obligations in many parts of the world. Although enforcement of these regulations can be variable. There’s new legislation in the European Union which will enforce quite rigorous accessibility standards, which as Den Odell argues here may see those standards adhered to elsewhere in the world.
Accessibility and the agentic web
So, what if there was a different way? What if I could ask a digital personal shopping assistant to help me find clothes based on my preferred parameters? What if I could ask the assistant for product descriptions, then have a conversation with it to find out more, before letting the assistant know which one I’d like to purchase?
You may not know that this is already possible. It’s still nascent technology, but it exists, and it’s being used today to improve the accessibility and usability of the retail shopping experience.
Source: Accessibility and the agentic web – TetraLogical
It’s not just developers who are thinking about agents and autonomy. We’ve recently cited a number of articles here at Conffab from designers thinking about the challenge of what happens when many of your users aren’t humans but some form of autonomous agent. Here Leonie Watson considers the implications of this for accessibility. And she wonders whether there is even any point in websites anymore in this new world.
Design & UX
Taste is a dead end; what you should have is a point of view
By justifying decisions on the basis of taste, designers are throwing away the influence they need for preventing low-value feature bloat
Source: Taste is a dead end; what you should have is a point of view
We’ve linked to quite a few articles on taste in the last year or so here, and this idea that the development of taste and the importance of taste in an era of AI has gained some traction, particularly in the design world. Pavel Samsonov argues that it’s in fact a point of view that designers need to develop in order to influence the direction of product development within their organizations.
From Clippy to Copilot: UX Design in the Age of AI Browsers
Remember Clippy? The overly enthusiastic paperclip that would interrupt your Word document to ask if you were writing a letter? At the time, it was ridiculed – we dismissed it as Microsoft’s well-intentioned but somewhat misguided attempt at helpful computing. Well, it seems Clippy’s back. But he’s evolved considerably.
Today’s AIs no longer just ask if you’re writing a letter. Now they’ll have access to your calendar, can navigate your inbox more efficiently than you, and likely know what you need to do next well before you do. We’re entering the age of AI browsers, and this could represent a fairly significant shift in how we approach UX and digital design moving forward.
Source: From Clippy to Copilot: UX Design in the Age of AI Browsers
Ben Tollady ponders the challenges for designers when it might be agents and not users who are visiting your site.
Sustainability
Designing a Grid-Aware Branch
Branch launched five years ago, and if you’ve been following along, you may have noticed that issue 9 arrives with a fresh site redesign. This new design builds on valuable feedback we’ve received from you, our community, and some brand-new ideas we’ve been exploring as part of the Green Web Foundation’s Grid-aware Websites project.
Source: Designing a Grid-Aware Branch
We’ve covered the impact of the web on the environment and energy use a few times here at Conffab. Here the folks at Branch Magazine talk about redeveloping their website to be grid-aware.
Great reading, every weekend.
We round up the best writing about the web and send it your way each Friday.
