Write Code That Runs in the Browser, or Write Code the Browser Runs
October 27, 2025
I’ve been thinking about a note from Alex Russell where he says:any time you’re running JS on the main thread, you’re at risk of being left behind by progress.The zen of web development is to spend a little time in your own code, and instead to glue the big C++/Rust subsystems together, then get out of the bloody way.
In his thread on Bluesky, Alex continues:How do we do this? Using the declarative systems that connect to those big piles of C++/Rust: CSS for the compositor (including scrolling & animations), HTML parser to build DOM, and for various media, dishing off to the high-level systems in ways that don’t call back into your JS.I keep thinking about this difference:I need to write code that does X.I need to write code that calls a browser API to do X.
There’s a big difference between A) making suggestions for the browser, and B) being its micromanager.Hence the title: you can write code that will run in the browser, or you can write code that calls the browser to run.
Source: Write Code That Runs in the Browser, or Write Code the Browser Runs – Jim Nielsen’s Blog
Back in 2009, I ran a competition at a conference called “No-Bit Sherlock.” The premise was simple: as SVG was gaining browser support, we should minimize—or ideally eliminate—our reliance on bitmap images on the web.
By “bits,” I mean raster graphics. At the time, web pages were littered with images of text, typically saved as JPEGs or PNGs. Illustrations that could have been rendered as vectors were routinely served as bitmaps instead.
While SVG adoption has increased dramatically since then, the unnecessary use of bitmap images remains surprisingly common. It’s become an instinct—a default we reach for without questioning.
So what does this have to do with the article I’m discussing? It’s about instinct too. This piece captures a crucial distinction between two approaches to web development:
One mindset is “write code that does X.” The other is “write code that calls a browser API to do X.”
Is this a difference without a distinction? Absolutely not. These represent fundamentally different philosophies about what we do as front-end engineers. Our instinct should be to understand the browser’s capabilities first, then write the minimal code necessary to leverage them.
Animation illustrates this perfectly. Fifteen to twenty years ago, web animation barely existed beyond hover states. Any movement, appearance, or transformation required JavaScript manipulating DOM properties directly. With JavaScript as our only tool, we blocked the main thread with every animation.
Fast-forward to today. Browsers offer rich built-in animation capabilities we can trigger with JavaScript or even CSS alone, keeping the main thread clear and performance smooth.
View transitions represent the latest iteration—essentially the holy grail. We can now animate page transitions without implementing the animation ourselves. We simply declare what we want, and the browser handles it. The result? High performance, better developer experience, and progressive enhancement. In Firefox (where multi-page view transitions aren’t yet implemented as of October 2025), users simply get traditional page transitions—no breakage, no compromise.
The pattern repeats across features: form validation, layout systems, accessibility features. There’s extensive built-in functionality we can enhance with JavaScript when needed, rather than replacing entirely.
Our job as professional front-end developers is to know the platform’s capabilities and use them fully. The browser will always be orders of magnitude more performant than our custom implementations. But this requires stepping outside the comfort zone of your preferred framework or library to understand the web platform itself—the foundation everything else is built on.
Related Speakers
