This week’s reading from Web Directions
This week, we launched the programme for our upcoming Next conference, “Product in the Age of AI and LLMs“, as well as the full programme for our Developer Summit conference, coming up in late November in Sydney and, of course, online.
Check out the programmes, mark your calendars, and we’ll see you there for these fantastic events!
If you’d like extra special pricing as well as, of course, all this great reading delivered weekly to your inbox, just sign up to our weekly newsletter.
JavaScript & Programming
Finally, safe array methods in JavaScript
There’s a good reason that many developers pause before using .sort(), .reverse(), or .splice() in JavaScript: those methods mutate the original array. That single side effect can lead to subtle, hard-to-trace bugs, especially in apps with shared or reactive state. The good news is that in the last couple of years we’ve gotten new array methods that make working with arrays safer and cleaner by avoiding mutation altogether:
Source: Finally, safe array methods in JavaScript – Matt Smith
We’ve covered some of the new JavaScript array functions more than once at presentations on Conffab. Here Matt Smith gives us an overview of these new methods. Why do we need them? What advantages do they bring us? Well, they do not mutate the original array they operate on.
Regexes Got Good: The History And Future Of Regular Expressions In JavaScript
JavaScript regex regular expressions
Although JavaScript regexes used to be underpowered compared to other modern flavors, numerous improvements in recent years mean that’s no longer true. Steven Levithan evaluates the history and present state of regular expressions in JavaScript with tips to make your regexes more readable, maintainable, and resilient.
Source: Regexes Got Good: The History And Future Of Regular Expressions In JavaScript — Smashing Magazine
We’ve covered regular expressions more than once here at Conffab. I still recall first encountering them in the first year of computer science, many, many, many years ago, and now as then they continue to largely feel like magical incantations. I must admit, I now use a large language model to give me regular expressions when I need to use them. They’ve long been in JavaScript, but they’ve been improving in recent years. Learn here all about how regular expressions got good in JavaScript.
CSS & Frontend Development
Integrating CSS Cascade Layers To An Existing Project
cascade layers CSS CSS architecture
The idea behind this is to share a full, unfiltered look at integrating CSS Cascade Layers into an existing legacy codebase. In practice, it’s about refactoring existing CSS to use cascade layers without breaking anything
Source: Integrating CSS Cascade Layers To An Existing Project — Smashing Magazine
Cascade layers are now well supported in evergreen browsers and provide a mechanism to help manage the complexity of specificity, cascade, and inheritance that we often use !important, increasingly elaborate selectors, or some flavour of CSS-in-JS to otherwise deal with. But a lot of our work is with established codebases where incorporating cascade layers can be challenging. Here Victor Ayomipo looks at how we can go about refactoring our CSS to incorporate cascade layers.
We Keep Reinventing CSS, but Styling Was Never the Problem
We’ve been building for the web for decades. CSS has had time to grow up, and in many ways, it has. We’ve got scoped styles, design tokens, cascade layers, even utility-first frameworks that promise to eliminate bikeshedding entirely.
And yet, somehow, every new project still begins with a shrug and the same old question:
“So… how are we styling things this time?”It’s not that we lack options. It’s that every option comes with trade-offs. None of them quite fit.
We keep reinventing CSS as if it’s the root cause.
It isn’t.
Source: We Keep Reinventing CSS, but Styling Was Never the Problem — Den Odell
CSS doesn’t work like most things that software developers have experienced. Concepts like inheritance, the cascade, specificity largely operate on a global scope. All of these may contribute to a complexity that can be hard to manage. We have developed numerous methodologies like OO-CSS, BEM, and many CSS-in-JS approaches to try and tame this complexity over the last 20 years or so. But what if CSS isn’t the problem? That’s the question that Dan Odell asks here.
The Fundamentals of CSS Alignment
While centering elements in CSS has become easy over time, there is still a lot of confusion around alignment in general. Let’s be honest, you always end up trying different combinations until it works, but you don’t really understand how it works, right?
Which property is for vertical alignment?
align-contentoralign-items? Where should I adddisplay: flex? Let’s add it everywhere! A height? Why do I need to define a height!? Maybe I should try withdisplay: grid?It’s time to clear all the confusion! Through this exploration, you will understand the logic behind all the alignment properties and how they work in each layout. It’s not another article about centering, we are going beyond!
Source: The Fundamentals of CSS Alignment
I’m going to admit it, I still find myself either looking up CSS Tricks’ great Flex cheat sheets or using my browser’s dev tools to remember which particular property and value will achieve my desired flex layout. But this article lays it all out in clinical detail.
Web Platform & Browser News
Google Chrome at 17 – A history of our browser
I still remember the fall of 2008 when Google launched Chrome – a quirky new browser with a comic book as its press release. As someone who’s spent a long time on the Chrome team, I’ve watched this project grow from a secret skunkworks to a browser used by billions. Chrome turns 17 this week, and it feels like a good time to reflect on how far we’ve come in terms of Chrome’s guiding principles: speed, security, stability, and simplicity [1]. In this write-up, I’ll walk through Chrome’s origins and evolution across these pillars (as best I know them), highlight key milestones (from multi-process architecture to AI-powered features), and share a few behind-the-scenes tidbits along the way. It’s been an incredible journey – one driven by relentless performance improvements, cutting-edge security efforts, and an uncompromising focus on user experience. Let’s dive in!
Source: AddyOsmani.com – Google Chrome at 17 – A history of our browser
For many, even these days, experienced web developers, Chrome will feel like it’s always been with us. I still think of it as a relatively new browser, though it has just turned 17 years old. Without Chrome, it’s hard to know exactly where the web would be, but it’s very unlikely that the platform would have the richness and sophistication that it does. Here Addy Osmani looks at the history of this browser, and it’s well worth reading for anyone who develops for the web.
Performance & Web Optimization
Low- and Mid-Tier Mobile for the Real World (2025)
TL;DR: If you want broadly representative Android hardware for real-world web performance testing in 2025, buy a Samsung Galaxy A15 5G (SM-A156x) (low-tier) and a Samsung Galaxy A54 5G (SM-A546x) (mid-tier). Both are mass-market, widely ranged across regions, have multi-year software support, and map well to Chrome DevTools’ Low- and Mid-tier presets.
Source: Low- and Mid-Tier Mobile for the Real World (2025) – CSS Wizardry
As folks like Alex Russell have been trying to get us to see for years, we (with our relatively up-to-date iPhones and recent MacBook Pros) are not by any means typical of the sort of real-world users set up. When testing the performance of our sites, keeping the older or less top-specced devices in mind is important. But what does that mean in 2025? Here, Harry Roberts investigates.
Should you preload fonts for performance?
Everyone’s preloading fonts for faster sites. But did you know it can secretly push your First Contentful Paint back instead? Let’s look at when preloading helps, when it hurts, and the simple rules to follow.
Source: Should you preload fonts for performance? | Erwin Hofman
Fonts can be large files. And we know loading large files can have a negative impact on performance and core web vitals. So here Erwin Hofman asks, how can you improve the performance of pages that use embedded fonts? Should we pre-load our fonts for performance?
Web Components & Modern Development
Architecture & Development Process
Local-First Landscape
architecture local-first offline
Whether you’re a developer looking to experiment with local-first patterns or a technical leader making a strategic technology decision, this resource helps you navigate the growing ecosystem of local-first tools and make informed choices.
Source: Local-First Landscape
The local-first architecture is gaining some mindshare, and we expect to only gather more momentum. We’ve covered it a couple of times already on the platform, and here’s a site that gives you an overview of the technologies available to implement the architecture.
The Mindset Shift for Designing Better Frontend Systems
architecture software engineering
When you read most design docs or product requirements, you’ll notice something: they’re almost always about the happy path — the perfect scenario where everything works exactly as intended.
The assumptions are: all services respond correctly and timely, the network is always stable, users are on modern browsers (and latest devices), and nobody makes mistakes. But reality is far messier than that.
Users mistype their email addresses, click the wrong button (because of bad designs or accessibility issues), or lose connection mid-action. Developers and QAs make mistakes too. Services fail. Devices slow down. And more often than not, the unhappy path is the one your system will have to deal with.
In truth, the happy path we love to design for is just a small slice of a system’s real life. Frontend system design — even if you’re “just” working on the UI — is largely about anticipating and handling these unhappy paths.
Source: The Mindset Shift for Designing Better Frontend Systems
Juntao Qiu has been writing extensively on frontend systems design in recent months. We’ve linked to at least a couple of his pieces lately. Here he observes that when we design systems, we very often think about the “happy paths” (the best possible use cases) and pay less attention to when things don’t go quite as well. But as he observes, it’s this ability to see outside the most common use cases and paths that distinguishes the senior developer from the rest. Here he explores the mindset shift required to think beyond the happy paths. Juntao will also be speaking about our upcoming Developer Summit on this topic.
Everything I know about good API design
API architecture software engineering
Most of what modern software engineers do involves APIs: public interfaces for communicating with a program, like this one from Twilio. I’ve spent a lot of time working with APIs, both building and using them. I’ve written public APIs for third-party developers, private APIs for internal use (or consumption by a single frontend page), REST and GraphQL APIs, and even non-network interfaces like the ones for command-line tools. Like designing good software systems, I think much of the advice floating around about API design is too fancy. People get wrapped up in what “real” REST is, or whether HATEOAS is a good idea, and so on. This post is my attempt at writing down everything I know about designing good APIs.
Source: Everything I know about good API design
As developers, we may not write APIs often if at all, but we work with them every day. So it’s worth thinking a bit about what makes for good API design, even if you are rarely ever going to do it yourself.
AI & Development Tools
AI Wants to Kill the Frontend Developer. It Won’t Work.
AI career LLMs software engineering
Every few years, someone declares my job dead.
First it was Flash. Then it was Dreamweaver. Then it was “anyone can drag-and-drop a Wix site.”
Now it’s AI.
The headlines practically write themselves: AI makes frontend engineers obsolete. The end of coding as we know it. Software that writes itself.
And just like every other “frontend killer,” it’s being oversold.
Source: AI Wants to Kill the Frontend Developer. It Won’t Work. | HackerNoon
For almost the entire time I have had anything to do with computers (which is quite a few decades now), people have been suggesting that the end of software development is just around the corner. Whether it is what we used to call fourth-generation languages, whether it’s low-code or no-code solutions, or now AI, there’s always something that was going to do what software engineers do any day now better and cheaper. So far, that hasn’t worked out, but it doesn’t mean just because something hasn’t happened so far, it won’t ever happen. What is the likelihood that large language models will get rid of our jobs, particularly in frontend? Dan Odell has some well-thought-through ideas here that I think are well worth contemplating. I think there’s little doubt that not only will software engineering, including frontend development, change—it already is significantly. So if we want to continue to stay relevant, these are the sorts of things we should definitely be thinking about.
My Vision for AI and the Web
AI will not all run locally yet. Large models still need server-side power. But smaller, specialized models can run on your device today, privately and securely. That is the balance I believe in: local AI for lightweight, privacy-first features, and server AI only when the workload is too heavy. On top of that, privacy on the server side is improving quickly thanks to technologies like GPU enclaves, for example Nvidia’s Confidential Compute. As devices get stronger and these safeguards mature, more intelligence can shift back to the user’s side with stronger guarantees at every step.
Source: My Vision for AI and the Web | Tarek Ziadé
Many people are far from most optimistic about the impact of large language models on the web. Firstly, for better or worse, the business model of the web for the last two decades or more has been advertising and traffic driven to publishers by search. But with large language models increasingly replacing search engines, and even Google providing answers directly on their site for queries, it seems this traffic, the lifeblood of independent content producers, may well be drying up. Meanwhile, what is the role of the browser in all this? Chrome and Firefox have been introducing some of the functionality we get from large language model providers like OpenAI and Anthropic directly in the browser. These can help address some of the concerns folks have, in particular around privacy and to some extent energy consumption. Here Tarek Ziadé who works on Mozilla explores some ideas about the role browsers might play in this era of large language models.
Working with Contexts – O’Reilly
Managing Your Context Is the Key to Successful Agents
As frontier model context windows continue to grow, with many supporting up to 1 million tokens, I see many excited discussions about how long-context windows will unlock the agents of our dreams. After all, with a large enough window, you can simply throw everything into a prompt you might need—tools, documents, instructions, and more—and let the model take care of the rest.
Long contexts kneecapped RAG enthusiasm (no need to find the best doc when you can fit it all in the prompt!), enabled MCP hype (connect to every tool and models can do any job!), and fueled enthusiasm for agents.
But in reality, longer contexts do not generate better responses. Overloading your context can cause your agents and applications to fail in surprising ways. Contexts can become poisoned, distracting, confusing, or conflicting. This is especially problematic for agents, which rely on context to gather information, synthesize findings, and coordinate actions.
Let’s run through the ways contexts can get out of hand, then review methods to mitigate or entirely avoid context fails.
Source: Working with Contexts – O’Reilly
Certainly, when it comes to software development using large language models, the context we provide the model seems to have a very significant impact on the model’s performance. We spend a lot of time thinking about what makes for a good prompt, but less so thinking about how we manage the contexts we provide our models.
The return of tech specs – Frontend Masters Blog
AI Native Dev LLMs software engineering
I’m confident that going forward, software engineers will need to relearn how to create detailed tech specs for complex changes. It’s also likely that AI will help write and review these specs before implementing them. It’s time to embrace tech specs again because they can be a key to advancing your career.
Source: The return of tech specs – Frontend Masters Blog
It turns out that writing technical specifications may ultimately be the way in which we work with our AI agents most effectively in their role as software developers.
Design Systems & Product Design
A Call for a Product Design Manifesto
Let’s be honest, Product Design has lost its way and purpose. Not because Product Managers took it away, not because engineering pushed us aside, but because too often, we’ve accepted a smaller role for ourselves.
Every time we treat a PRD as our starting point, we reduce product design to delivery. We become executors of someone else’s decisions, decorators of someone else’s brief.
That’s not Product Design. That’s UI execution with a shinier title, let’s stop pretending it’s something it’s not.
It’s time to draw the line.
Source: A Call for a Product Design Manifesto | by Darren Smith
This piece will resonate with many designers. It’s a call for design to have a bigger role in the development of products. For design to be more than execution.
Great reading, every weekend.
We round up the best writing about the web and send it your way each Friday.
