Nolan Lawson

toot.cafe admin, dev at Socket. Creator of https://pinafore.social. Formerly Salesforce and Microsoft Edge. The web is for everyone.

Website: https://nolanlawson.com
Pronouns: he/him
Patreon: https://www.patreon.com/user?u=5535137
Header: https://flic.kr/p/owsn7U

Public Key

npub1yewefjyn7gypzfgme0makq9ps6zws829hmnprl333e686ywx64dsasxuft

NIP-05 Address

[email protected]

Profile Code

nprofile1qqszvhv5ezflyzq3y5duha7mqzscdp8gr4zmaes3lcccuaraz8rd2kcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds4tyd8d

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1yewefjyn7gypzfgme0makq9ps6zws829hmnprl333e686ywx64dsasxuft

Show more details

Last Notes

2026-05-02 04:30:01 UTC

- reply

Oh man I almost forgot about:
- elementtiming
- ARIA semantics where the parent-child DOM relationship matters (e.g. list / list items)
- scoped custom element registries
I'm having flashbacks to all these battles. Really hard to say I miss them.

2026-05-02 04:13:43 UTC

- reply

I *really* look forward to using shadow DOM in, like, ~3-5 years after all this stuff has been ironed out. In the meantime, its advocates are doing true heroics to harmonize it with the rest of the web platform. But it's really a slog, and it's hard for me to remember fondly all the effort I put into getting basic stuff to work across shadow boundaries

2026-05-02 04:10:45 UTC

- reply

I don't want to dismiss the hard work that people are doing to make the web platform more cohesive. And of course competing interests and priorities will always make the web "lumpy": https://paul.kinlan.me/the-lumpy-web/
But still, as a web developer, it's exhausting. This site doesn't even cover @font-face, ARIA IDref, submit buttons in forms, focus libraries, browser extensions, styling… the list goes on and on. When you work with shadow DOM, you're opting into pain.

2026-05-02 03:54:42 UTC

Just discovered this excellent resource about which CSS features work well in shadow DOM and which don't: https://shadow-dom-css.adobe.com/
Honestly this is the part I miss least about working with web components. It broke so many parts of the web platform, and plenty of new web APIs seem to be just plowing ahead and hoping "somebody will figure out this shadow DOM stuff later"

2026-02-07 16:53:07 UTC

New post: "We mourn our craft" https://nolanlawson.com/2026/02/07/we-mourn-our-craft/
No comment on this one.

2026-01-24 23:47:24 UTC

- reply

I'm honestly sorry if you felt offended, but yes I was trying to be a bit provocative. Believe me, it pains me a bit too – I've seen the Hayao Miyazaki video and I strongly identified with him and against the boors who take his work without understanding the artistry that went into it. But with coding at least, I suppose I've placed my bet on where I think things will end up, regardless of which side I identify with more. I guess that was my point.

2026-01-24 21:31:00 UTC

New post: "AI tribalism" https://nolanlawson.com/2026/01/24/ai-tribalism/
It must be 2026, because I'm still writing slightly-spicy AI takes. 😅

2026-01-18 19:35:51 UTC

- reply

How I'm currently coping:
- Not believing the most outrageous hype, because a lot of the early experiments are still laughably bad
- But not dismissing it out-of-hand either because I can see the vision
- Doing non-AI open-source coding on the weekends to try to keep my skills sharp
- Trying to figure out which high-level skills are also worth cultivating (taste, architecture, systems thinking, etc.)

2026-01-18 19:33:16 UTC

- reply

I've run a very poor man's version of this myself, where Claude writes the code, Cursor reviews it, and then Claude writes the bugfixes. It's horribly inefficient! But the most inefficient part is the wet squishy human in the middle. Automating that part is not complicated.
And even if it's still slow and token-inefficient, and even if the cost of tokens goes up, it's probably less than a dev's salary. So yeah I'm scared.

2026-01-18 19:26:10 UTC

- reply

If you picture someone trying to automate an entire software company, you're not far off. If Steve Yegge had chosen less dystopian names and something more like "PM," "IC," "director," etc then it would look a lot more familiar.
Does it actually work? Unclear. Could it get better? Maybe! All I know is I'm scared. If you understand how the individual puzzle pieces work then it's not rocket science to put them together.

2026-01-18 19:21:36 UTC

RE: https://hachyderm.io/@mitsuhiko/115915668396176076
I wrote a longer reply on Lobsters, but I think understanding the thinking behind things like Ralph loops and Gas Town helps make some sense of this madness: https://lobste.rs/s/0pxvyd/agent_psychosis_are_we_going_insane#c_agw4oe

2025-12-15 15:49:52 UTC

- reply

Yep looks like a WordPress bug; sadly I'm on WordPress.com so can't fix it. 🙄

2025-12-14 20:47:42 UTC

New post: "The <time> element should actually do something" https://nolanlawson.com/2025/12/14/the-time-element-should-actually-do-something/
A modest proposal for a forgotten HTML element.

2025-12-13 16:09:54 UTC

- reply

FWIW I avidly followed your links and really appreciated the curation. But I understand why you wouldn't do it anymore.
The quality of tech writing on the internet does seem to have gone down lately but I feel like replies have always been kinda bad. E.g. I noticed at some point that the same people seem to comment on every HN post, so some people just love replying apparently.

2025-11-27 16:54:42 UTC

"The top-line takeaway is chilling: sites that are explicitly designed as SPAs, and which have intentionally opted in to metrics measurement around soft-navigations are seeing one (1) soft-navigation for every full page load on average."
Amazing research and analysis as always from @npub1pf4…pgxq https://infrequently.org/2025/11/performance-inequality-gap-2026/

2025-11-16 19:13:16 UTC

New blog post: "The fate of 'small' open source" https://nolanlawson.com/2025/11/16/the-fate-of-small-open-source/
Some meandering thoughts on writing open source when LLMs can do a lot of the same thing. I don't have all the answers, but I'm trying to ask the right questions anyway.

2025-11-09 23:41:14 UTC

"Death of the Browser" by @npub1cf0…evxz https://youtu.be/1bLX1INicBM
Excellent and slightly upsetting talk; gave me a lot to think on. It definitely feels like something big is changing in the browsers/web space, and I'm a bit afraid of where it takes us but trying to be optimistic.

2025-10-31 05:08:06 UTC

"I Built the Same App 10 Times: Evaluating Frameworks for Mobile Performance" by Loren Stewart https://www.lorenstew.art/blog/10-kanban-boards
One of the best web perf analyses I've read in a long while. Can't say the results are surprising, but it's great to see it all laid out.

2025-09-06 15:35:55 UTC

I'm always so relieved when I press the back button on a website and it actually shows me the content I was just looking at, as opposed to slowly and jankily reloading the page, then auto-scrolling to the wrong spot.
Still waiting for webdevs to notice that the latter is a dead giveaway that your site is an SPA.

2025-08-26 13:16:34 UTC

Coming from the browser world to Node.js, it amazes me how primitive the tooling is for performance analysis. In the browser, you can click one button in DevTools and see every thread (including Workers), IndexedDB, networking, and user timing all laid out in one timeline. Whereas in Node, you get one thread, and good luck figuring out what's going on with your database or filesystem calls. Feels like a lost opportunity, given that Node can talk to the same DevTools APIs.

2025-06-26 14:59:45 UTC

"The time is right for a DOM templating API" by @npub1rm0…7psc https://justinfagnani.com/2025/06/26/the-time-is-right-for-a-dom-templating-api/
I agree. The major frameworks (outside React anyway) have converged on surprisingly similar ideas. It's a good time to just put JavaScript frameworks into the browser.

2025-05-23 00:54:31 UTC

"The Copilot Delusion" by Jj https://deplet.ing/the-copilot-delusion/
"You’re not working with a copilot. You’re playing Russian roulette with a loaded dependency graph."
Infinitely quotable. I wish I could write like this.

2025-05-10 00:21:46 UTC

Every time I look at the new CSS APIs coming down the pike, I get excited about all the dumb code I can delete.
Today's unreasonable excitement comes from `field-sizing`, which aims to solve the problem of auto-expanding/auto-shrinking <textarea>s. Can't come soon enough! https://developer.mozilla.org/en-US/docs/Web/CSS/field-sizing

2025-03-29 15:31:12 UTC

This is a great example of why the web rocks. Safari and Chrome disagreed on the spec, so we ended up with a third, better spec. This wouldn't happen if one company controlled everything: https://webkit.org/blog/16587/item-flow-part-1-a-new-unified-concept-for-layout/

2025-03-14 15:20:33 UTC

- reply

Even with web performance, I saw a thread recently of someone working on an AI agent to analyze perf traces and provide recommendations. It's deeply scary tbh

2025-03-14 14:48:15 UTC

- reply

The challenge for me personally is that I feel like abstaining from LLMs is not necessarily going to stop this tidal wave from happening anyway. For the past couple years I've been one of the few people in my org (loudly) decrying LLMs and refusing to use them in my work, and yet I still look outside and see the tsunami approaching.

2025-03-14 14:44:45 UTC

This post from @npub1fdr…lvhs captures some of the dread dredged up by my recent thread on using LLMs for coding: https://pluralistic.net/2025/03/13/electronic-whipping/
> "Code reviewer" is a much less fulfilling job than "programmer." Code reviewers are also easier to replace than programmers. A code reviewer is a reverse-centaur, a servant to the machine. Every time you hear "AI-assisted programmer," you should substitute "programmer-assisted AI."

2025-03-09 14:16:32 UTC

- reply

These are good points, thank you. Maybe that's the heart of my inner conflict: these tools "work" (for some definition of "work") but they are inherently dehumanizing and insulting. They make a mockery of my ~20 years of hard-won expertise.
Ezra Klein in his podcast once said that the core "message" of GenAI (in the McLuhan sense) is: "You are derivative." I totally agree with that.

2025-03-08 23:29:14 UTC

- reply

I'm familiar with all the arguments against GenAI, and I'm a big fan of authors like @npub1hr7…jxyc whose excellent book, The Intelligence Illusion, I've read twice. It's highly recommended. https://illusion.baldurbjarnason.com/
I have a degree in computational linguistics, and that's partly why I was so skeptical of these tools for so long. I still am! But more and more I felt like the world was moving on without me. To this day I feel deeply conflicted.

2025-03-08 23:22:59 UTC

- reply

Of course, this is a choice: I *could* choose not to use LLMs. When I ride my bike, I don't bemoan the fact that a car could do it faster – the goal is exercise.
But nobody's paying me to ride my bike. If I were a delivery driver, it'd be pretty unprofessional to show up an hour late with a cold pizza just because I like biking.
With LLMs, it almost feels like malpractice *not* to use them at this point. I can't justify taking ~3x longer to ship a feature just because I don't enjoy using them.

2025-03-08 23:20:17 UTC

- reply

The other issue of course is that I'm not learning as much when I use LLMs. Even if it's an iterative, back-and-forth process, the tool is doing ~80% of the thinking for me.
It feels like I either need to spend more time learning outside of coding, or just accept at some level that I'm "cashing in my chips" and relying on ~20 years of actual coding experience.
Either way, I feel less excited by these tools than defeated. They're incredible magic wands, but I kind of liked doing my own sorcery?

2025-03-08 23:19:13 UTC

I held out for a long time, but I finally started using LLMs in my regular coding work. I couldn't deny the utility of tools like Claude any longer, when it can do in 2 minutes what would take me an hour.
There are problems: hallucinations, verbosity, bad/unperformant/inaccessible code. I have to correct it a lot. That's OK.
The main problem I find is that it's sucked a lot of the fun out of coding for me. It's like I've been pushed into a management role when I just wanted to stay a coder.

2025-03-08 18:13:39 UTC

My response to a lot of issues these days on emoji-picker-element is "please use patch-package": https://www.npmjs.com/package/patch-package
When given the choice between 1) add 50 different configuration options to satisfy 50 niche use cases, or 2) have 50 people apply patches to their own codebase, I'm strongly in favor of the latter.

2025-02-03 20:35:14 UTC

"Offlinin' Aint Easy" by @npub1t0w…zgs2 https://blog.codepen.io/2025/02/03/chris-corner-offlinin-aint-easy/
Just to further illustrate how complicated Service Workers can be, the linked minimal examples are missing nav preloads, which means it can actually make your site _slower_ for non-cached requests: https://web.dev/blog/navigation-preload
Service Workers are great, but I think they're still too low-level a lot of the time. Would be great to have a higher-level, more ergonomic API.

2025-01-14 16:22:46 UTC

#LineageOS is pretty incredible. I have an 8-year-old OnePlus 5T rocking the latest version of Android thanks to LineageOS 22.1. The battery still lasts more than a day, and the phone only cost me $500 (in 2017 dollars). Pretty great value for money.

2024-12-28 17:18:52 UTC

- reply

This is about selector performance. Selectors have a cost during style calculation, and browsers have tons of optimizations for simple class selectors (and Tailwind doesn't even use descendant selectors AIUI): https://nolanlawson.com/2023/01/17/my-talk-on-css-runtime-performance/

2024-12-28 03:09:01 UTC

I'm surprised that more Tailwind advocates don't promote it for its improvements to Style Calculation performance. Since it's all just straight CSS classes, you'd expect style recalc costs to be close to zero.
I took a glance at 3 sites in the Tailwind showcase (https://tailwindcss.com/showcase). 1 had very low style recalc costs relative to layout costs. The other 2 had higher costs, but they were clearly coming from non-Tailwind CSS (via "Selector Stats" in DevTools).

2024-12-01 18:47:58 UTC

New blog post: "Avoiding unnecessary cleanup work in disconnectedCallback" https://nolanlawson.com/2024/12/01/avoiding-unnecessary-cleanup-work-in-disconnectedcallback/
A quick #webcomponents tip, for some subtle timing issues with `disconnectedCallback`.

2024-11-03 17:41:02 UTC

"Sharing Styles with Declarative Shadow DOM" by Kurt Catti-Schmidt https://youtu.be/acTFdPTTe-Y
Great breakdown of the problem and very creative solution. I've been watching this space for a while, and this is the first proposal that I don't have any problems with. Excited to see where this goes!

2024-10-29 02:18:55 UTC

"We're forking Flutter. This is why." by Matt Carroll https://flutterfoundation.dev/blog/posts/we-are-forking-flutter-this-is-why/
This is fascinating. I'll be interested to see if this turns out like Node->io.js (projects eventually merge), Hudson->Jenkins (everyone moves to the fork), or something else.

2024-10-20 21:20:29 UTC

New post: 'Why I’m skeptical of rewriting JavaScript tools in "faster" languages' https://nolanlawson.com/2024/10/20/why-im-skeptical-of-rewriting-javascript-tools-in-faster-languages/
Some thoughts that sprang from a recent Mastodon thread: https://toot.cafe/@nolan/113340900722953634

2024-10-20 17:17:28 UTC

Every time I mess around with sysadmin stuff, I'm always flummoxed by dumb things like "what is the difference between /usr/bin and /usr/local/bin, what the heck is an LD_LIBRARY_PATH, should I use sudo for this build tool or not," etc.). I guess this is how backend devs feel when they have to tweak a Webpack config.

2024-10-20 16:10:22 UTC

- reply

Another amusing thing to me: if the Chrome team had never documented these improvements (Back-Forward Cache, Paint Holding, etc.), I think these would have been "discovered" naturally by web developers, probably a lot later. Many of these things already existed in non-Chrome browsers and weren't widely known; Chrome just broadcasted it when they did the work (good on them!). Same goes for things like the JavaScript bytecode cache. https://v8.dev/blog/code-caching-for-devs

2024-10-20 16:08:15 UTC

- reply

Accompanying article: https://htmx.org/essays/you-cant/
Besides the Back-Forward Cache, one thing I wish the article mentioned is that you're really writing a lot less code with MPAs. Or at least, you're sending a lot less code to the client. There are so many fiddly bits you have to get right with SPA navigations (although the new Navigation API helps), and you just don't need those if you do a full navigation.
SPAs still have their place, but the underlying browser tech has really changed!

2024-10-20 16:05:22 UTC

"Breaking free from SPA dominance with Anthony Alaribe" https://podrocket.logrocket.com/breaking-free-from-spa-dominance-anthony-alaribe
Great interview. Between Service Worker, Speculation Rules, View Transitions, Paint Holding, and the Back-Forward cache, there are just less and less reasons to write an SPA these days.

2024-10-20 05:41:17 UTC

"The IPv6 Transition" by Geoff Huston https://www.potaroo.net/ispcol/2024-10/ipv6-transition.html
"I suspect that the dual stack world we’re in is a world we will be stuck in for quite some time. There seems to be no appetite to resolve this situation by completing the transition any time soon, and absolutely no desire to back out and revert to a IPv4-only network."

2024-10-15 02:45:25 UTC

"An Introduction to Shared Compression Dictionaries" by Anna Monus https://www.debugbear.com/blog/shared-compression-dictionaries
Really feels like a once-in-a-generation kind of performance improvement. Hard to think of anything else of the same magnitude in recent memory.

2024-10-13 19:33:32 UTC

New post: "The greatness and limitations of the js-framework-benchmark" https://nolanlawson.com/2024/10/13/the-greatness-and-limitations-of-the-js-framework-benchmark/
In which I discuss some of the lesser-known secrets of this benchmark, which is frequently cited when comparing JavaScript frameworks.

2024-10-11 01:39:41 UTC

- reply

I don't understand how anyone can think that the current Node dependency roller coaster is remotely normal. If you have any reasonable number of dependencies (TypeScript, Rollup, ESLint, etc), you are broken at least every other week.
These tools are supposed to make us more productive? I think? So why am I spending a bunch of time reading some inscrutable error message and hunting for some glib comment buried in a CHANGELOG.md?
Lockfiles are the only thing keeping the whole house of cards up.

2024-10-11 01:31:19 UTC

Updating my Node dependencies after 2 months: "Ah, let's see what fresh horrors await"

2024-10-09 17:20:43 UTC

- reply

BTW I never understood the whole Liskov substitution thing until this post. It's not just a problem for built-ins, but also web component libraries that allow subclassing. Any change to the superclass is effectively a breaking change unless the subclass automatically gets the new behavior somehow (e.g. super.connectedCallback).

2024-10-09 17:10:55 UTC

- reply

Fantastic post. My only minor quibble is that I do think the React team has kept innovating – concurrent rendering and RSCs come to mind. Although I'm not convinced the first is a great idea (https://nolanlawson.com/2022/10/22/style-performance-and-concurrent-rendering/) and the second seems to be heavily dividing the React community, I have to give them credit for having the guts to try new stuff even though they're the clear market leader.

2024-10-07 07:33:21 UTC

- reply

That's fair, but I'm not reading this as "let's stop evolving JS," I'm reading it as "let's raise the bar for evolving JS in ways that tooling can already handle"

2024-10-07 07:18:18 UTC

- reply

Honestly I don't hate this. I sympathize with JS engine authors trying to balance security/perf with ergonomics. Given the CVE count and dumb perf bugs like "var is faster than const/let", it seems like a losing battle.
JS is already quite good, and it would be sad IMO if it became like Perl where there are 20 ways to do everything. And of course if perf/security suffer. JS0/JSSugar seem totally reasonable to me.

2024-10-02 03:33:31 UTC

"I wasted a day on CSS selector performance to make a website load 2ms faster" by [@trys](https://mastodon.social/@trys ) https://www.trysmudford.com/blog/i-spent-a-day-making-the-website-go-2ms-faster/
This is one of the unfortunate things about the DevTools' "selector stats." It can really mislead you if you don't notice the text "(slow)" which _really_ means slow.

2024-09-28 23:30:13 UTC

New blog post: "Web components are okay" https://nolanlawson.com/2024/09/28/web-components-are-okay/
Lord help me, I've entered the web components discourse. Trying to be a peacemaker though!

2024-09-24 06:52:51 UTC

"Thoughts on Debugging" by Dave DeGraw https://catskull.net/thoughts-on-debugging.html
I identify with this a lot. I actually enjoy debugging a lot of the time.

2024-09-09 05:35:29 UTC

- reply

Totally randomly, I opened a PR on Tachometer to add support for cross-origin isolation… need to check on why it wasn't merged: https://github.com/google/tachometer/pull/234
For the Firefox error, I managed to fix it on Ubuntu by pointing to the snap binary: https://gist.github.com/nolanlawson/c9d42d0a49130ae6922718608c921efb

2024-09-01 16:35:34 UTC

The goal of Dependabot seems to be to remind me that my Node projects from ~2 years ago are utterly unmaintainable

2024-08-05 14:42:05 UTC

New blog post: "Reliable JavaScript benchmarking with Tachometer" https://nolanlawson.com/2024/08/05/reliable-javascript-benchmarking-with-tachometer/
I've been using Tachometer for a long time, but it occurred to me I never wrote about it. So here's why I like this tool for JavaScript benchmarks!