Den Odell’s Journal

The Web Is About to Get Better for Everyone, Everywhere

Wed, 23 Jul 2025 13:00:00 GMT

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.

The Accidental Global Upgrade

On paper, the EAA is about protecting the rights of disabled users in the EU. In practice, it will quietly upgrade the user experience for everyone, everywhere.

Because global companies don’t build fifty different versions of their site. They build one. And when that one needs to pass strict accessibility checks in Europe, it becomes the new default for everyone. Not because they’ve had a sudden ethical awakening, but because it’s cheaper than maintaining a fork.

I’ve seen this happen firsthand. At Volvo Cars, I helped lead accessibility work on a complex finance interface used across dozens of countries. Some markets had legal requirements. Others didn’t. We didn’t build two versions. We built one good one. That’s what’s about to happen at scale.

This Isn’t GDPR. It’s Deeper.

We’ve been here before. The GDPR forced companies to rethink privacy. Cookie banners popped up everywhere, and data practices changed, even in countries that had no such law.

The EAA will have the same ripple effect. But where GDPR mostly lives in popups and policy pages, accessibility lives in your codebase. This time, it’s going to affect how teams design, build, and ship products.

Developers will need to stop misusing <div>s and start writing semantic markup. They’ll have to test keyboard navigation and make sure screen readers can do more than guess. Designers will need to think about contrast, focus indicators, and interaction patterns that work for more than just perfect eyesight and fine motor control. Product managers will need to bring accessibility forward in the roadmap, instead of leaving it to sprint eleven.

For teams that never took it seriously, this will feel like a lot. Because it is.

Everyone Wins, Eventually

The good news is, once companies start updating their design systems and components to comply, those updates don’t stay locked inside. They spread.

When Figma kits, React libraries, or UI frameworks adjust for accessibility, thousands of developers benefit, even if they’ve never heard of the EAA. Small teams and solo devs inherit improvements without lifting a finger. Your bootstrapped SaaS gets better because someone at a bank had to follow the law.

And just like GDPR influenced privacy legislation far beyond Europe, the EAA could nudge other governments into action. The US has had the ADA for decades, but it has never applied consistently to the web. That may change once global companies start setting a new baseline.

Even if no new laws appear, the precedent is clear. Accessibility is not a bonus. It is a requirement.

There’s Still Work to Do

Laws help, but they don’t write your code. Teams will need support. Tooling will need to catch up. Companies will need to invest in audits, training, and inclusive hiring.

But the momentum is there. And for once, it isn’t being driven by blog posts or industry talks. It’s being driven by legislation with actual teeth.

For years, accessibility experts have asked companies to take this seriously. Now they have to.

Turns out the web gets fixed quicker when ignoring it brings in the lawyers.

AI Is Just the Latest Frontend Killer. Don’t Panic.

Wed, 09 Jul 2025 13:00:00 GMT

Apparently, frontend developers are about to be made obsolete.
AI can scaffold a site from a prompt, restyle it mid-conversation, and write tests it will never have to maintain.
It’s fast. It’s confident. And according to some, it means we’re done here.

This all sounds very familiar.

The End Of The Frontend Profession?

The first time I saw an AI coding assistant write a React component, I paused.

It used the right hook. Destructured props neatly. Even remembered the aria-label.

Well, I thought, there goes the frontend job market.

But the more I used it, the more I tried to hand it real work, the more it missed the mark. It was fast, yes. But shallow. Confident, but clueless. It could write code, but not the right code. Not in the way I needed it.

And that’s when it clicked: the risk isn’t that AI will replace frontend jobs. It’s that it will replace the ones that were already replaceable.

What AI Still Doesn’t Get

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.

The Demos Look Clean. The Reality Isn’t.

I’ve seen the posts.

AI tools generating complete sites in a single session. Pixel-perfect designs from a few prompts. “Production-ready” apps without a line of hand-written code.

And yes, it’s impressive. The scaffolding is faster than ever. The demos look clean.

But when you try to scale them, test them, or make them fast, accessible, and reliable across real devices and real users?

That’s where the job actually begins.
And that’s not something I trust a code generator to own.

More Than Just a Coder

I still write code, of course. But I also…

Trace where the bloat comes from
Fix interactivity delays no audit tool flags
Catch the missing aria-describedby before it hits QA
Explain to designers why we can't animate everything, everywhere, all at once

These aren’t things I want to outsource. They’re the job.

AI is a Tool, Not a Threat

I do use AI. It helps me prototype faster, summarize unfamiliar APIs, and draft tests I’d rather not write by hand. Sometimes it even surprises me with a pattern I hadn’t considered.

But I never copy anything I don’t understand. I don’t ship what I wouldn’t explain.

I’ve done on-call. I’ve supported real users at real scale. And I can tell you, I wouldn’t want to be the one debugging production issues in code I didn’t fully understand, especially not at 2am. If AI wrote it, I need to own it before I ship it.

The responsibility, the judgment, is still mine.

We’ve Been Here Before

I’ve been building for the web professionally for 25 years. That’s long enough to have watched entire tech stacks rise and fall. From table layouts to Flash to jQuery to SPAs to server-first rendering and back again.

And I’ve seen the “death of frontend” declared more than once.

When Dreamweaver promised you’d never need to write HTML again.
When Flash and Silverlight tried to replace the browser.
When JavaScript frameworks told us the DOM was obsolete.
When no-code tools promised designers wouldn’t need developers.
Now it’s AI’s turn.

Each time, the pitch was the same: this new thing writes the code for you.
But the complexity didn’t go away. It just shifted.
And the need for people who understand users, performance, and systems never disappeared.

What Hasn’t Changed

So what’s different this time? Not much. Just the speed, and the hype.

AI is better than the tools that came before it. No question.
But the fundamentals of great frontend work haven’t changed: fast interactions, inclusive experiences, clear architecture, systems thinking.

We debug the weird bugs. We balance performance with design.
We build for everyone, not just the fast, the lucky, or the local.

That’s what real frontend engineers do.
That’s what I do.

And I’m not planning to become obsolete anytime soon.

UPDATE 21 Aug 2025. An updated, extended version of this article can be found on Hacker Noon: https://hackernoon.com/ai-wants-to-kill-the-frontend-developer-it-wont-work

Building the Web in Islands, Not Mountains

Wed, 25 Jun 2025 13:00:00 GMT

Not every site needs to be a full-blown app. In fact, most don’t. What they need is to be fast, focused, and respectful of the user’s device.

Put another way: if your ‘About Us’ page needs 300kB of JavaScript to render a sentence about your mission, it may be time to reconsider.

We’ve leaned heavily into building everything as if it were an application: routing, state, hydration, and all. That approach works brilliantly for complex, interactive experiences. But for many sites, it leads to overengineered pages, unnecessary JavaScript, and slower interactions.

There’s a better pattern, and it’s gaining momentum again. It’s called islands architecture, and it offers a way to ship less, do more, and give users speed where it counts.

The Problem With “One Big App”

Single-page apps (SPAs) brought a wave of innovation to the frontend. They gave us smooth routing, shared state, and dynamic interactivity. For many use cases, they remain the right choice.

But when every page becomes part of one large application, even simple, mostly static ones, we start to pay a price. That price often includes larger bundles, delayed interactivity, and more work for the browser than is truly needed.

If your marketing page or blog post loads the same hydration logic and route configuration as your account dashboard, something is off. It creates work that doesn’t need to happen, especially on mobile.

What Is Islands Architecture?

Islands architecture takes a more selective approach. It renders the majority of the page server-side, using static HTML whenever possible, and hydrates only the components that need to be interactive.

Picture a page as a landmass. Most of it — layout, content, structure — is pre-rendered and delivered instantly. Then come the islands: self-contained interactive parts like a search box, a shopping cart, or a comment form. These hydrate independently and only when needed.

Instead of treating every page like a fully hydrated application, you focus interactivity where it adds the most value.

This Isn’t a New Idea

Before SPAs and JavaScript frameworks, developers often rendered pages server-side and used scripts sparingly to enhance behavior. You’d write HTML, sprinkle in jQuery plugins, and call it a day.

In hindsight, this was a kind of early islands model. The challenge was maintainability. Everything felt stitched together.

Today’s tools bring back the same mindset, but with component-based discipline and modern developer ergonomics.

How Islands Work in Practice

Frameworks like Astro are built with islands in mind. You can specify how and when a component should hydrate:

This tells Astro to render the component on the server and hydrate it only once the page is idle. Other directives include client:load, client:visible, and client:media, letting you match hydration to user context.

Other frameworks take similar or adjacent approaches:

Qwik uses resumability, which avoids hydration entirely by serializing state for instant interactivity.
Enhance.dev leans into web standards and progressive enhancement.
Fresh (Deno) supports islands as a core rendering model.
Even Next.js, with React Server Components and the app/ directory, is giving developers more fine-grained control over what runs where.

These are not opposing models. They are part of a broader shift toward delivering more HTML and less JavaScript when appropriate.

Why It’s Fast

Less JavaScript up front means quicker interactivity.
Fewer layout shifts make the experience more stable.
Lower memory and CPU usage helps users on mid-range or older devices.
Core Web Vitals like LCP, INP, and CLS often improve naturally.

And most importantly, it feels better. The page is usable immediately. You don’t wait for hydration to finish or for a loading spinner to disappear.

When to Use It

Islands architecture shines when:

Your content is mostly static, with pockets of interactivity.
You care about first load performance.
Your audience includes mobile users or bandwidth-constrained regions.

It’s a great fit for blogs, marketing pages, documentation sites, and e-commerce product pages. Anywhere that’s mostly static but benefits from pockets of interactivity.

For complex apps with deep state and interactive workflows, a hybrid model may make more sense.

But even there, treating your UI as a set of islands can still lead to smarter hydration, clearer boundaries, and better performance.

It’s Future-Ready Too

The trend is clear. Edge rendering, streaming, and component-level monitoring are all rising. Islands work well in this environment.

They support:

HTML streaming for faster time to first byte.
Incremental rendering and delivery.
Real user monitoring at the component level.
Smarter delivery based on user context such as device, viewport, and connection speed.

If your stack supports server rendering and hydration control, you are already most of the way there.

Build Islands, Not Mountains

Modern frameworks brought us power, flexibility, and developer joy. But they also nudged us toward treating every site like a full application.

Islands architecture brings balance. It keeps the parts of modern development that work, such as components, server-side rendering, and interactivity, and refocuses them around speed, simplicity, and user needs.

You don’t need to build a mountain for every page.
Islands get users where they need to go.
Without the altitude sickness.

Code Reviews That Actually Improve Frontend Quality

Wed, 20 Aug 2025 13:00:00 GMT

Most frontend reviews pass quickly. Linting's clean, TypeScript's happy, nothing looks broken. And yet: a modal won't close, a button's unreachable, an API call fails silently.

The code was fine. The product wasn't.

We say we care about frontend quality. But most reviews never look at the thing users actually touch.

A good frontend review isn't about nitpicking syntax or spotting clever abstractions. It's about seeing what this code becomes in production. How it behaves. What it breaks. What it forgets.

If you want to catch those bugs, you need to look beyond the diff. Here's what matters most, and how to catch these issues before they ship:

Catch System Failures

When reviewing, start with the obvious question: what happens if something goes wrong?

If the API fails, the user is offline, or a third-party script hangs, if the response is empty, slow, or malformed, will the UI recover? Will the user even know?

If there's no loading state, no error fallback, no retry logic, the answer is probably no.
And by the time it shows up in a bug report, the damage is already done.

Check Usability

Once you've handled system failures, think about how real people interact with this code.

Does Tab reach every element it should?
Does Escape close the modal?
Does keyboard focus land somewhere useful after a dialog opens?

A lot of code passes review because it works for the developer who wrote it. The real test is what happens on someone else's device, with someone else's habits, expectations, and constraints.

Look for Subtle Performance Traps

Performance bugs hide in plain sight.

Watch out for nested loops that create quadratic time complexity: fine on 10 items, disastrous on 10,000:

// O(n²). Fine for small test data, brutal at scale
items.map(item => 
  categories.find(cat => cat.id === item.categoryId)
)

// Fix: Pre-index categories with a Map() for O(1) lookups
const categoryMap = new Map(categories.map(cat => [cat.id, cat]));
items.map(item => categoryMap.get(item.categoryId));

Recalculating values on every render is also a performance hit waiting to happen. And a one-line import that drags in 100KB of unused helpers? If you miss it now, Lighthouse will flag it later.

The worst performance bugs rarely look ugly. They just feel slow.
And by then, they've shipped.

Trace State and Side Effects

State problems don't always raise alarms. But when side effects run more than they should, when event listeners stick around too long, when flags toggle in the wrong order, things go wrong. Quietly. Indirectly. Sometimes only after the next deploy.

If you don't trace through what actually happens when the component (or view) initializes, updates, or gets torn down, you won't catch it.

Catch Accessibility Gaps Early

Same goes for accessibility.

Watch out for missing labels, skipped headings, broken focus traps, and no live announcements when something changes, like a toast message appearing without a screen reader ever announcing it.

No one's writing <div role="button"> maliciously; they're just not thinking about how it works without a pointer.

You don't need to be an accessibility expert to catch these basics. The fixes aren't hard. The hard part is noticing.

Spot What's Missing

And sometimes, the problem isn't what's broken. It's what's missing.

Watch out for missing empty states, no message when a list is still loading, and no indication that an action succeeded or failed.

The developer knows what's going on.
The user just sees a blank screen.

Call Out Brittle Complexity

Other times, the issue is complexity.

The component fetches data, transforms it, renders markup, triggers side effects, handles errors, and logs analytics, all in one file.
It's not technically wrong. But it's brittle.
And no one will refactor it once it's merged.

Call it out before it calcifies.

Same with naming.

A function called handleClick might sound harmless, until you realize it toggles login state, starts a network request, and navigates the user to a new route.
That's not a click handler. It's a full user flow in disguise.

Reviews are the last chance to notice that sort of thing before it disappears behind good formatting and familiar patterns.

How to Deliver These Reviews

A good review finds problems. A great review gets them fixed without putting anyone on the defensive.

Keep the focus on the code, not the coder.
"This component re-renders on every keystroke" lands better than "You didn't memoize this."

Explain why it matters.
"This will slow down typing in large forms" is clearer than "This is inefficient."

And when you point something out, give the next step.
"Consider using useMemo() here" is a path forward. "This is wrong" is a dead end.

Call out what's done well. A quick "Nice job handling the loading state" makes the rest easier to hear.

If the author feels attacked, they'll tune out. And the bug will still be there.

Check the Experience, Not Just the Diff

What journey is this code part of?
What's the user trying to do here?
Does this change make that experience faster, clearer, or more resilient?

If you can't answer that, open the app. Click through it. Break it. Slow it down.

Better yet, make it effortless.
Spin up a temporary, production-like copy of the app for every pull request.
Now anyone, not just the reviewer, can click around, break things, and see the change in context before it merges.

Tools like Vercel Preview Deployments, Netlify Deploy Previews, GitHub Codespaces, or Heroku Review Apps make this almost effortless.

Catch them here, and they never make it to production.
Miss them, and your users will find them for you.

The real bugs aren't in the code; they're in the product, waiting in your next pull request.

Constraints and the Lost Art of Optimization

Mon, 23 Feb 2026 00:00:00 GMT

In 1984, Steve Jobs walked over to a bag standing on stage and pulled out a computer that would change the world. The Macintosh had an operating system, a graphical user interface, window manager, font renderer, and a complete graphics engine called QuickDraw, one of the most elegant pieces of software ever written.

The whole thing fit inside the machine’s 64KB ROM.
Sixty. Four. Kilobytes.

A typical webpage hero image is larger. Most "Hello World" apps are larger. The entire intellectual and creative output of a team that reinvented personal computing fits in a space that, today, we wouldn’t think twice about wasting on a single font file.

They did it because there just wasn’t any other choice. A larger ROM would have been too expensive for a mass-market consumer device, so efficiency and hyper-optimization was the only route.

Somewhere in the years that followed we’ve lost the creative solutions, the art of optimization, that being constrained in that way produces.

The Atari 2600 game console had 4KB of ROM and 128 bytes of RAM. Not kilobytes… bytes. And because there was no display buffer, programmers had to manually synchronize their code with the connected TV’s electron beam as it swept across the screen, line by line, sixty times a second. If your code ran too slow, the image tore. If it ran too fast, you’d corrupt the next line.

They called it "racing the beam." It was brutal, unforgiving, and it forced some of the most inventive programming in computing history.

Super Mario Bros shipped on a 40KB NES cartridge. Tetris for the Nintendo Game Boy, the most successful handheld game ever made at the time, was 32KB. These weren’t compromised experiences, they were masterpieces. The constraints didn’t diminish the work, they actually defined it.

The programmers who built these things weren’t just efficient, they thought differently. They knew their medium the way a sculptor knows stone. They understood every byte, every clock cycle, and every trade-off. The machine had no secrets from them because it couldn’t afford to.

Abundant, Cheap, Fast, and Powerful

Modern development is defined by abundance. Cheap storage, fast networks, and powerful hardware. The practical consequences of inefficiency have largely disappeared. A few extra megabytes, a few wasted milliseconds, an unnecessary UI re-render. For the most part, nobody notices and nothing breaks.

And so we’ve stopped noticing ourselves.

This isn’t out of laziness, it’s just how rational people work. When the hard limits disappear, the thinking they demanded tends to disappear with them. There’s no forcing function, no electron beam to race, no 128 bytes standing between your idea and disaster. We can afford not to understand, and so increasingly, we simply don’t.

What Can We Learn From The Past?

Here’s what I think is worth recovering: not the constraints themselves, but the relationship with the medium that having those constraints produced.

The engineers who wrote the Mac ROM didn’t just know how to be efficient, they understood their problem at a level that made elegance possible. Bill Atkinson’s QuickDraw wasn’t just small, it was a beautiful piece of code. The 64KB forced him to find the right solution, not just a working one.

That instinct, to understand deeply before you build, to ask whether this is the right structure and not just a functional one, to treat your medium as something to be understood rather than merely used, that’s the transferable thing. Not the bit-twiddling, the thinking.

The best engineers I’ve worked with carry this instinct even when others might think it crazy. They impose their own constraints. They ask what this would look like if it had to be half the size, or run twice as fast, or use a tenth of the memory. Not because anyone demanded it, but because just by thinking there could be a better, more efficient solution, one often emerges.

If you want to start developing this instinct today, the most valuable thing you can do is learn how your runtime actually works. Not at the API level, but internally. How your platform parses, allocates, renders, and executes. For web developers that means understanding the browser pipeline: parsing, style resolution, layout, paint, and compositing. For mobile developers it means understanding how iOS or Android manages memory, handles drawing, and schedules work. Understanding your platform changes what you notice, what makes you wince, and what you reach for instinctively. The engineers who built the Mac knew their domain completely, and you can know yours too.

Fast by Default

There’s a principle I keep coming back to in engineering apps for performance: fast by default. Not fast because you optimized after the fact, but fast because the thinking that produces fast software is simply better thinking. It catches unnecessary complexity early, and it produces systems that are easier to understand, easier to change, and easier to reason about under pressure.

The Atari programmers were fast by default; they had no choice. But the discipline they practiced, that intimate, demanding relationship with their constraints, that’s a choice we can still make.

The 64KB Mac ROM isn’t just a remarkable footnote, it’s a provocation. It asks: if they could do that with that, then what’s our excuse?

Not to shame us, but to remind us that constraints aren’t the enemy of great work.
They’re often the source of it.

Escape Velocity: Break Free from Framework Gravity

Wed, 05 Nov 2025 00:00:00 GMT

Frameworks were supposed to free us from the messy parts of the web. For a while they did, until their gravity started drawing everything else into orbit.

Every framework brought with it real progress. React, Vue, Angular, Svelte, and others all gave structure, composability, and predictability to frontend work. But now, after a decade of React dominance, something else has happened. We haven’t just built apps with React, we’ve built an entire ecosystem around it—hiring pipelines, design systems, even companies—all bound to its way of thinking.

The problem isn’t React itself, nor any other framework for that matter. The problem is the inertia that sets in once any framework becomes infrastructure. By that point, it’s “too important to fail,” and everything nearby turns out to be just fragile enough to prove it.

The Gravity of Success

React is no longer just a library. It’s a full ecosystem that defines how frontend developers are allowed to think.

Its success has created its own kind of gravity, and the more we’ve built within it, the harder it’s become to break free.

Teams standardize on it because it’s safe: it’s been proven to work at massive scale, the talent pool is large, and the tooling is mature. That’s a rational choice, but it also means React exerts institutional gravity. Moving off it stops being an engineering decision and becomes an organizational risk instead. Solutions to problems tend to be found within its orbit, because stepping outside it feels like drifting into deep space.

We saw this cycle with jQuery in the past, and we’re seeing it again now with React. We’ll see it with whatever comes next. Success breeds standardization, standardization breeds inertia, and inertia convinces us that progress can wait. It’s the pattern itself that’s the problem, not any single framework.

But right now, React sits at the center of this dynamic, and the stakes are far higher than they ever were with jQuery. Entire product lines, architectural decisions, and career paths now depend on React-shaped assumptions. We’ve even started defining developers by their framework: many job listings ask for “React developers” instead of frontend engineers. Even AI coding agents default to React when asked to start a new frontend project, unless deliberately steered elsewhere.

Perhaps the only thing harder than building on a framework is admitting you might need to build without one.

Evolution and Innovation

React’s evolution captures this tension perfectly. Recent milestones include the creation of the React Foundation, the React Compiler reaching v1.0, and new additions in React 19.2 such as the component, `useEffectEvent`, Performance Tracks in DevTools, and experimental and Fragment Refs.

These updates represent tangible improvements. Especially the compiler, which brings automatic memoization at build time, eliminating the need for manual useMemo and useCallback optimization. Production deployments show real performance wins using it: apps in the Meta Quest Store saw up to 2.5x faster interactions as a direct result. This kind of automatic optimization is genuinely valuable work that pushes the entire ecosystem forward.

But here’s the thing: the web platform has been quietly heading in the same direction for years, building many of the same capabilities frameworks have been racing to add.

Browsers now ship View Transitions, Container Queries, and smarter scheduling primitives. The platform keeps evolving at a fair pace, but most teams won’t touch these capabilities until React officially wraps them in a hook or they show up in Next.js docs.

Innovation keeps happening right across the ecosystem, but for many it only becomes “real” once React validates the approach. Which is fine, assuming you enjoy waiting for permission to use the platform you’re already building on.

The React Foundation and the Question of Priorities

The React Foundation represents an important milestone for governance and sustainability. This new foundation is a part of the Linux Foundation, and founding members include Meta, Vercel, Microsoft, Amazon, Expo, Callstack, and Software Mansion.

This is genuinely good for React’s long-term health, providing better governance and removing the risk of being owned by a single company. It ensures React can outlive any one organization’s priorities.

But it doesn’t fundamentally change the development dynamic of the framework. Yet.

The engineers who actually build React still work at companies like Meta and Vercel. The research still happens at that scale, driven by those performance needs. The roadmap still reflects the priorities of the companies that fund full-time development.

And to be fair, React operates at a scale most frameworks will never encounter. Meta serves billions of users through frontends that run on constrained mobile devices around the world, so it needs performance at a level that justifies dedicated research teams. The innovations they produce, including compiler-driven optimization, concurrent rendering, and increasingly fine-grained performance tooling, solve real problems that exist only at that kind of massive scale.

But those priorities aren’t necessarily your priorities, and that’s the tension. React’s innovations are shaped by the problems faced by companies running apps at billions-of-users scale, not necessarily the problems faced by teams building for thousands or millions.

Signals in the Lab: Research at Enterprise Scale

React’s internal research reveals the team’s awareness of current architectural limitations. Experimental projects like Forest explore signal-like lazy computation graphs; essentially fine-grained reactivity instead of React’s coarse re-render model. Another project, Fir, investigates incremental rendering techniques.

These aren’t roadmap items; they’re just research prototypes happening inside Meta. They may never ship publicly. But they do reveal something important: React’s team knows the virtual DOM model has performance ceilings and they’re actively exploring what comes after it.

This is good research, but it also illustrates the same dynamic at play again: that these explorations happen behind the walls of Big Tech, on timelines set by corporate priorities and resource availability. Meanwhile, frameworks like Solid and Qwik have been shipping production-ready fine-grained reactivity for years. Svelte 5 shipped runes in 2024, bringing signals to mainstream adoption.

The gap isn’t technical capability, but rather when the industry feels permission to adopt it. For many teams, that permission only comes once React validates the approach. This is true regardless of who governs the project or what else exists in the ecosystem.

What React Got Right

I don’t want this critique to take away from what React has achieved over the past twelve years.

React popularized declarative UIs and made component-based architecture mainstream, which was a huge deal in itself. It proved that developer experience matters as much as runtime performance and introduced the idea that UI could be a pure function of input props and state. That shift made complex interfaces far easier to reason about. Later additions like hooks solved the earlier class component mess elegantly, and concurrent rendering through `` opened new possibilities for truly responsive UIs.

The React team’s research into compiler optimization, server components, and fine-grained rendering pushes the entire ecosystem forward. This is true even when other frameworks ship similar ideas first. There’s value in seeing how these patterns work at Meta’s scale.

The critique isn’t that React is bad, but that treating any single framework as infrastructure creates blind spots in how we think and build. When React becomes the lens through which we see the web, we stop noticing what the platform itself can already do, and we stop reaching for native solutions because we’re waiting for the framework-approved version to show up first.

And crucially, switching to Solid, Svelte, or Vue wouldn’t eliminate this dynamic; it would only shift its center of gravity. Every framework creates its own orbit of tools, patterns, and dependencies. The goal isn’t to find the “right” framework, but to build applications resilient enough to survive migration to any framework, including those that haven’t been invented yet.

Inertia and Cultural Limitations

This inertia isn’t about laziness; it’s about logistics. Switching stacks is expensive and disruptive. Retraining developers, rebuilding component libraries, and retooling CI pipelines all take time and money, and the payoff is rarely immediate. It’s high risk, high cost, and hard to justify, so most companies stay put, and honestly, who can blame them?

But while we stay put, the platform keeps moving. The browser can stream and hydrate progressively, animate transitions natively, and coordinate rendering work without a framework. Yet most development teams won’t touch those capabilities until they’re built in or officially blessed by the ecosystem.

That isn’t an engineering limitation; it’s a cultural one. We’ve somehow made “works in all browsers” feel riskier than “works in our framework.”

Better governance doesn’t solve this. The problem isn’t React’s organizational structure; it’s our relationship to it. Too many teams wait for React to package and approve platform capabilities before adopting them, even when those same features already exist in browsers today.

The `` Component: Formalization vs. Innovation

React 19.2’s `` component captures this pattern perfectly. It serves as a boundary that hides UI while preserving component state and unmounting effects. When set to mode="hidden", it pauses subscriptions, timers, and network requests while keeping form inputs and scroll positions intact. When revealed again by setting mode="visible", those effects remount cleanly.

It’s a genuinely useful feature. Tabbed interfaces, modals, and progressive rendering all benefit from it, and the same idea extends to cases where you want to pre-render content in the background or preserve state as users navigate between views. It integrates smoothly with React’s lifecycle and `` boundaries, enabling selective hydration and smarter rendering strategies.

But it also draws an important line between formalization and innovation.

The core concept isn’t new; it’s simply about pausing side effects while maintaining state. Similar behavior can already be built with visibility observers, effect cleanup, and careful state management patterns. The web platform even provides the primitives for it through tools like IntersectionObserver, DOM state preservation, and manual effect control.

What adds is formalization and coordination with React’s internals. It’s easier to use, harder to misuse, and integrates cleanly with features like. Yet it also exposes how dependent our thinking has become on frameworks. We wait for React to formalize platform behaviors instead of reaching for them directly.

This isn’t a criticism of `` itself; it’s a well-designed API that solves a real problem. But it serves as a reminder that we’ve grown comfortable waiting for framework solutions to problems the platform already lets us solve. After orbiting React for so long, we’ve forgotten what it feels like to build without its pull.

Platform First Thinking

The answer isn’t necessarily to abandon your framework, but to remember that it runs inside the web, not the other way around. I’ve written before about building the web in islands as one way to rediscover platform capabilities we already have.

Even within React’s constraints, you can still think platform first:

Use native forms and form submissions to a server, then enhance with client-side logic
Prefer semantic HTML and ARIA before reaching for component libraries
Try View Transitions directly with minimal React wrappers instead of waiting for an official API
Use Web Components for self-contained widgets that could survive a framework migration
Keep business logic framework-agnostic, plain TypeScript modules rather than hooks, and aim to keep your hooks short by pulling logic from outside React
Profile performance using browser DevTools first and React DevTools second
Try native CSS features like :has(), @layer, scroll snap, @container, and prefers-reduced-motion before adding JavaScript solutions
Use fetch, FormData, and URLSearchParams instead of framework-specific alternatives wherever possible
Experiment with the History API (pushState, popstate) directly before reaching for React Router
Structure code so routing, data fetching, and state management can be swapped out independently of React
Test against real browser APIs and behaviors, not just framework abstractions

These aren’t anti-React practices, they’re portable practices that make your web app more resilient. They let you adopt new browser capabilities as soon as they ship, not months later when they’re wrapped in a hook. They make framework migration feasible rather than catastrophic.

When you build this way, React becomes a rendering library that happens to be excellent at its job, not the foundation everything else has to depend on.

Freedom Beyond Frameworks

A React app that respects the platform can outlast React itself.

When you treat React as an implementation detail instead of an identity, your architecture becomes portable. When you embrace progressive enhancement and web semantics, your ideas survive the next framework wave.

The recent wave of changes, including the React Foundation, React Compiler v1.0, the `` component, and internal research into alternative architectures, all represent genuine progress. The React team is doing thoughtful work, but these updates also serve as reminders of how tightly the industry has become coupled to a single ecosystem’s timeline. That timeline is still dictated by the engineering priorities of large corporations, and that remains true regardless of who governs the project.

If your team’s evolution depends on a single framework’s roadmap, you are not steering your product; you are waiting for permission to move.

That is true whether you are using React, Vue, Angular, or Svelte. The framework does not matter; the dependency does. It is ironic that we spent years escaping jQuery’s gravity, only to end up caught in another orbit.

Reclaim the Platform

React was once the radical idea that changed how we build for the web. Every successful framework reaches this point eventually, when it shifts from innovation to institution, from tool to assumption. jQuery did it, React did it, and something else will do it next.

The React Foundation is a positive step for the project’s long-term sustainability, but the next real leap forward will not come from better governance. It will not come from React finally adopting signals either, and it will not come from any single framework “getting it right.”

Progress will come from developers who remember that frameworks are implementation details, not identities.

Build for the platform first.
Choose frameworks second.

The web isn’t React’s, it isn’t Vue’s, and it isn’t Svelte’s. It belongs to no one. If we remember that, it will stay free to evolve at its own pace, drawing the best ideas from everywhere rather than from whichever framework happens to hold the cultural high ground.

Frameworks are scaffolding, not the building. Escaping their gravity does not mean abandoning progress; it means finding enough momentum to keep moving.

Reaching escape velocity, one project at a time.

Fast by Default

Mon, 09 Feb 2026 00:00:00 GMT

After 25 years building sites for global brands, I kept seeing the same pattern appear. A team ships new features, users quietly begin to struggle, and only later do the bug reports start trickling in. Someone finally checks the metrics, panic spreads, and feature development is put on hold so the team can patch problems already affecting thousands of people. The fixes help for a while, but a month later another slowdown appears and the cycle begins again. The team spends much of its time firefighting instead of building.

I call this repeating sequence of ship, complain, panic, patch the Performance Decay Cycle. Sadly, it’s the default state for many teams and it drains morale fast.

There has to be a better way.

When I stepped into tech-lead roles, I started experimenting. What if performance was something we protected from the start rather than something we cleaned up afterward? What if the entire team shared responsibility instead of relying on a single performance-minded engineer to swoop in and fix things? And what if the system itself made performance visible early, long before issues hit production?

Across several teams and many iterations, a different pattern began to emerge. I now call it Fast by Default.

Fast by Default is the practice of embedding performance into every stage of development so speed becomes the natural outcome, not a late rescue mission. It involves everyone in the team, not just engineers.

Fixing It Later Never Works

Most organizations treat performance as something to address when it hurts, or they schedule a bug-fix sprint every few months. Both approaches are expensive, unreliable, and almost always too late.

By the time a slowdown is noticeable, the causes are already baked into the rendering strategy, the data-fetching sequence, and the component boundaries. These decisions define a ceiling on how fast your system can ever be. You can tune within that ceiling, but without a rebuild, you can’t break through it.

Meanwhile, the baseline slowly drifts. Slow builds and sluggish interactions become expected. What felt unacceptable in week 1 feels normal by month 6.

And once a feature ships, the attention shifts. Performance work competes with new ideas and roadmap pressure. Most teams never return to clean things up.

How Performance Problems Grow

Performance regressions rarely announce themselves through one dramatic failure. They accumulate quietly, through dozens of reasonable decisions.

A feature adds a little more JavaScript, a new dependency brings a hidden transitive load, and a design tweak introduces layout movement. A single page load still feels fine, but interactions begin to feel heavier. More features are added, more code ships, and slowly the slow path becomes the normal path.

It shows up most clearly at the dependency level:

// Looks harmless enough...

// ...but 6 months later the bundle is 2MB and nobody remembers why

Each import made sense in isolation and passed through code review. No single decision broke the experience; the combination did.

This is why prevention always beats the cure.

The Shift In Thinking

If you want to avoid returning to a culture of whack-a-mole fixes, you need to change the incentives so fast outcomes happen naturally.

The core idea is simple: make the fast path easier than the slow path.

Once you do that, performance stops depending on vigilance or heroics. You create systems and workflows that quietly pull the team toward fast decisions without friction.

Here’s what this looks like day-to-day:

Architecture choices should raise the performance ceiling

If your starting point is a client-rendered SPA, you’re already fighting uphill. Server-first rendering with selective hydration (often called the Islands Architecture) gives you a performance margin that doesn’t require constant micro-optimization to maintain. It also helps clarify how much of your SPA truly needs to be a SPA.

Tooling should make performance visible during development

When dependency size appears directly in your IDE, bundle size and budget checks run automatically in CI, and hydration warnings surface in local development, developers see the cost of their changes immediately and fix issues while the context is still fresh.

Defaults should favor lightweight choices

Reaching for utility-first libraries, choosing smaller dependencies, and cultivating a culture where the first question is "do we need this?" rather than "why not?" keeps complexity from compounding.

Code review should act as a guardrail

When reviewers consistently ask how a change affects render time or memory pressure, the entire team levels up. The question becomes part of the craft rather than an afterthought, and eventually it appears in every pull request.

Shared Responsibility, Not Specialists

Teams that stay fast don’t succeed because they have more performance experts; they succeed because they distribute ownership.

Designers think about layout stability, product managers scope work with speed in mind, and engineers treat performance budgets as part of correctness rather than a separate concern. Everyone understands that shipping fast code is as important as shipping correct code.

For this to work, regressions need to surface early. That requires continuous measurement, clear ownership, and tooling that highlights problems before users do. Once the system pulls in the right direction with minimal resistance, performance becomes self-sustaining.

The Compounding Effect

A team with fast defaults ships fast software in month 1, and they’re still shipping fast software in month 12 and month 36 because small advantages accumulate in their favor.

A team living in the Performance Decay Cycle may start with acceptable performance, but by month 12 they find themselves planning a dedicated performance sprint, and by month 36 they’re discussing a rewrite.

The difference isn’t expertise or effort; it’s the approach they started from.

Speed is leverage because it builds trust, sharpens design, and accelerates development. Once you lose it, you lose more than seconds: you lose users, revenue, and confidence in your own system.

Fast by Default is how teams break this cycle and build systems that stay fast as they grow.

For more on this model, see https://fastbydefault.com.

<small>This article was first published on 4 December 2025 at https://calendar.perfplanet.com/2025/fast-by-default/</small>

Hacking Layout Before CSS Even Existed

Wed, 11 Jun 2025 13:00:00 GMT

Before flex, before grid, even before float, we still had to lay out web pages.

Not just basic scaffolding, full designs. Carefully crafted interfaces with precise alignment, overlapping layers, and brand-driven visuals. But in the early days of the web, HTML wasn’t built for layout. CSS was either brand-new or barely supported. Positioning was unreliable. Browser behavior was inconsistent.

And yet, somehow, we made it work.

So how did we lay out the web?

With tables.
Yup. Tables.

Not the kind used for tabular data. These were layout tables, deeply nested, stretched and tweaked, often stuffed with invisible spacer GIFs to push elements into place. Text, links, and buttons were dropped into cells and floated among a scaffolding of invisible structure.

If you were building websites in the late ’90s or early 2000s, this will sound familiar. If not, consider this a quick trip back to one of the more creatively chaotic eras of frontend development, and what it can still teach us today.

HTML wasn’t made for layout

HTML began as a way to mark up academic documents. Headings, paragraphs, links, lists, that was about it. There was no real concept of “layout” in the design sense. Early browsers had little support for positioning or styling beyond font tweaks and basic alignment.

But developers still wanted structure. And clients, especially as the web grew more mainstream, wanted their brands to show up consistently. They expected full visual treatments: custom type, precise alignment, multi-column layouts, and logos in exactly the right place. Designs weren’t just documents, they were meant to look like something. Often like print. Often pixel-perfect.

So we did what developers always do: we got creative.

Enter the layout table

HTML tables gave us something no other element did at the time: control. You could create rows and columns. You could define cell widths and heights. You could nest tables inside tables to carve up the page into zones. That control was intoxicating.

It wasn’t elegant. It definitely wasn’t semantic. But it worked.

<table width="100%" cellpadding="0" cellspacing="0">
  <tr>
    <td width="200">
      <img src="spacer.gif" width="200" height="1" alt="">
    </td>
    <td>
      Main content goes here
    </td>
  </tr>
</table>

Spacer GIFs like the one above were a standard trick. You’d create a 1×1 pixel transparent image, then stretch it using width and height attributes to force the browser to reserve space. There were entire toolkits built to generate spacer-driven layouts automatically.

If you wanted padding, you’d nest another table. For alignment, you’d add empty cells or tweak the align attribute. And when that wasn’t enough, you’d resort to comment-tag hacks or browser-specific rendering quirks just to make things behave.

Slicing designs into the web

At agencies like AKQA, where I worked at the time, the designs weren’t simple page frames. They were fully realized compositions, often with custom art direction, background textures, and layered effects. We’d receive static visuals, usually Photoshop files, and break them apart manually into dozens of individual image slices.

Some slices were background textures. Some were visual foreground elements: shadows, corners, borders, custom typography before @font-face existed. Then we’d reassemble everything with HTML tables, mixing sliced images with live HTML, real text, buttons, form inputs, to recreate the original design as closely as browsers would allow.

It was part engineering, part pixel-pushing, part dark art.

Why we did it anyway

It’s easy to laugh now, but back then layout tables gave us something CSS didn’t: predictability.

CSS support was spotty. Browsers implemented it inconsistently. You could spend hours tweaking styles, only to have them break in IE5.5. Tables weren’t perfect, but they rendered the same almost everywhere.

WYSIWYG tools like Dreamweaver leaned hard into the table model. You’d drag content into cells and it would spit out layers of nested HTML you weren’t really meant to touch.

Was it bloated? Yes. Fragile? Absolutely. But it shipped.

The long road to modern CSS

CSS1 arrived in 1996. CSS2 in 1998 brought position: absolute, float, and z-index. But it took years for browsers to catch up, and even longer for developers to trust it.

The table era didn’t really end until the mid-2000s, when modern browsers matured and CSS layout finally became viable. Even then, it took time for the idea of separation of concerns to take hold: structure in HTML, style in CSS, behavior in JavaScript.

Today: grid systems, not grid hacks

Now we have display: grid and display: flex. We can align elements without nesting. We can reorder content for accessibility. We can build responsive layouts without a single spacer GIF in sight.

What used to take 100 lines of messy table markup now takes 10 lines of clean, declarative CSS. It’s better for developers, and for users, especially those using assistive tech that struggled to parse table-based scaffolding.

What the table era still teaches us

A few lessons from the layout table era still hold true:

Cross-browser consistency matters. Even now, not everything renders the same. Test broadly.
You’ll always work with constraints. Back then it was no CSS. Today it might be legacy code, team skills, or framework limitations. Creativity under constraint is part of the job.
Understand the tools you’re misusing. Tables weren’t designed for layout, but we understood them deeply. That same mindset helps today when bending modern tools to fit the real world.

In closing

Table-based layouts were a workaround. But they also reflect something constant about web development: we’re always adapting. Always hacking. Always building better experiences with the tools we have, until the next set of tools comes along.

So next time you float a div or write a neat little grid template, give a small nod to the table layouts that walked so Flexbox could run.

HTML’s Best Kept Secret: The <output> Tag

Wed, 01 Oct 2025 00:00:00 GMT

Every developer knows <input>. It’s the workhorse of the web.

But <output>? Most have never touched it. Some don’t even know it exists.

That’s a shame, because it solves something we’ve been cobbling together with <div>s and ARIA for years: dynamic results that are announced to screen readers by default.

It’s been in the spec for years. Yet it’s hiding in plain sight.

Here’s what the HTML5 spec says:

The <output> element represents the result of a calculation performed by the application, or the result of a user action.

It’s mapped to role="status" in the accessibility tree. In plain terms, it announces its value when it changes, as if it already had aria-live="polite" aria-atomic="true".

In practice, that means updates do not interrupt the user. They are read shortly after, and the entire content is spoken rather than just the part that changed. You can override this behavior by setting your own ARIA properties if needed.

Usage is straightforward:

<output>Your dynamic value goes here</output>

That’s it. Built-in assistive technology support. No attributes to memorize. Just HTML doing what it was always meant to do.

My moment of discovery

I discovered <output> on an accessibility project with a multi-step form. The form updated a risk score as fields changed. It looked perfect in the browser, but screen reader users had no idea the score was updating.

Adding an ARIA live region fixed it. But I’ve always believed in reaching for semantic HTML first, and live regions often feel like a patch.

That’s when I scoured the spec and <output> jumped out. It understands forms without requiring one, and it announces its changes natively. Turns out the simplest fix had been in the spec all along.

So why don’t we use it?

Because we forgot. It’s not covered in most tutorials. It doesn’t look flashy. When I searched GitHub public repos, it barely showed up at all.

It gets overlooked in patterns and component libraries too. That absence creates a feedback loop: if no one teaches it, no one uses it.

A few things to know

Like <label>, <output> has a for="" attribute. Here you list the ids of any <input> elements the result depends on, separated by spaces:

<input id="a" type="number"> +
<input id="b" type="number"> =
<output for="a b"></output>

For most users, nothing changes visually. But in the accessibility tree it creates a semantic link, letting assistive technology users connect the inputs with their calculated result.

It doesn’t require a <form> either. You can use it anywhere you are updating dynamic text on the page based on the user’s input.

By default <output> is inline, so you’ll usually want to style it for your layout, just as you would a <span> or <div>.

And because it has been part of the spec since 2008, support is excellent across browsers and screen readers. It also plays nicely with any JavaScript framework you might be using, like React or Vue.

Update 7 Oct 2025: Some screen readers have been found not to announce updates to the tag, so explicitly emphasising the role attribute might be worthwhile for now until support improves: <output role="status">.

One thing to note: <output> is for results tied to user inputs and actions, not global notifications like toast messages. Those are better handled with role="status" or role="alert" on a generic element, since they represent system feedback rather than calculated output.

So what does this look like in practice?

Real world examples

I’ve personally reached for <output> in multiple real-world projects since discovering it:

Simple calculator app

During a recent 20-minute coding challenge, I used <output> to display calculation results. Without adding a single ARIA role, the screen reader announced each result as it updated. No hacks required.

Range slider formatting

At Volvo Cars, we displayed user-friendly versions of slider values. Internally the slider might hold 10000, but the output showed 10,000 miles/year. We wrapped the slider and <output> in a container with role="group" and a shared label, creating a cohesive React component:

<div role="group" aria-labelledby="mileage-label">
  <label id="mileage-label" htmlFor="mileage">
    Annual mileage
  </label>
  <input
    id="mileage"
    name="mileage"
    type="range"
    value={mileage}
    onChange={(e) => setMileage(Number(e.target.value))}
  />
  <output name="formattedMileage" htmlFor="mileage">
    {mileage.toLocaleString()} miles/year
  </output>
</div>

Form validation feedback

I found that password strength indicators and real-time validation messages work beautifully with <output>.

<label for="password">Password</label>
<input type="password" id="password" name="password">
<output for="password">
  Password strength: Strong
</output>

Server-calculated output? No problem.

The <output> tag even fits modern patterns where you might fetch prices from APIs, show tax calculations, or display server-generated recommendations.

Here, a shipping cost calculator updates an <output> tag, informing users once the cost has been calculated:


  const [weight, setWeight] = useState("");
  const [price, setPrice] = useState("");

  useEffect(() => {
    if (weight) {
      // Fetch shipping price from server based on package weight
      fetch(`/api/shipping?weight=${weight}`)
        .then((res) => res.json())
        .then((data) => setPrice(data.price));
    }
  }, [weight]);

  return (
    <form>
      <label>
        Package weight (kg):
        <input
          type="number"
          name="weight"
          value={weight}
          onChange={(e) => setWeight(e.target.value)}
        />
      </label>
      
      <output name="price" htmlFor="weight">
        {price ? `Estimated shipping: $${price}` : "Calculating..."}
      </output>
    </form>
  );
}

Satisfaction guaranteed

There’s something satisfying about using a native HTML element for what it was designed for, especially when it makes your UI more accessible with less code.

<output> might be HTML’s best kept secret, and discovering gems like this shows how much value is still hiding in the spec.

Sometimes the best tool for the job is the one you didn’t even know you had.

Update 11 Oct 2025: The ever-excellent Bob Rudis has produced a working example page to support this post. Find it here: https://rud.is/drop/output.html

The Design-Minded Engineer

Tue, 28 Apr 2026 00:00:00 GMT

In 2002, I was a few weeks into a new role, my second since completing my degree two years earlier. I was a frontend engineer at AKQA, a creative agency in London. I’d just finished one of my first projects, building out a new page for a client, and I thought it looked great. So I told the designer it was done.

A while later, I heard him in the engineering room. Den? Where’s Den? He came over to my desk and opened Photoshop. He placed a screenshot of my build on one layer and his original design on another, dropped the opacity to 50%, and let me see the difference for myself.

Everything was off. Spacing, alignment, type rendering, visual weight. Not by miles, but by enough. Enough that the thing I’d built felt different from the thing he’d designed, even though I’d have sworn they were identical.

I was embarrassed. I was so sure it was done.

Something rewired in my brain that day. Not a new skill, exactly, but a new way of seeing. I had started to become an engineer who could see what I’d built through the eyes of the designer, not just through my own.

The gap between what designers intend and what engineers ship is one of the oldest problems in our industry, and it has defined my career since that day. I’ve come to believe it’s the most undervalued skill in software engineering.

The gap is real, and it’s everywhere

Brian Lovin, currently at Notion, wrote recently about the difficulty of hiring what he called “design-minded frontend engineers.” The struggle he describes is widely shared. There are engineers who can code, and there are designers who can design, but the engineers who can honor design intent while building the real product? That pool is vanishingly small.

Lovin’s framing was about frontend engineers specifically, but the gap he’s describing isn’t a web problem; it’s a general UI problem. Mobile engineers ship apps that drift from their designs. Embedded engineers build interfaces for cars, appliances, ATMs, point-of-sale terminals, and medical devices where a misjudged tap target has real-world consequences. Anywhere a human touches software, someone has to close the space between what was designed and what gets built, and that someone is an engineer regardless of what platform they work on.

What’s striking about this gap is how much has been written about it already, and how little has changed. Designers have been naming the problem for years: posts about engineers breaking their designs, articles about the handoff process, and conference talks about the collaboration breakdown. The designer’s perspective on this is a well-established literature. But that literature is written by designers, for designers, and no amount of designers talking to each other about the problem has fixed it, because fixing it was never something designers could do alone. The engineer is the other half of the conversation, and the engineer is the half that has to change.

And here’s the thing: this isn’t a new problem that appeared with the rise of design systems or component libraries. It’s been there since the first time a designer handed a mockup to an engineer and got something back that felt almost right but not quite. The gap between the mockup and the shipped product is an engineering problem, and it’s a problem with a solution. The skills required to close it can be taught.

Defining “design-minded”

The thing to understand about design is that it isn’t the mockup, it’s the experience the person has when they’re using the shipped product. That experience is built by engineers from what designers describe and intend. The mockup is a promise, the feel is what actually ships.

One distinction is the Design Engineer. This is someone who occupies a hybrid role: they design and they build. Matthias Ott has written persuasively about design engineering as the structural fix for the design-implementation gap: a role that holds both disciplines at once and makes the gap stop forming in the first place. Companies like Linear and Vercel have made the role famous, and I’m in awe of the people doing it; they are genuinely talented at both sides.

But it’s also a luxury solution. Most companies can’t hire for it, and even at companies that do, many design engineers typically focus on design systems or high-fidelity components. Somebody still has to take those components and build the actual product with care.

Ott’s prescription is a role; mine is a capability. Think of it as the democratized version: a design engineer for the rest of us. The role is valuable where companies can hire for it and that extra level of fidelity is required, but the capability is what scales to everyone else building user-facing software.

That somebody is the design-minded engineer. That’s not a new job title; it’s a way of working, of engineering, of caring about how the product looks and feels.

A design-minded engineer is not a designer, and their task is not to originate design decisions but to apply and extrapolate them. The goal is for the designer to look at the shipped product and not be able to tell where their design file ended and the engineer’s judgment began. The highest compliment a design-minded engineer can receive is silence from the designer, because silence means you got it right.

This isn’t about engineers becoming designers either. Designers should still design, and engineers still build. But the engineer who builds with design judgment ships a different product than the engineer who builds without it.

Apply and extrapolate, don’t originate. That’s design-minded engineering.

The framework: three lenses on every design

Over the course of my career, from agency work at AKQA for Nike and Ferrari, to global e-commerce at Volvo, to my accessibility and animation work at Canva, I’ve developed a framework for how engineers should engage with design. It comes down to three lenses:

1. User behavior.
What will people actually do with this? Not what the mockup assumes, but what happens in real conditions. The designer typically designs for one user in one ideal state, while the engineer knows that localized strings reshape layouts in ways the original mockup didn’t account for, that right-to-left languages flip everything, that users will hit this screen on a train with one bar of signal halfway through a checkout flow. The design-minded engineer sees those realities and addresses them before they become bugs.

2. Performance.
What’s the hidden cost the user pays that the mockup can’t show? A prototype can promise buttery smooth interactions, but if the shipped product has 80ms input latency instead of 16ms, users feel the difference even if they can’t articulate it. Samsung famously copied Apple’s pinch-to-zoom gesture, matching the visual design almost exactly, but the interaction felt wrong because the engineering underneath didn’t match the design promise. Performance is a design decision, and engineers are the only ones who can make it real.

3. Accessibility.
Who gets excluded? This is the most defensible concern you can raise in any design review, and it’s the one most often deferred. Accessibility isn’t a compliance checkbox but a signal of engineering quality, and more than that, a signal of care. Passing WCAG scores while the actual screen reader experience is incomprehensible doesn’t count. Turning on VoiceOver and navigating your own product with different input types does.

These three lenses aren’t reasons to block work or push back on designers; they’re the opposite. They’re how an engineer earns a seat at the design table, by caring about design outcomes through a lens that designers recognize and respect.

The engineer as a creative contributor

Design-minded engineering isn’t only analytical, though. There’s a whole dimension that’s about creative contribution.

Engineers know things designers don’t, because the two disciplines have different vantage points. When CSS container queries landed, or view transitions went from spec to stable, or SwiftUI’s animation APIs opened up new motion possibilities on iOS, those weren’t just engineering milestones. They were creative unlocks. Each expanded what was possible in a user interface, and engineers saw the new ground first.

At AKQA, I worked on a Ferrari project not long after CSS got the cubic-bezier() function for custom easing curves. We built a dropdown menu with easing curves derived from actual race car telemetry data. It was the kind of contribution that only happens when an engineer is in the room during the creative conversation, feeding into it, not waiting downstream for a handoff.

The designer is constrained by what they think is possible, and the design-minded engineer knows what actually is. Stay current with new platform capabilities. You’ll have options to bring to every brainstorm, and the team designs something they couldn’t have designed without you.

The undesigned states

If there’s a single idea in this framework that I think resonates most immediately with working engineers, it’s gap states.

Every mockup shows the happy path. The page loaded, the data arrived, the user is logged in, the content fits perfectly. But shipped products have to account for loading states, error states, empty states, skeleton screens, offline fallbacks, optimistic updates, expired sessions, permission denials, locale-specific edge cases, and a dozen other conditions that never appeared in any design file.

These aren’t afterthoughts, they are the product for a significant percentage of real user sessions. The engineer who treats them as first-class design problems, who asks “what does this screen look like with no data?” before leaving the design review, is doing design-minded engineering. The craft applied to these in-between moments is what separates products that feel polished from products that feel like they were built from a mockup and nothing else.

Sometimes there is no design

Everything I’ve described so far assumes a design exists. But what happens when it doesn’t?

This is where design-minded engineering faces its real exam. Every engineer eventually encounters a situation where they need to build something with incomplete or absent design direction: a feature that needs shipping before the designer can get to it, a prototype built from raw data and business requirements, or a long stretch where the team is between designers.

I’ve lived both extremes. I’ve been handed raw data and asked to build something that felt intentional with no design input at all. And at Volvo, before a design system existed, I spent six months without my designer, building across 70 markets from data and whatever fragments of earlier design work I could find.

The early weeks were the hardest. You don’t realize how much of your confidence comes from having a design to reference until it’s gone. Every decision that would normally take seconds suddenly has weight. What size should this type be? How much padding feels right here? Is this hierarchy clear, or am I just used to looking at it? There’s no mockup to check against, no designer to ask; just you, the data, and whatever design judgment you’ve accumulated over the years.

What I leaned on was the three lenses. User behavior first: what will real people in real markets actually do with this? I knew German strings would be 40% longer than English, that some markets read right to left, that a checkout flow designed for English speakers in a desktop browser would encounter completely different friction points when a user in Saudi Arabia was navigating it in Arabic on a phone. I knew the edge cases because I’d been cataloging them for years. Performance second: what’s the cost of every decision on the devices our users actually have? Not the specced-out MacBook Pro I was developing on, but the mid-range Android in Jakarta, or the spotty connection in rural Norway. Accessibility third: who gets excluded if I get this wrong?

Those lenses didn’t replace the designer, but they gave me a structure for making principled decisions. Instead of guessing what looked good, I was solving for outcomes I could measure or defend. The visual choices I couldn’t reason about, I kept conservative. I matched existing patterns in the system and extrapolated from what the designer had already established rather than inventing something new.

Exercising restraint is the counterintuitive part. When the designer is gone, the temptation is to fill the creative vacuum, to make the bold call, to prove you can do both jobs. But that’s exactly the wrong instinct. The design-minded engineer’s job in that situation is to make the product feel continuous with the designer’s existing intent, not to introduce a new voice. Every time I reached for a decision I wasn’t sure about, I asked myself: if the designer were here, would this surprise them? If the answer was yes, I pulled back and found a more conservative path. Boring is better than wrong when you’re operating without a net.

When the designer eventually returned and reviewed what I’d built, he requested only minor tweaks. Not “what were you thinking?” Just the micro-level adjustments that separate a designer’s instinct from an engineer’s principled approach.

That outcome is the proof of concept for the entire framework. It’s also an honest illustration of where designer instinct is hardest to replicate: the micro-level decisions about spacing, weight, and proportion that feel obvious only after someone with that instinct points them out. Design-minded engineering can get you remarkably close, but recognizing where “close” falls short is part of the skill.

The familiar anti-patterns

Part of developing design fluency is learning to spot where it went wrong. The industry has no shortage of cautionary tales: Snapchat’s 2018 redesign, the hamburger menu epidemic, dark patterns that optimize for conversion while destroying trust, and recently the rise of AI-generated UI that looks plausible and works incoherently.

The hamburger menu is an instructive example, because it felt like such an elegant engineering solution at the time. Screen space is limited on mobile, navigation takes up room, so you collapse it behind an icon. Problem solved. Except the data kept telling the same story: users don’t open menus they can’t see. Features hidden behind hamburger menus saw dramatically lower engagement than features visible in the interface. The space-saving argument won on logic but lost on human behavior, and the design-minded engineer’s contribution in that room wasn’t to have a better opinion about navigation but to notice that the argument for hiding things needed to account for whether users would ever find them again.

AI makes this urgent

AI is making it easier than ever to generate UI code, and you can prompt your way to a working interface in minutes. That’s exactly why design judgment matters more today than ever.

AI is a powerful tool for design-minded engineers. It can generate locale variants, simulate gap states, produce working prototypes during brainstorms, and catch accessibility issues before the design review. But it can’t evaluate whether the result feels right. It can’t decide whether an animation serves the interaction or just decorates it. It can’t tell you that the loading state your component shows for 200ms on a fast connection will hang for four seconds on a train in rural Portugal.

The risk I see emerging is subtler than “AI will replace designers.” It’s that engineers will start treating AI as a substitute for design judgment. Need a loading state? Ask the model to generate one. Need an error message? Let it write the copy. Need to decide how a component should behave on mobile? Prompt for options and pick the one that looks reasonable. Each individual decision might be fine, but the cumulative effect is an interface that has no point of view, no coherence, no sense that a human being thought carefully about what the person using it actually needs. It’s design by default rather than design by intent.

The design-minded engineer is the counterweight to that drift. They’re the person who looks at the AI-generated output and applies the three lenses: does this serve real user behavior? What’s the performance cost? Who gets left behind? Those questions require human judgment, not better prompts. The execution can be accelerated; the judgment cannot.

Design fluency is a skill, not a talent

I’ve been developing this framework across 25 years in some of the most design-demanding engineering environments in the industry. What I’ve learned is that design fluency isn’t a talent you either have or you don’t. It’s a skill that can be taught, practiced, and developed, and it grows in ways that are hard to see in the moment but obvious in retrospect.

The engineer who starts paying attention to spacing in their first year starts noticing type hierarchy in their third. By year five, they’re catching interaction patterns that don’t match the design intent before the designer does. By year ten, they’re the engineer the designer wants in the room when the hard decisions get made. By year fifteen, they’re the Staff engineer who catches a broken loading state in code review and can articulate exactly why it matters, not just that it looks wrong, but what it does to the user’s trust in the product.

None of that happens overnight, but it starts with a single decision: to care about what you’re building beyond whether it works.

The misalignments I catch now in code review, the edge cases I see before they ship, the interactions I can tell are wrong before anyone else does: none of it would have registered with me in 2002. The AKQA designer with the Photoshop overlay taught me to look. That skill isn’t an innate talent, it’s something any engineer can learn to see for themselves with practice. And the engineers who become design-minded are the ones designers stop having to chase.

The Main Thread Is Not Yours

Thu, 08 Jan 2026 00:00:00 GMT

When a user visits your site or app, their browser dedicates a single thread to running your JavaScript, handling their interactions, and painting what they see on the screen. This is the main thread, and it’s the direct link between your code and the person using it.

As developers, we often use it without considering the end user and their device, which could be anything from a mid-range phone to a high-end gaming rig. We don’t think about the fact that the main thread doesn’t belong to us; it belongs to them.

I’ve watched this mistake get repeated for years: we burn through the user’s main thread budget as if it were free, and then act surprised when the interface feels broken.

Every millisecond you spend executing JavaScript is a millisecond the browser can’t spend responding to a click, updating a scroll position, or acknowledging that the user did just try to type something. When your code runs long, you’re not causing "jank" in some abstract technical sense; you’re ignoring someone who’s trying to talk to you.

Because the main thread can only do one thing at a time, everything else waits while your JavaScript executes: clicks queue up, scrolls freeze, and keystrokes pile up hoping you’ll finish soon. If your code takes 50ms to respond nobody notices, but at 500ms the interface starts feeling sluggish, and after several seconds the browser may offer to kill your page entirely.

Users don’t know why the interface isn’t responding. They don’t see your code executing; they just see a broken experience and blame themselves, then the browser, then you, in that order.

The 200ms You Don’t Own

Browser vendors have spent years studying how humans perceive responsiveness, and the research converged on a threshold: respond to user input within 100ms and the interaction feels instant, push past 200ms and users notice the delay. The industry formalized this as the Interaction to Next Paint (INP) metric, where anything over 200ms is considered poor and now affects your search rankings.

But that 200ms budget isn’t just for your JavaScript. The browser needs time for style calculations, layout, and painting, so your code gets what’s left: maybe 50ms per interaction before things start feeling wrong. That’s your allocation from a resource you don’t own.

The Platform Has Your Back

The web platform has evolved specifically to help you be a better guest on the main thread, and many of these APIs exist because browser engineers got tired of watching developers block the thread unnecessarily.

Web Workers let you run JavaScript in a completely separate thread. Heavy computation, whether parsing large datasets, image processing, or complex calculations, can happen in a Worker without blocking the main thread at all:

// Main thread: delegate work and stay responsive
const worker = new Worker('heavy-lifting.js');

// Send a large dataset from the main thread to the worker
// The worker then processes it in its own thread
worker.postMessage(largeDataset);

// Receive results back and update the UI
worker.onmessage = (e) => updateUI(e.data);

Workers can’t touch the DOM, but that constraint is deliberate since it forces a clean separation between "work" and "interaction."

requestIdleCallback lets you run code only when the browser has nothing better to do. (Due to a WebKit bug, Safari support is still pending at time of writing.) When the user is actively interacting, your callback waits; when things are quiet, your code gets a turn:

requestIdleCallback((deadline) => {

  // Process your tasks from a queue you created earlier
  // deadline.timeRemaining() tells you how much time you have left
  while (tasks.length && deadline.timeRemaining() > 0) {
    processTask(tasks.shift());
  }

  // If there are tasks left, schedule another idle callback to complete later
  if (tasks.length) requestIdleCallback(processRemainingTasks);
});

This is ideal for non-urgent work like analytics, pre-fetching, or background updates.

isInputPending (Chromium-only for now) is perhaps the most user-respecting API of the lot, because it lets you check mid-task whether someone is waiting for you:

function processChunk(items) {

  // Process items from a queue one at a time
  while (items.length) {
    processItem(items.shift());

    // Check if there’s pending input from the user
    if (navigator.scheduling?.isInputPending()) {

      // Yield to the main thread to handle user input,
      // then resume processing after
      setTimeout(() => processChunk(items), 0);

      // Stop processing for now
      return;
    }
  }
}

You’re explicitly asking "is someone trying to get my attention?" and if the answer is yes, you stop and let them.

The Subtle Offenders

The obvious main thread crimes like infinite loops or rendering 100,000 table rows are easy to spot, but the subtle ones look harmless.

Calling JSON.parse(), for example, on a large API response blocks the main thread until parsing completes, and while this feels instant on a developer’s machine, a mid-range phone with a throttled CPU and competing browser tabs might take 300ms to finish the same operation, ignoring the user’s interactions the whole time.

The main thread doesn’t degrade gracefully; it’s either responsive or it isn’t, and your users are running your code in conditions you’ve probably never tested.

Measure What You Spend

You can’t manage what you can’t measure, and Chrome DevTools’ Performance panel shows exactly where your main thread time goes if you know where to look. Find the "Main" track and watch for long yellow blocks of JavaScript execution. Tasks exceeding 50ms get flagged with red shading to mark the overtime portion. Use the Insights pane to surface these automatically if you prefer a guided approach. For more precise instrumentation, the performance.measure() API lets you time specific operations in your own code:

// Mark the start of a heavy operation
performance.mark('parse-start');

// The operation you want to measure
const data = JSON.parse(hugePayload);

// Mark the end of the operation
performance.mark('parse-end');

// Name the measurement for later analysis
performance.measure('json-parse', 'parse-start', 'parse-end');

The Web Vitals library can capture INP scores from real users across all major browsers in production, and when you see spikes you’ll know where to start investigating.

The Framework Tax

Before your application code runs a single line, your framework has already spent some of the user’s main thread budget on initialization, hydration, and virtual DOM reconciliation.

This isn’t an argument against frameworks so much as an argument for understanding what you’re spending. A framework that costs 200ms to hydrate has consumed four times your per-interaction budget before you’ve done anything, and that needs to be a conscious choice you’re making, rather than an accident.

Some frameworks have started taking this seriously: Qwik’s "resumability" avoids hydration entirely, while React’s concurrent features let rendering yield to user input. These are all responses to the same fundamental constraint, which is that the main thread is finite and we’ve been spending it carelessly.

Borrow, Don’t Take

The technical solutions matter, but they follow from a shift in perspective, and when I finally internalized that the main thread belongs to the user, not to me, my own decisions started to change.

Performance stops being about how fast your code executes and starts being about how responsive the interface stays while your code executes. Blocking the main thread stops being an implementation detail and starts feeling like taking something that isn’t yours.

The browser gave us a single thread of execution, and it gave our users that same thread for interacting with what we built. The least we can do is share it fairly.

Want to Be a Better Frontend Engineer? Try a Week On-Call

Wed, 04 Jun 2025 13:00:00 GMT

You’re going to hate me for saying this, but I actually like being on-call.
I know. I know. But hear me out.
Obviously not the part where PagerDuty yanks you out of a dream with your heart pounding.
But on-call taught me more about frontend quality than any bug tracker ever did.

It was 2:43 AM.
A customer couldn’t click through to checkout.
Revenue was on the line.
And the alert came to me.

The root cause wasn’t in the frontend. A backend job had failed quietly, returning malformed data. But to the user, the result was simple: the button didn’t work. And when you’re on-call for the frontend, you’re the one who has to respond, no matter where the problem starts.

On-Call Sharpens What You Already Care About

I’ve always cared about quality.
I’ve written tests, chased down edge cases, and treated polish as part of the craft.
But on-call changes how you think about all of it.

It’s not just about whether your code works.
It’s about how it fails.
It’s about how quickly it can be understood under pressure.
It’s about whether your interface can recover from issues far outside your control.

The Frontend Catches Everything

When something fails in the system, the user usually sees it in the frontend.
If a service goes down, your component gets no data.
If a token expires, the user gets stuck.
If a third-party script blocks rendering, your buttons stop working.
If checkout breaks, your app takes the blame.

You may not control the systems upstream, but on-call teaches you that you still own the experience.

You Start Building for Real-World Failure

On-call shifts your habits.

You write clearer loading states.
You handle empty, broken, or missing data.
You stop assuming things will behave.
You add useful logs. A lot of them.
You recover from failure instead of hiding from it.

You stop writing code that works in theory.
You start writing code that holds up at 2 AM.

You begin asking better questions:

What happens if this API returns nothing?
What if the feature flag system is down?
Will this UI leave the user stranded if it doesn’t render properly?

You Build Like You’re the One Who’ll Be Paged

Because you might be.

On-call brings accountability.
You stop cutting corners you know might break later.
You stop leaving vague TODOs for someone else.
You stop letting “it works on my machine” be the final word.

A single week of on-call teaches you what months of bug triage can’t.
It shows you what real-world pressure feels like, and how it exposes every weak spot in your stack.

And once you’ve lived through that, you start building differently.
You start building better.

We Keep Reinventing CSS, but Styling Was Never the Problem

Wed, 06 Aug 2025 13:00:00 GMT

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.

CSS Wasn’t Made for This

It’s easy to forget what CSS was originally designed for: documents. You’d write some HTML, style a few headings and paragraphs, maybe float an image to the left, and call it a day. In that world, global styles made sense. The cascade was helpful. Inheritance was elegant.

Fast-forward a couple of decades and we’re building highly interactive, component-based, state-driven, design-system-heavy applications, still with a language meant to style a résumé in the early 2000s.

CSS wasn’t built for encapsulated components. It wasn’t built for dynamic theming or runtime configuration or hydration mismatches. So we’ve spent years bolting on strategies to make it work.

Every Option Solves One Problem. None Solve All of Them.

What we have now is a landscape of trade-offs.

BEM gives you naming predictability, and very verbose selectors.
CSS Modules give you scoping, unless you need runtime theming.
Utility-first CSS (like Tailwind) enables fast iteration, but clutters your markup.
CSS-in-JS offers colocation and flexibility, at the cost of runtime performance and complexity.
Cascade Layers and :where() give you more control, if your team is ready to learn them.

Each approach solves something. None solve everything. Yet we keep framing them as silver bullets, not as trade-off tools.

Maybe It’s Not CSS That’s the Problem

Here’s the uncomfortable truth: most of our styling pain doesn’t come from CSS itself.
It comes from trying to shoehorn CSS into frontend architectures that weren’t designed to support it.

React, Vue, Svelte. They all put components at the core. Scoped logic. Scoped templates. Scoped state. Then we hand them a stylesheet that’s global, cascading, and inherited by default.

We’ve spent the last decade asking CSS to behave like a module system. It isn’t one.

The Real Question: Which Pain Are You Willing to Accept?

This isn’t just a tooling choice.
It’s a question of what trade-offs you’re prepared to live with.

Do you want:

Scoped styles with minimal tooling? Use CSS Modules and accept limited runtime flexibility.
Predictability and no cascade? Use utility-first CSS and brace for cluttered markup.
Dynamic styles colocated with logic? Use CSS-in-JS and monitor your bundle size closely.

There’s no single solution. Just strategies. Just context.

Accept the Mess. Choose With Your Eyes Open.

Styling the web isn’t solved. It may never be. But it gets easier when we stop pretending there’s a perfect answer just one abstraction away.

Be clear about what matters, and deliberate about what you’re willing to trade.

Because at the end of the day, no one writes perfect CSS.
Just CSS that’s good enough to ship.

You're Looking at the Wrong Pretext Demo

Mon, 30 Mar 2026 00:00:00 GMT

Pretext, a new JavaScript library from Cheng Lou, crossed 7,000 GitHub stars in its first three days. If you've been anywhere near the frontend engineering circles in that time, you've seen the demos: a dragon that parts text like water, fluid smoke rendered as typographic ASCII, a wireframe torus drawn through a character grid, multi-column editorial layouts with animated orbs displacing text at 60fps. These are visually stunning and they're why the library went viral.

But they aren't the reason this library matters.

The important thing Pretext does is predict the height of a block of text without ever reading from the DOM. This means you can position text nodes without triggering a single layout recalculation. The text stays in the DOM, so screen readers can read it and users can select it, copy it, and translate it. The accessibility tree remains intact, the performance gain is real, and the user experience is preserved for everyone. This is the feature that will change how production web applications handle text, and it's the feature almost nobody is demonstrating.

The community has spent three days building dragons. It should be building chat interfaces. And the fact that the dragons went viral while the measurement engine went unnoticed tells us something important about how the frontend community evaluates tools: we optimize for what we can see, not for what matters most to the people using what we build.

The Problem Pretext Solves

The problem is forced layout recalculation, where the browser has to pause and re-measure the page layout before it can continue. When a UI component needs to know the height of a block of text, the standard approach is to measure it from the DOM. You call getBoundingClientRect() or read offsetHeight, and the browser synchronously calculates layout to give you an answer. Do this for 500 text blocks in a virtual list and you've forced 500 of these pauses. This pattern, called layout thrashing, remains a leading cause of visual stuttering in complex web applications.

Pretext's insight is that canvas.measureText() uses the same font engine as DOM rendering but operates outside the browser's layout process entirely. Measure a word via canvas, cache the width, and from that point forward layout becomes pure arithmetic: walk cached widths, track running line width, and insert breaks when you exceed the container's maximum. No slow measurement reads, and no synchronous pauses.

The architecture separates this into two phases. prepare() does the expensive work once: normalize whitespace, segment the text using Intl.Segmenter for locale-aware word boundaries, handle bidirectional text (such as mixing English and Arabic), measure segments with canvas, and return a reusable reference. layout() is then pure calculation over cached widths, taking about 0.09ms for a 500-text batch against roughly 19ms for prepare(). Cheng Lou himself calls the 500x comparison "unfair" since it excludes the one-time prepare() cost, but that cost is only paid once and spread across every subsequent call. It runs once when the text appears, and every subsequent resize takes the fast path, where the performance boost is real and substantial.

The core idea traces back to Sebastian Markbåge's research at Meta, where Cheng Lou implemented the earlier text-layout prototype that proved canvas font metrics could substitute for DOM measurement. Pretext builds on that foundation with production-grade internationalization, bidirectional text support, and the two-phase architecture that makes the fast path so fast. Lou has a track record here: react-motion and ReasonML both followed the same pattern of identifying a constraint everyone accepted as given and removing it with a better abstraction.

The Measurement Breakthrough

The first use case Pretext serves, and the one I want to make the case for, is measuring text height so you can render DOM text nodes in exactly the right position without ever asking the browser how tall they are. This isn't a compromise path, it's the most capable thing the library does.

Consider a virtual scrolling list of 500 chat messages. To render only the visible ones, you need to know each message's height before it enters the viewport. The traditional approach is to insert the text into the DOM, measure it, and then position it, paying the layout cost for every message. Pretext lets you predict the height mathematically and then render the text node at the right position. The text itself still lives in the DOM, so the accessibility model, selection behavior, and find-in-page all work exactly as they would with any other text node.

Here's what that looks like in practice:

const prepared = prepare(message.text, '16px Inter');
const { height } = layout(prepared, containerWidth, 24);

Two function calls: the first measures and caches, the second predicts height through calculation. No layout cost, yet the text you render afterward is a standard DOM node with full accessibility.

The shrinkwrap demo is the clearest example of why this path matters. CSS width: fit-content sizes a container to the widest wrapped line, which wastes space when the last line is short. There's no CSS property that says "find the narrowest width that still wraps to exactly N lines." Pretext's walkLineRanges() calculates the optimal width mathematically, and the result is a tighter chat bubble rendered as a standard DOM text node. The performance gain comes from smarter measurement, not from abandoning the DOM. Nothing about the text changes for the end user.

Accordion sections whose heights are calculated from Pretext, and masonry layouts with height prediction instead of DOM reads: these both follow the same model of fast measurement feeding into standard DOM rendering.

There are edge cases worth knowing about, starting with the fact that the prediction is only as accurate as the font metrics available at measurement time, so fonts need to be loaded before prepare() runs or results will drift. Ligatures (where two characters merge into one glyph, like "fi"), advanced font features, and certain CJK composition rules can introduce tiny differences between canvas measurement and DOM rendering. These are solvable problems and the library handles many of them already, but acknowledging them is part of taking the approach seriously rather than treating it as magic.

Canvas Paints Pixels, Not Accessible Text

Pretext also supports manual line layout for rendering to Canvas, SVG, or WebGL. These APIs give you exact line coordinates so you can paint text yourself rather than letting the DOM handle it. This is the path that went viral, and the one that dominates every community showcase.

The canvas demos are impressive and they're doing things the DOM genuinely can't do at 60fps. But they're also painting pixels, and when you paint text as canvas pixels, the browser has no idea those pixels represent language. Screen readers like VoiceOver, NVDA, and JAWS derive their understanding of a page from the accessibility tree, which is itself built from the DOM, so canvas content is invisible to them. Browser find-in-page and translation tools both skip canvas pixels entirely. Native text selection is tied to DOM text nodes and canvas has no equivalent, so users can't select, copy, or navigate the content by keyboard. A <canvas> element is also a single tab stop, meaning keyboard users can't move between individual words or paragraphs within it, even if it contains thousands of words. In short, everything that makes text behave as text rather than an image of text disappears.

None of this means the canvas path is automatically wrong. There are legitimate contexts where canvas text rendering is the right choice: games, data visualizations, creative installations, and design tools that have invested years in building their own accessibility layer on top of canvas. For SVG rendering, the trade-offs are different again, since SVG text elements do participate in the accessibility tree, making it a middle ground between DOM and canvas.

But the canvas path is not the breakthrough, because canvas text rendering has existed for fifteen or more years across dozens of libraries. What none of them offered was a way to predict DOM text layout without paying the layout cost. Pretext's prepare() and layout() do exactly that, and it's genuinely new.

The Wrong Demos Often Go Viral

This pattern often repeats across the frontend ecosystem, and I understand why.

A dragon parting text like water is something you can record as a GIF, post to your socials, and collect thousands of impressions. A virtual scrolling list that pre-calculates text heights looks identical to one that doesn't. The performance difference is substantial but invisible to the eye. Nobody makes a showcase called "works flawlessly with VoiceOver" or "scrolls 10,000 messages without a single forced layout" because these things look like nothing. They look like a web page working the way web pages are supposed to work.

This is Goodhart's Law applied to web performance: once a metric becomes a target, it ceases to be a good measure. Frame rate and layout cost are proxies for "does this work well for users." GitHub stars are a proxy for "is this useful." When the proxy gets optimized instead, in this case by visually impressive demos that happen to use the path with the steepest accessibility trade-offs, the actual signal about what makes the library important gets lost. The library's identity gets set by its most visually impressive feature in the first 72 hours, and the framing becomes "I am drawing things" rather than "I am measuring things faster than anyone has before." Once that framing is set, it's hard to shift.

The best text-editing libraries on the web, CodeMirror, Monaco, and ProseMirror, all made the deliberate choice to stay in the DOM even when leaving it would have been faster, because the accessibility model isn't optional. Pretext's DOM measurement path belongs in that tradition but goes further: those editors still read from the DOM when they need to know how tall something is. Pretext eliminates that step entirely, predicting height through arithmetic before the node is ever rendered. It's the next logical step in the same philosophy: keep text where it belongs, but stop paying the measurement cost to do so.

The Bigger Picture

I've been thinking about performance engineering as a discipline for most of my career, and what strikes me about Pretext is that the real innovation is the one that is hardest to see. Predicting how text will lay out before it reaches the page, while keeping the text in the DOM and preserving everything that makes it accessible, is a genuinely new capability on the web platform. It's the kind of foundational improvement that every complex text-heavy application can adopt immediately.

If you're reaching for Pretext this week, reach for prepare() and layout() first. Build something that keeps text in the DOM and predicts its height without asking the browser. Ship an interface that every user can read, select, search, and navigate. Nobody else has done this yet, and it deserves building.

Performance engineering is at its best when it serves everyone without asking anyone to give something up. Faster frame rates that don't make someone nauseous. Fewer layout pauses that mean a page responds when someone with motor difficulties needs it to. Text that is fast and readable and selectable and translatable and navigable by keyboard and comprehensible to a screen reader.

The dragons are fun. The measurement engine is important. Let's try not to confuse the two.