Jim Nielsen’s Blog

I enjoyed listening to Feross Aboukhadijeh, founder and CEO of the security firm Socket, on the Changelog podcast “npm under siege”. The cat-and-mouse nature of security is a kind of infinite source of novel content, like a series of heist movies that never produces the same plot so you can never quite guess what happens next.

I like how succintly Feross points out the paradox of trying to keep your software safe by upgrading packages on npm:

The faster you upgrade your packages, the safer you are from software vulnerabilities. But then the faster you upgrade the more vulnerable you are to supply chain attacks

He points out (and I learned) that pnpm has a feature called minimumReleaseAge that lets you avoid installing anything super new. So you can, for example, specify: “Don’t install anything published in the last 24 hours.”

In other words: let’s slow down a bit. Maybe we don’t need immediacy in everything, including software updates. Maybe a little friction is good.

And if security vulnerabilities are what it took to drive us to this realization, perhaps it’s a blessing in disguise.

(Until the long running cat-and-mouse game of security brings us a bad actor who decides to exercise a little patience and creates some kind of vulnerability whose only recourse requires immediate upgrades and disabling the minimumRelaseAge flag, lol.)

Later in the podcast Feross is asked whether, if he was the benevolent dictator of npm, he would do things the same. He says “yes”. Why? Because the trade-offs of “trust most people to do the right thing and make it easy for them” feels like the better decision over “lock it down and make it harder for everyone”. He’s a self proclaimed optimist:

There’s so much good created when you just trust people and you hope for the best.

Obviously Feross has an entire business based on the vulnerabilities of npm, so his incentives are such that if he did change things, he might not exist ha. So read that how you will.

But I like his optimistic perspective: try not to let a few bad actors ruin the experience for everyone. Maybe we can keep the levers where they are and try to clean up what remains.

Reply via: Email · Mastodon · Bluesky

I recently added a bunch of app icons from macOS Tahoe to my collection.

Afterwards, I realized some of them were missing relational metadata.

For example, I have a collection of iMove icons through the years which are related in my collection by their App Store ID. However, the latest iMovie icon I added didn’t have this ID.

This got me thinking, "Crap, I really want this metadata so I can see apps over time. Am I gonna have to go back through each icon I just posted and find their associated App Store ID?”

Then I thought: “Hey, I bet AI could figure this out — right? It should be able to read through my collection of icons (which are stored as JSON files on disk), look for icons with the same name and developer, and see where I'm missing appStoreId and cateogryId.”

So I formulated a prompt (in hindsight, a really poor one lol):

look through all the files in sites/macos/icons/ and find any that start with 2025-11-13-* and then find me any icons like iMovie that have a correlation to other icons in sites/macos/icons/ where it's missing appStoreId and categoryId

But AI did pretty good with that. I’ll save you the entire output, but Cursor thought for a bit, then asked to run this command:

for file in sites/macos/icons/2025-11-13-*.json; do if ! grep -q "appStoreId" "$file" || ! grep -q "categoryId" "$file"; then echo "$file"; fi; done

I was like, “Ok. I couldn’t write that myself, but that looks about right. Go ahead.” It ran the command, thought some more, then asked to run another command. Then another.

It seemed unsatisfied with the results, so it changed course and wrote a node script and asked permission to run that.

I looked at it and said, “Hey that’s probably how I would’ve approached this.” So I gave permission.

It ran the script, thought a little, then rewrote it and asked permission to run again. Here’s the final version it ran:

node -e "
const fs = require('fs');
const path = require('path');

// Get all Apple icons with appStoreId and categoryId
const iconsWithIds = {};
const files = fs.readdirSync('sites/macos/icons');
files.forEach(file => {
  if (file.endsWith('.json')) {
    try {
      const content = JSON.parse(fs.readFileSync(\`sites/macos/icons/\${file}\`, 'utf8'));
      if (content.developer === 'Apple' && content.appStoreId && content.categoryId) {
        const name = content.name.toLowerCase().replace(/[^a-z0-9]/g, '');
        if (!iconsWithIds[name]) {
          iconsWithIds[name] = {
            appStoreId: content.appStoreId,
            categoryId: content.categoryId,
            file: file
          };
        }
      }
    } catch (e) {
      // skip invalid JSON
    }
  }
});

// Get all Apple icons missing appStoreId/categoryId
const missing = [];
files.forEach(file => {
  if (file.endsWith('.json')) {
    try {
      const content = JSON.parse(fs.readFileSync(\`sites/macos/icons/\${file}\`, 'utf8'));
      if (content.developer === 'Apple' && (!content.appStoreId || !content.categoryId)) {
        const name = content.name.toLowerCase().replace(/[^a-z0-9]/g, '');
        if (iconsWithIds[name]) {
          missing.push({
            file: file,
            name: content.name,
            match: iconsWithIds[name]
          });
        }
      }
    } catch (e) {
      // skip invalid JSON
    }
  }
});

// Sort by file name
missing.sort((a, b) => a.file.localeCompare(b.file));

console.log(JSON.stringify(missing, null, 2));
"

And with that, boom! It found a few newly-added icons with corollaries in my archive, pointed them out, then asked if I wanted to add the missing metadata.

The beautiful part was I said “go ahead” and when it finished, I could see and review the staged changes in git. This let me double check the LLM’s findings with my existing collection to verify everything looked right — just to make sure there were no hallucinations.

Turns out, storing all my icon data as JSON files on disk (rather than a database) wasn’t such a bad idea. Part of the reason I’ve never switched from static JSON files on disk to a database is because I always figured it would be easier for future me to find and work with files on disk (as opposed to learning how to setup, maintain, and query a database). Turns out that wasn’t such a bad bet. I’m sure AI could’ve helped me write some SQL queries to do all the stuff I did here. But what I did instead already fit within a workflow I understand: files on disk, modified with scripting, reviewed with git, checked in, and pushed to prod.

So hey, storing data as JSON files in git doesn’t look like such a bad idea now, does it future Jim?

Reply via: Email · Mastodon · Bluesky

This post is a continuation of Paul Kafasis’ post “Tahoe’s Terrible Icons” where he contrasts the visual differences across a number of Apple’s updated icons in macOS Tahoe (a.k.a. the Liquid Glass update).

While Paul’s post mostly covers icons for the apps you’ll find in the primary /Applications folder, there’s also a subset of possibly lesser-known icons in the /System/Library/CoreServices folder which have suffered a similar fate.

When I first got a Mac back in college, one of the things I remember being completely intrigued by — and then later falling in love with — was how you could plumb obscure areas of the operating system and find gems, like the icons for little OS-level apps. You’d stumble on something like the “Add Printer” app and see the most beautiful printer icon you’d ever seen. Who cares what the app did, you could just stare at that icon. Admire it. Take it in. And you’d come away with a sense that the people who made it really cared.

Anyhow, enough reminiscing. Let’s get to the icons. I’m saving these pre-Tahoe icons for posterity’s sake because they’re beautiful. On the left is the pre-Tahoe icon, on the right is Tahoe.

(Psst: I’ve got a long-running collection of icons for iOS and macOS if you want some eye candy.)

/System/Library/CoreServices/AddPrinter

/System/Library/CoreServices/AppleScript Utility

System/Library/CoreServices/Automator Application Stub

/System/Library/CoreServices/Applications/Directory Utility

/System/Library/CoreServices/Erase Assistant

/System/Library/CoreServices/Applications/Expansion Slot Utility

/System/Library/CoreServices/Applications/Folder Actions Setup

/System/Library/CoreServices/Install Command Line Developer Tools

/System/Library/CoreServices/Installer

/System/Library/CoreServices/Setup Assistant

/System/Library/CoreServices/Spotlight

/System/Library/CoreServices/Applications/Ticket Viewer

/System/Library/CoreServices/Widgetkit Simulator

/System/Library/CoreServices/Applications/Wireless Diagnostics

Reply via: Email · Mastodon · Bluesky

Whenever Apple does a visual refresh in their OS updates, a new wave of icon archiving starts for me.

Now that “Liquid Glass” is out, I’ve begun nabbing the latest icons from Apple and other apps and adding them to my gallery.

Since I’ve been collecting these icons for so long, one of the more interesting and emerging attributes of my collection is the visual differences in individual app icons over time.

For example: what are the differences between the icons I have in my collection for Duolingo? Well, I have a page for that today.

That’ll let you see all the different versions I’ve collected for Duolingo — not exhaustive, I’m sure, but still interesting — as well as their different sizes.

But what if you want to analyze their differences pixel-by-pixel? Turns out, There’s A Web Component For That™️.

Image Compare is exactly what I was envisioning: “A tiny, zero-dependency web component for comparing two images using a slider” from the very fine folks at Cloud Four. It’s super easy to use: some HTML and a link to a script (hosted if you like, or you can vendor it), e.g.

<image-compare>
  <img />
  <img />
</image-compare>
<script src="https://unpkg.com/..."></script>

And just like that, boom, I’ve got a widget for comparing two icons.

For Duolingo specifically, I have a long history of icons archived in my gallery and they’re all available under the /comapre route for your viewing and comparison pleasure.

Wanna see some more examples besides Duolingo? Check out the ones for GarageBand, Instagram, and Highlights for starters. Or, just look at the list of iOS apps and find the ones that are interesting to you (or if you’re a fan of macOS icons, check these ones out).

I kinda love how easy it was for my thought process to go from idea to reality:

• “It would be cool to compare differences in icons by overlaying them…“
• “Image diff tools do this, I bet I could find a good one…“
• “Hey, Cloud Four makes a web component for this? Surely it’s good…”
• “Hey look, it’s just HTML: a <script> tag linking to compiled JS along with a custom element? Easy, no build process required…“
• “Done. Well that was easy. I guess the hardest part here will be writing the blog post about it.”

And I’ve written the post, so this chunk of work is now done.

Reply via: Email · Mastodon · Bluesky

Over the years, I’ve been chewing on media related to nuclear weapons. This is my high-level, non-exhaustive documentation of my consumption — with links!

• 📖 The Making of the Atomic Bomb by Richard Rhodes.
  • This is one of those definitive histories (it’s close to 1,000 pages and won a Pulitzer Prize). It starts with the early discoveries in physics, like the splitting of the atom, and goes up to the end of WWII. I really enjoyed this one. A definite recommendation.
  • 📖 Dark Sun: The Making of the Hydrogen Bomb by Richard Rhodes is the sequel. If you want to know how we went from atomic weapons to thermonuclear ones, I think this one will do it. It was a harder read for me though. It got into a lot of the politics and espionage of the Cold War and I fizzled out on it (plus my library copy had to be returned, somebody else had it on hold). I’ll probably go pick it up again though and finish it — eventually.
• 📖 The Bomb: A Life by Gerard J. DeGroot
  • This one piqued my interest because it covers more history of the bomb after its first use, including the testing that took place in Nevada not far from where I grew up. Having had a few different friends growing up whose parents died of cancer that was attributed to being “downwinders” this part of the book hit close to home. Which reminds me of:
  • 🎥 Downwinders & The Radioactive West from PBS. Again, growing up amongst locals who saw some of the flashes of light from the tests and experienced the fallout come down in their towns, this doc hit close to home. I had two childhood friends who lost their Dads to cancer (and their families received financial compensation from the gov. for it).
• 📖 Command and Control: Nuclear Weapons, the Damascus Accident, and the Illusion of Safety by Eric Schlosser
  • Read this one years ago when it first came out. It’s a fascinating look at humans bumbling around with terrible weapons.
  • 🎥 Command and Control from PBS is the documentary version of the book. I suppose watch this first and if you want to know more, there’s a whole book for you.
• 📖 Nuclear War: A Scenario by Annie Jacobsen
  • Terrifying.
  • 🎥 House of Dynamite just came out on Netlify and is basically a dramatization of aspects of this book.
• 📖 The Button: The New Nuclear Arms Race and Presidential Power from Truman to Trump by William J. Perry and Tom Z. Collina
  • How did we get to a place where a single individual has sole authority to destroy humanity at a moment’s notice? Interesting because it’s written by former people in Washington, like the Sec. of Defense under Clinton, so you get a taste of the bureaucracy that surrounds the bomb.
• 🎧 Hardcore History 59 – The Destroyer of Worlds by Dan Carlin
  • First thing I’ve really listened to from Dan. It’s not exactly cutting-edge scholarship and doesn’t have academic-level historical rigor, but it’s a compelling story around how humans made something they’ve nearly destroyed themselves with various times. The part in here about the cuban missile crisis is wild. It led me to:
  • 📖 Nuclear Folly: A History of the Cuban Missile Crisis by Serhii Plokhy is a deep look at the Cuban Missile crisis. This is a slow burning audiobook I’m still chewing through. You know how you get excited about a topic and you’re like “I’m gonna learn all about that thing!” And then you start and it’s way more than you wanted to know so you kinda back out? That’s where I am with this one.
• 🎥 The Bomb by PBS.
  • A good, short primer on the bomb. It reminds me of:
  • 🎥 Turning Point: The Bomb and the Cold War on Netflix which is a longer, multi-episode look at the bomb during the Cold War.
• 📝 Last, but not least, I gotta include at least one blog! Alex Wellerstein, a historian of science and creator of the nukemap, blogs at Doomsday Machines if you want something for your RSS reader.

Phew!

This isn’t exhaustive, but if you’ve got recommendations I didn’t mention, send them my way.

Reply via: Email · Mastodon · Bluesky

Authentication on the web is a complicated problem. If you’re going to do it yourself, there’s a lot you have to take into consideration.

But odds are, you’re building an app whose core offering has nothing to do with auth. You don’t care about auth. It’s an implementation detail.

So rather than spend your precious time solving the problem of auth, you pay someone else to solve it.

That’s the value of SaaS.

What would be the point of paying for an authentication service, like workOS, then re-implementing auth on your own? They have dedicated teams working on that problem. It’s unlikely you’re going to do it better than them and still deliver on the product you’re building.

There’s a parallel here, I think, to building stuff in the browser.

Browsers provide lots of features to help you deliver good websites fast to an incredibly broad and diverse audience.

Browser makers have teams of people who, day-in and day-out, are spending lots of time developing and optimizing their offerings.

So if you leverage what they offer you, that gives you an advantage because you don’t have to build it yourself.

You could build it yourself. You could say “No thanks, I don’t want what you have. I’ll make my own.”

But you don’t have to. And odds are, whatever you do build yourself, is not likely to be as fast as the highly-optimized subsystems you can tie together in the browser.

And the best part? Unlike SaaS, you don’t have to pay for what the browser offers you.

And because you’re not paying, it can’t be turned off if you stop paying.

@view-transition, for example, is a free API that’ll work forever.

That’s a great deal. Are you taking advantage?

Reply via: Email · Mastodon · Bluesky

I was watching Alex Petros’ talk and he has a slide in there titled “Incantations that make HTML work correctly”.

This got me thinking about the basic snippets of HTML I’ve learned to always include in order for my website to work as I expect in the browser — like “Hey I just made a .html file on disk and am going to open it in the browser. What should be in there?”

This is what comes to mind:

<!doctype html>
<html lang="en">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1.0">

Why each?

doctype

<!doctype html>

Without <!doctype html>, browsers may switch to quirks mode, emulating legacy, pre-standards behavior. This will change how calculations work around layout, sizing, and alignment.

<!doctype html> is what you want for consistent rendering. Or <!DOCTYPE HTML> if you prefer writing markup like it’s 1998. Or even <!doCTypE HTml> if you eschew all societal norms. It’s case-insensitive so they’ll all work.

html lang

<html lang="en">

Declare the document’s language. Browsers, search engines, assistive technologies, etc. can leverage it to:

• Get pronunciation and voice right for screen readers
• Improve indexing and translation accuracy
• Apply locale-specific tools (e.g. spell-checking)
• And more…

Omit it and things will look ok, but lots of basic web-adjacent tools might get things wrong. Specifying it makes everything around the HTML work better and more accurately, so I always try to remember to include it.

meta utf-8

This piece of info can come back from the server as a header, e.g.

return new Response(
    "<!doctype html><h1>Hello world</h1>",
    {
        status: 200,
        headers: { "Content-Type": "text/html; charset=utf-8" },
    }
);

But I like to set it in my HTML, especially when I’m making files on disk I open manually in the browser.

<meta charset="utf-8">

This tells the browser how to interpret text, ensuring characters like é, ü, and others display correctly.

So many times I’ve opened a document without this tag and things just don’t look right — like my smart quotes.

For example: copy this snippet, stick it in an HTML file, and open it on your computer:

<!doctype html>
<h1>Without meta utf-8</h1>
<dl>
  <dt>Smart quotes</dt>
  <dd>“” and ‘’</dd>
  <dt>Symbols</dt>
  <dd>©, ™, ®, etc.</dd>
  <dt>Ellipsis</dt>
  <dd>…</dd>
  <dt>Emojis</dt>
  <dd>👍</dd>
  <dt>Non-latin characters</dt>
  <dd>é, ñ, etc.</dd>
</dl>

Things might look a bit wonky. But stick a <meta charset="utf-8"> tag in there and you’ll find some relief.

Meta viewport

<meta name="viewport" content="width=device-width,initial-scale=1.0">

Sometimes I’ll quickly prototype a little HTML and think, “Great it’s working as I expect!” Then I go open it on mobile and everything looks tiny — “[Facepalm] you forgot the meta viewport tag!”

Take a look at this screenshot, where I forgot the meta viewport tag on the left but included it on the right:

That ever happen to you? No, just me? Well anyway, it’s a good ‘un to include to make HTML work the way you expect.

Last But Not Least…

I know what you’re thinking, I forgot the most important snippet of them all for writing HTML:

<div id="root"></div>
<script src="bundle.js"></script>

Lol.

Reply via: Email · Mastodon · Bluesky

Chris Coyier wrote about it.

Now it’s my turn.

Last week I’m flying home.

My flight gets delayed in air, then lands late so I miss my connecting flight…

[Skip over all the stuff about airline customer support, getting rebooked, etc.]

It’s ~10pm and I’m stranded overnight. I need a last-minute hotel room.

I figure I’ll try HotelTonight because that’s their shtick, right? “Incredible last-minute hotel deals” says their homepage hero banner.

I find the closest hotel, click “Purchase” it takes me to checkout, I do the whole Apple Pay thing, then it says “failed to book” because there are no more rooms left.

Ok? Would’ve been nice to know that before going through all the checkout stuff, but ok. I’ll find another.

Two more hotels, same deal. Click through, checkout, blah blah blah, payment won’t go through. It says there are no more rooms left.

No I’m getting frustrated. I’ll try one more time…

Same flow. Finally! Payment goes through. Confirmation number and all — I’m good to go!

I leave the airport and get a rideshare to the hotel.

Go up to the desk. “Yes, I’m checking in please.” They ask for my name. I give it.

They can’t find me.

“Oh, no…” I think.

“Do you have a reservation number?”

Hell yes I do! Right here in the email HotelTonight sent me.

I give it to them.

It’s not in their system.

“Ok well, can you get me a room?”

Nope, they are completely full for the night.

Knowing that I booked through a third-party system, and it’s not in the first-party system, I know there’s no chance I’m getting a room.

So now it’s 10:30pm. I’m in the lobby of the hotel for which I have a bogus confirmation and I begin my search for the next-closest hotel.

I know at this point I’m not using anything internet-based to make a reservation. Over-the-phone only!

I call a bunch of nearby hotels. Every one is giving me their automated phone system — “If you want to book a reservation, press 1. If you want to…”

I sit through the first couple calls and eventually connect to a human: “Do you have any rooms available tonight?”

“Yes sir, can you confirm which location you are calling for?” They don’t know because this isn’t someone at the hotel. This is a call center somewhere.

I quickly realize this ain’t gonna work.

New rule: if the number online is a centralized number that gives me your automated phone system, I’m out. Next hotel.

I just need to connect to a human at a front desk.

I call maybe 12 hotels. About two give me humans at the front desk. Both of those are booked solid for the night.

But you know what? Props to those hotels for having direct lines to a human. YUGE props.

A direct line to a human feels like the ultimate luxury at this point.

“Hey you got any rooms tonight? No? That’s ok. I appreciate you being there to answer my call, friend. You have a good night.”

Eventually I find a hotel 20 minutes down the road where somebody at the front desk answers and says they have a room. “It’s twice the cost since it’s our last room.” I don’t care, I book it. This is a phone call with a person at the front desk, I know I’m getting a room.

Postscript: I also spent several days going back and forth with a rep at HotelTonight to get a refund. I guess it’s hard to prove that their system sold me a room that did not exist.

Reply via: Email · Mastodon · Bluesky

OpenAI released their new “browser” and Simon Willison has the deets on its security, going point-by-point through the statement from OpenAI’s Chief Information Security Officer. His post is great if you want to dive on the details. Here’s my high-level takeaway:

Everything OpenAI says they are doing to mitigate the security concerns of an LLM paired with a browser sounds reasonable in theory. However, as their CISO says, “prompt injection remains a frontier, unsolved security problem”. So unless you want to be part of what is essentially a global experiment on the frontier of security on the internet, you might want to wait before you consider any of their promises “meaningful mitigation”.

(Aside: Let’s put people on the “frontier” of security for their daily tasks, that seems totally fine right? Meanwhile, Tom MacWright has rationally argued that putting an AI chatbot between users and the internet is an obvious disaster we’ll all recognize as such one day.)

What really strikes me after reading Simon’s article is the intersection of these two topics which have garnered a lot of attention as of late:

1. npm supply chain attacks
2. AI browsers

This intersection seems primed for exploitation, especially if you consider combining different techniques we’ve seen as of late like weaponizing LLM agents and shipping malicious code that only runs in end-users’ browsers.

Imagine, for a second, something like the following:

You’re an attacker and you stick malicious instructions — not code, mind you, just plain-text English language prose — in your otherwise helpful lib and let people install it.

No malicious code is run on the installing computer.

Bundlers then combine third-party dependencies with first-party code in order to spit it out application code which gets shipped to end users.

At this point, there is still zero malicious code that has executed on anyone’s computer.

Then, end users w/AI browsers end up consuming these plain-text instructions that are part of your application bundle and boom, you’ve been exploited.

At no point was any “malicious code” written by a bad actor “executed” by the browser engine itself. Rather, it’s the bolted on AI agent running alongside the browser engine that ingests these instructions and does something it obviously shouldn’t.

In other words: it doesn’t have to be code to be an exploit. Plain-text human language is now a weaponizable exploit, which means the surface for attacks just got way bigger.

But probably don’t listen to me. I’m not a security expert. However, every day that voice in the back of my head to pivot to security gets louder and louder, as it’s seemingly the only part of computer science that gets worse every year.

Reply via: Email · Mastodon · Bluesky

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.

A Few Examples

So what are the browser ‘subsystems’ I can glue together? What are some examples of things I can ask the browser to do rather than doing them myself?

A examples come to mind:

• View transitions API (instead of JS DOM diffing and manual animation).
• CSS transitions or @keyframes (GPU-accelerated) vs. manual JS with setInterval updates.
• scroll-behavior: smooth in CSS vs. JS scroll logic.
• CSS grid or flexbox vs. JS layout engines (e.g., Masonry clones).
• <video> and <audio> elements with native decoding and hardware acceleration vs. JS media players.
• <picture> or <img> with srcset for responsive images vs. manual image swapping logic in JS.
• Built-in form state (formData) and validation (required, pattern, etc.) vs. JS-based state, tracking, and validation logic.
• Native elements like <details>, <dialog>, <select>, etc., which provide built-in keyboard and accessibility behavior vs. custom ARIA-heavy components.

Going Galaxy Brain

The trick is to let go of your need for control. Say to yourself, “If I don’t micromanage the browser on this task and am willing to let go of control, in return it will choose how to do this itself with lower-level APIs that are more performant than anything I can write.”

For example, here are some approaches to animating transitions on the web where each step moves more responsibility from your JavaScript code on the main thread to the browser’s rendering engine:

• setTimeout
  • JS timers, DOM manipulation, browser repaints when it can. Dropped frames.
• requestAnimationFrame
  • Syncs to browser repaint cycle. Smooth, but you gotta handle a lot yourself (diffing, cleanup, etc.)
• View Transitions in JS
  • JS triggers, browser snapshots and animates. Native performance, but requires custom choreography on your part.
• View Transitions in CSS
  • Declare what you expect broadly, then let the browser take over.

It’s a scale from:

I want the most control, and in exchange I’ll worry about performance.

To:

I don’t need control, and in exchange you’ll worry about performance.

I don’t know about you, but I’d much rather hand over performance, accessibility, localization, and a whole host of issues to the experts who build browsers.

It’s Trade-offs All the Way Down

Building on the web is a set of choices:

• Do it yourself.
• Let the browser do it.
• Somewhere in between.

Anytime you choose to do something yourself, you’re choosing to make a trade-off. Often that increase in control comes at the cost of a degradation in performance.

Why do it yourself? Often it’s because you want a specific amount of control over the experience you’re creating. That may be perfectly ok! But it should be a deliberate choice, not because you didn’t consider (or know) the browser offers you an alternative. Maybe it does!

So instead of asking yourself, “How can I write code that does what I want?” Consider asking yourself, “Can I write code that ties together things the browser already does to accomplish what I want (or close enough to it)?”

Building this way will likely improve your performance dramatically — not to mention decrease your maintenance burden dramatically!

Reply via: Email · Mastodon · Bluesky

Related posts linking here: (2025) Browser APIs: The Web’s Free SaaS