DEV Community: Den Odell

You're Looking at the Wrong Pretext Demo

Den Odell — Mon, 30 Mar 2026 09:29:00 +0000

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 Markbage'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.

Constraints and the Lost Art of Optimization

Den Odell — Mon, 23 Feb 2026 01:00:00 +0000

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. A "Hello World" React application is 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.

The Main Thread Is Not Yours

Den Odell — Thu, 08 Jan 2026 00:00:00 +0000

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.

Escape Velocity: Break Free from Framework Gravity

Den Odell — Wed, 05 Nov 2025 00:00:00 +0000

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 <Activity /> component, useEffectEvent, Performance Tracks in DevTools, and experimental <ViewTransition /> 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 <Suspense /> 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 `<Activity />` Component: Formalization vs. Innovation

React 19.2’s <Activity /> 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 <Suspense /> 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 <Activity /> adds is formalization and coordination with React’s internals. It’s easier to use, harder to misuse, and integrates cleanly with features like <Suspense />. 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 <Activity /> 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 <Activity /> 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.

HTML’s Best Kept Secret: The Tag

Den Odell — Wed, 01 Oct 2025 00:00:00 +0000

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.

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">.

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.

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:

export function ShippingCalculator() {
  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.

Code Reviews That Actually Improve Frontend Quality

Den Odell — Wed, 20 Aug 2025 08:00:00 +0000

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.

We Keep Reinventing CSS, but Styling Was Never the Problem

Den Odell — Wed, 06 Aug 2025 13:00:00 +0000

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.

The Web Is About to Get Better for Everyone, Everywhere

Den Odell — Wed, 23 Jul 2025 13:00:00 +0000

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.

Den Odell — Wed, 09 Jul 2025 10:08:08 +0000

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.

Building the Web in Islands, Not Mountains

Den Odell — Wed, 25 Jun 2025 13:00:00 +0000

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:

<InteractiveRating client:idle />

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.

Hacking Layout Before CSS Even Existed

Den Odell — Wed, 11 Jun 2025 13:00:00 +0000

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.

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

Den Odell — Wed, 04 Jun 2025 12:29:01 +0000

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.