nolanl

Glad to see you and the team are still at it! The accessibility guardrails in Svelte are in particular something that I imagine steers agents in the right direction. And it would be sad if the frontend ecosystem converged on React for the LLM benefits given that it's definitely not optimal performance-wise, especially on slower mobile devices.

Welp, I fed it the first 3 paragraphs of an unpublished blog post I wrote a few years ago, and Opus 4.7 guessed right. ChatGPT guessed wrong though.

My wife also got the same result, so I'm guessing it wasn't just because I was using my personal Claude account. Spooky stuff.

The concept of "AI will review AI-authored PRs" seems completely wrong to me. Why didn't the AI write the correct code in the first place?

If it takes 17 rounds of review from 5 different models/harnesses – I don't care. Just spit out the right code the first time. Otherwise I'm wasting my time clicking "review this" over and over until the PR is worth actually having a human look at.

This is 100% my experience. Like, reading this thread right now, I notice the ringing in my ears. But otherwise I go months without thinking about it.

I've had tinnitus for almost a decade now. It gets better.

The first six months were hell because I kept focusing on how awful it was. Eventually you stop noticing it. It just becomes part of the background – like how the sky is blue, grass is green, etc.

I strongly recommend reading "Living with Tinnitus" by Laura Cole. Tinnitus is a very poorly-understood condition, but hearing about the experiences of others helps a lot. I hope you feel better soon. https://www.goodreads.com/book/show/37707931-living-with-tin...

I've found Bugbot to be shockingly effective at finding bugs in my PRs. Even when it's wrong, it's usually worth adding a comment, since it's the kind of mistake a human reviewer would make.

Right, but you do avoid worries like "will I have to update this dependency every week and deal with breaking changes?" or "will the author be compromised in a supply-chain attack, or do a deliberate protestware attack?" etc. As for performance, a lot of npm packages don't have proper tree-shaking, so you might be taking on extra bloat (or installation cost). Your point is well-taken, though.

As someone who has actually worked on JavaScript frameworks, I think Marko is criminally underrated. The compile-time optimizations are extremely impressive: https://markojs.com/docs/explanation/fine-grained-bundling

I was not surprised for example that Marko came out very well in this performance comparison: https://www.lorenstew.art/blog/10-kanban-boards

Author here. I actually did some research on CSS selector performance: https://nolanlawson.com/2023/01/17/my-talk-on-css-runtime-pe...

The TL;DW is: yes, class selectors are slightly more performant than attribute selectors, mostly because only the attribute _names_ are indexed, not the values. But 99% of the time, it's not a big enough deal to justify the premature optimization. I'd recommend measuring your selector performance first: https://developer.chrome.com/docs/devtools/performance/selec...

I use shadow DOM every day, but yes, it is often the part of WCs that baffles people – probably because they don't need it.

Alternative approaches that may work for your use case:

- "HTML web components" [1] - light DOM only, SSR-first, good as a replacement for "jQuery sprinkles"

- "Shadow gristle" [2] - use as little shadow DOM as possible. If you need styling or composition, put it in the light DOM!

[1]: https://adactio.com/journal/20618

[2]: https://glazkov.com/2023/03/02/shadow-gristle/

I cover this in another post [1], but broadly:

- Not every web app is perf-sensitive to every extra kB (eCommerce is, productivity tools typically aren't)

- Plenty of frameworks have tiny runtimes, e.g. Svelte is 2.7kB [2]

- I wouldn't advocate for 100 different frameworks on the page, but let's say 5-6 would be fine IMO

No one is arguing that this is ideal, but sometimes this model can help, e.g. for gradual migrations or micro-frontends.

BTW React 17 actually introduced a feature where you could do exactly this: have multiple versions of React on the same page [3].

[1]: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-comp...

[2]: https://bundlephobia.com/package/svelte@4.2.19

[3]: https://legacy.reactjs.org/blog/2020/10/20/react-v17.html

Author here. I cover this in another post [1], but basically the interop benefits you get on the client just aren't there (yet) on the server. My north star:

> Maybe in the future, when you can render 3 different web component frameworks on the server, and they compose together and hydrate nicely, then I’ll consider this solved.

[1]: https://nolanlawson.com/2023/08/23/use-web-components-for-wh...

Thanks a lot! I was just trying to highlight the cool work that browsers do under the hood, but which wasn't very well-known. So I'm really glad that folks enjoyed the talk. :)

Author here! I struggled with the word "modern" – I could have said "current gen" or "post-React" or even "Solid-inspired" frankly, but I thought "modern" was succinct with the right amount of punchiness.

Obviously a lot of these techniques are pretty novel, and maybe they won't stand the test of time. Or maybe a new browser standard will make them obsolete eventually. But for now these seem to be the current wave anyway.

Author here. Thanks for the thoughtful reply!

I did indeed mix up `useMemo` and `React.memo` – fixed it in the post.

You're right, I am skipping a lot of details (hence "to grossly oversimplify"). I know that React doesn't invalidate the whole tree, but it does in the worst case. Maybe I should add a note about that.

Svelte not being truly reactive makes perfect sense, but in Svelte v5 my understanding is that "runes mode" does exactly that. This is what I mean by "moving in that direction."

Thanks for the shout-out! I think I mention this in the talk, but note that YMMV. I designed that benchmark as a kind of "worst-case scenario" where shadow DOM / scoped styles really show a benefit. Depending on your CSS rules, DOM size, and amount of thrashing, the perf benefit could be small to large.

Also, it's still possible to shoot yourself in the foot, especially if you have a large/complex stylesheet repeated across multiple shadow roots. (Not because of the repetition – that's optimized in browsers [1] – but rather because of the number of DOM nodes affected.)

That said, I still think the perf benefits of shadow DOM have been undersung. And Declarative Shadow DOM makes it way more useful.

[1]: https://github.com/whatwg/dom/issues/831#issuecomment-585489...

Thank you! This is exactly what I had in mind. The streaming aspect of MPA pages is a great example of something you can't really do in an SPA. (Although there are hacks: https://jakearchibald.com/2016/fun-hacks-faster-content/)

(Author here.) I totally agree and feel that Service Workers are still underexplored in this area. If your main reason for writing an SPA is speeding up navigation (e.g. the Turbolinks approach), then you may be better served by just moving the rendering logic into a Service Worker.

It should be possible to build an "MPA" where all the rendering logic lives in the Service Worker. Then you'd get fast navigations without needing to worry about a client-side router and managing focus/scroll/etc. I'm not sure I've seen a great implementation of this though.

It depends. For elements that are removed from the DOM, then yes, the event listener should also be automatically removed: https://jakearchibald.com/2020/events-and-gc/

However, if you're adding event listeners to the document, the window, or some permanent element (header, footer, etc.), then those won't be GC'ed since the DOM node is never GC'ed.

That's really interesting. I wonder if this is a Chromium-only issue? It may be worth filing a bug: https://bugs.chromium.org

I'm not an expert in this space, but it seems to me that the JavaScript engine could eventually clean up that memory, maybe based on some heuristics (e.g. the size of the original string, whether any references to the original string exist, etc.).

Great point! This is exactly why fuite does a preflight iteration before the "real" iterations. One-time setup costs shouldn't count against the "leak" – only sustained memory growth.

Author here. I added support for custom scenarios, where you can define a "setup" step that logs in or does whatever you may need to do: https://github.com/nolanlawson/fuite/#extending-the-default-...

Author here. I wasn't aware of your talk, but it's super interesting! Showing info about the retain chain is a great idea, but I didn't get around to doing it in fuite. IME just counting the number of objects is actually pretty effective to find the smoking gun. (You leaked 1 event listener, which leaked a bazillion strings, arrays, objects, etc., but all you really care about is the 1 event listener.)

I would love to see how your tool approaches this! Hope it gets open-sourced. :)

I wrote that article 7 years ago, and FWIW I would side more with Dale these days. It's probably a good thing we didn't just slap a half-baked API on top of SQLite and call it a web standard.

The biggest problem is that yeah, WebSQL tends to be faster than IndexedDB. Or at least it was back when I was working on PouchDB. Biggest issue IIRC was that joins were faster in SQLite than implementing the same thing in userland on top of IndexedDB. Browsers eventually shipped getAll/getAllKeys which also helped with cursor slowness.

I haven't looked much at the Storage Foundation API [1], but it seems like a more reasonable approach moving forward. Just give developers the low-level tools and let them build SQLite on top of it. Also the Chromium devs have been working on relaxed durability, which apparently improves IDB perf in some scenarios [2] (although still not as fast as Firefox it seems [3]).

[1]: https://github.com/WICG/storage-foundation-api-explainer

[2]: https://www.chromestatus.com/feature/5730701489995776

[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=102545...

Author of Pinafore here. Yes, ironically for an app and userbase that is so focused on privacy, things like private browsing, Privacy Badger, adblockers, etc. can cause compat issues with Pinafore.

Interestingly, the reason is (as I discovered) that most of these tools consider cross-origin requests as a signal of a third-party tracker or ad, and therefore block it. Pinafore works by talking directly to the instance's API, and so the instance itself is suspected to be a third-party tracker. ‍️

It looks like the Social CG is still active, and they're working on the new ActivityPub protocol which Mastodon 2.0 supports. Follower migration is one of the issues they're discussing:

- https://www.w3.org/wiki/SocialCG/2017-10-11

- https://github.com/swicg/general/issues/1

A good place to start is https://instances.social/ or https://joinmastodon.org

It doesn't seem to offer a single-user version, but https://masto.host/ can give you a managed Mastodon instance at the click of a button.

Mastodon has a single-user instance mode: https://github.com/tootsuite/mastodon/blob/8392ddbf87f5522c4...

Most instances would federate with you immediately since they're on a blacklist model, but some instances (such as awoo.space) operate on a whitelist, meaning they'd have to vet you first.

I contribute to Mastodon, an open-source federated social network based on the OStatus set of W3C standards. Most of my work has been on making the web frontend faster, trying to add the kind of fit-and-finish that proprietary apps like Twitter and Facebook have.