JavaScript: Weekly Summary (November 17-23, 2025)

There was a busy week in the JavaScript blogging world. Bits of engineering, a few hot takes, and a small stack of tinkering and tooling notes. I would describe them as a mixed bag — some practical tricks you can copy-paste into a project, some essays that grumble about the whole web-of-everything idea, and a couple of playful experiments that feel like side projects at midnight. To me, it feels like everyone is nudging at the same edges: performance, smoothness, how JS talks to other things, and whether the web is becoming the only game in town.

Smooth transitions and the tricky Navigation API

The week kicked off with a neat how-to from Bramus about faking Two-Phase View Transitions using the Navigation API's precommitHandler. The writeup is practical and a bit clever. The problem is obvious if you have ever clicked a link and watched the UI jump or stare blank while the next page loads — a small but jarring delay. Bramus walks through making an immediate preview state, like dropping in a spinner or a subtle placeholder, before the new page actually loads. He shares code, which is what you want when you actually want to try this tomorrow.

It's not magic. Browser support is still the rub. I would describe his approach as pragmatic: you get better perceived performance without waiting for perfect platform support. The idea is like putting a pot on the stove and lighting the burner before you chop the onions — the visible part moves first, so the user thinks things are faster. There are trade-offs: you need to handle aborts, fallback paths, and maintain decent UX when the precommit step isn't available. If this kind of nitty-gritty UX work appeals to you, read Bramus' post. It shows code and the edge cases, so you don't have to guess.

Interop: Elm still treats JS as a weird neighbor

There was also an excellent primer from Christian Ekrem — a missing chapter for an Elm book, about JavaScript interop. He unpacks ports and flags, and how Elm insists that JavaScript is untrusted infrastructure. The tone is careful, because Elm's whole pitch is purity and safety, so talking to JS is a controlled handshake, not a free-for-all.

I’d say Christian makes the point clear: interop should be explicit. Flags for program start-up, ports for runtime messaging. The examples are small but solid. It feels like being handed a polite but stern neighbor introduction — you can borrow sugar, but don’t leave your door open. There are practical code bits and warnings about breaking Elm's guarantees. If you ever thought that pulling JS into a pure functional world would be simple, Christian gently reminds you that it isn't, and shows ways to do it without causing chaos.

Classic algorithms in a modern playground

A lovely little detour was Rodrigo Girão Serrão's demo of Flood Fill, explained in Python and shown with a JavaScript demo. The article is hands-on and tactile. There’s a click handler, pixel manipulation, and the satisfying feeling of filling a shape with color, like pouring paint inside the lines when you were a kid.

This one is small but useful. If you teach or prototype image tools, Rodrigo's step-by-step approach gives you the mechanics. It’s the kind of post that’s easy to skim but easy to copy into a toy project and see instant results. Like a kitchen recipe that actually works the first time.

Caching and deduping requests — practical state hygiene

There was also a smart piece on caching and de-duplicating fetch requests from Delicious Reverie. It reads like the author's app reached a point where multiple components asked for the same data and the server started groaning. The solution is not glamorous: localStorage, a queue to manage concurrent requests, and sensible expiry rules.

I’d say this is useful because it focuses on the problem you actually hit in apps with many widgets. The author walks through race conditions and how to avoid hitting the API three times because three components all mount at once. The idea is as practical as putting labeled jars in your pantry so you don't buy three different packets of rice. There's code, and there are gotchas about stale data — which is where the expiry logic comes in. For anyone building UIs that talk to the same backend from multiple places, this is worth the read.

Small games and retro tinkering

Two posts leaned into playful territory. One is a charming little demo called Dangerous Dave in Space from Unlisted Retrograde Holdout. It’s a tiny game where Dave rides a glowing blob with arrow keys. The author explains future enhancements — dragging Dave, sound effects, performance tweaks — and mentions the old hardware they used to test it. It’s small, earnest, and reads like a Saturday night project you’d show a friend over a pint.

Speaking of nostalgia, the same author also posted a browser JavaScript benchmark run in a Windows 7 environment — Windows 7 Browser JavaScript Mega Battle. This one is a bit of a time-travel piece. The benchmark compared browsers on low-spec and high-end testbeds. Chrome-based browsers, especially one called Supermium, come out on top, while older forks like Palemoon struggle. There’s a privacy angle too, and a sense that raw JS speed still matters for some people and some workflows.

The two posts together feel like a dip into the hobbyist scene: games, benchmarks, and hardware nostalgia. It’s like rummaging in a shed and finding an old toolbox you forgot you had.

SpeechSynthesis and accessibility — small APIs with big reach

David Walsh had a thoughtful note about the speechSynthesis API. He frames it as one of those small browser features that can really help accessibility. The API lets browsers speak text. He pairs it with mentions of the Vibration API and Page Visibility API, suggesting they’re the kind of mobile-friendly primitives that make apps feel native.

To me, it feels like a reminder: web APIs are no longer just paint and type. They reach into audio, haptics, and sensors. David gives practical pointers and reasons to consider speech synthesis beyond pure accessibility — like audible notifications or read-aloud modes for content-heavy sites. The post doesn’t go deep into edge cases, but it’s a great nudge to try the API out in a real UI.

Automation and newsletters — the glue that keeps content flowing

Simon Willison wrote about automating a Substack newsletter from his blog. If you follow the things Simon builds, you'll recognize the stack: Django, Heroku, PostgreSQL, GitHub Actions, some SQL voodoo, and yes, JavaScript for the parts that need it.

This is a practical, slightly messy story about automating friction away. The interesting bits are the way content is fetched, massaged, and pushed to Substack with minimal editing. There’s a lot of plumbing, and I’d describe it as a reminder that automation is often three parts hack, one part patience. If you publish regularly and hate the manual work, this is a good look at how someone else made the effort pay off. It’s not a polished product; it’s an honest how-I-did-it.

AI in the editor — first impressions and limits

Leon Mika tried out Google Antigravity, an AI code assistant, and wrote a first impressions piece. He used it to build a timestamp and timezone converter, and the experience was a mix of helpful code gen and instability. Crashes and flaky code snippets cropped up. Leon says the output is acceptable but he prefers other tools like Claude Code for his workflow.

I’d say the post is a mild reality check: these AI tools can spit out useful code, but they won't replace a calm, experienced developer's judgment. Antigravity shows promise, but it also reminded Leon (and the reader) that developer workflows are personal. If you like a certain rhythm in your editor, a different AI assistant might suit you better. The post has some useful examples and a frank take on the tooling hiccups.

The long essay: everything is web-based now — a grumpy love letter

Finally, there was a broad essay from dorinlazar.ro about how the development world moved to web-first everything. The piece is part critique, part history lesson. The author argues that the push for web apps has made some things messy and inefficient, that native apps used to be nicer in places, and that large companies like Apple and Google played roles that have complicated the ecosystem.

It's one of those posts that makes you nod and then wince. The complaints sometimes sound like an old-timer at a cafe talking about how music was better on vinyl. But there are good points. The essay highlights the cost of building for the web — the layers of abstraction, the endless toolchains, and the surprising performance gaps that still exist. It’s worth reading if you’re wondering whether the web-dominated future is actually the one you want.

There’s a tension here across many posts: the web is powerful and ubiquitous, but that ubiquity brings baggage. I kept thinking of a market that got very crowded. More stalls, more choice, but also more noise. You can buy great stuff, but sometimes you have to sift through a lot of junk to find it.

Recurring themes and where authors agree or differ

A few patterns stood out. First, performance and perceived speed matter a lot. Bramus' navigation trick, the browser benchmarks, and the caching piece all circle this idea. They take different angles: UX polish, raw JavaScript speed, and request-level efficiency. They agree, tacitly, that users notice the tiny delays.

Second, interoperability and boundaries are a frequent worry. Christian’s Elm interop piece and Simon's automation pipeline both deal with how systems talk to each other. One prefers strict contracts and the other accepts a messy pipeline. There’s no true consensus — some people want fences, others want open hills.

Third, accessibility and small APIs show up as low-cost wins. David Walsh's short post is a gentle nudge that speaking text or using vibration can make apps feel much more polished without a massive rewrite.

Fourth, tooling and AI are in that awkward adolescence. Leon's Antigravity review and the automation story both show tools helping, but not quietly replacing thoughtful workflows. It’s like power tools in a workshop — they speed you up, but you still need to know what you’re doing before you start the saw.

Finally, there's nostalgia and critique. The essay about everything becoming web-based reads like someone carrying a stack of old postcards. There's frustration about the direction of travel, but also acknowledgment that the web’s reach is useful. People are split between wanting cleaner primitives and accepting the messy reality.

Little tangents I enjoyed (and why they matter)

I kept thinking about how these posts form a sort of patchwork map of what it feels like to build on the web today. A user sees a laggy transition — Bramus shows how to hide that. A dev worries about repeated API calls — Delicious Reverie gives a cure. Someone wants a simple tool to read a post aloud on the bus — David Walsh points to speechSynthesis.

There's also that small human thing: the retro game, the Windows 7 benchmark, and the frantic automation of a Substack. They show that people still keep hobbies inside work. They also remind you that not every article has to be a manifesto. Sometimes a post is a slice of life, and it’s valuable precisely because it is simple and small.

Who might want to read what first

• If you build multi-component UIs that hit the same API, start with the caching and dedupe post from Delicious Reverie. It’s pragmatic and will save you API quotas and heartache.

• If you care about perceived navigation speed and UX polish, read Bramus. His precommitHandler trick is the sort of thing users notice and you can ship.

• If you use Elm or are curious about keeping purity while still talking to JS, Christian Ekrem’s chapter is the spot to stop by: Christian Ekrem.

• Want a tiny, satisfying demo? Rodrigo’s Flood Fill shows algorithms in an accessible way: Re: Factor.

• If you tinker with accessibility or mobile UX, David Walsh’s short piece on speechSynthesis is an easy win: David Walsh.

• For the hobbyist or retro crowd, the Dangerous Dave demo and the Windows 7 benchmark are fun: Unlisted Retrograde Holdout.

• If you want a peek into automating content workflows, Simon Willison lays out his stack: Simon Willison.

• For a realistic take on AI in the editor, Leon Mika’s hands-on review is worth a slow read: Leon Mika.

• And if you want a longer rumination about the web-first world and its costs, read the essay from dorinlazar.ro.

Small, useful takeaways I kept repeating in my head

1. Perceived speed often matters more than raw speed. A spinner or smooth placeholder can change how people feel about navigation. That sticky feeling sticks with you — like putting on a warm jumper on a cold day.

2. Don’t reinvent the request cache. If your app is hitting the same endpoints from multiple places, centralize the logic. It’s like sharing a carpool instead of everyone driving separately.

3. Use browser APIs for small wins. Speech, vibration, page visibility — these are cheap to experiment with and can pay off in polish.

4. Interop needs rules. If you use Elm or a similarly opinionated tool, respect the boundary. The code will be simpler and more robust.

5. AI tools are helpers, not replacements. Expect rough edges and be picky about workflow fit.

A small digression: why these tiny posts matter

I know it’s easy to skim and say these are small things, but the internet is long. A tiny tweak — an idea about caching or a neat API trick — can save a week of debugging when it lands in your app. It’s like a neighbor telling you a shortcut through a back alley. You might not follow it every day, but when you do, it’s a real time saver.

There’s also the cultural bit: hobbyists keep the web weird and interesting. The Dangerous Dave game or the Windows 7 benchmark remind you that people build for joy sometimes, not just product metrics. That creativity feeds back into tooling and best practices in a quiet way.

If you want more detail on any of these riffs, the authors’ posts are each compact and link-rich. Skim the code snippets, try the demos, and maybe steal a trick or two. You’ll find the deeper instructions there.

That’s the lot for this week. Some practical fixes, some opinionated essays, and a few toys. If nothing else, there’s enough here to poke at over a cup of tea or while you wait for a bus — both good places to tinker in my book.