JavaScript: Weekly Summary (November 03-9, 2025)

I spent some time reading the small pile of posts about JavaScript this week. There’s a clear mood to them. Some are quietly tired of JavaScript doing everything. Some lean into its power, carving out new use-cases. Others are tiny tools and fixes — little things that keep people sane. I would describe them as a mix of thrift, tinkering, and a bit of caution. To me, it feels like a neighbourhood where a few people are renovating with careful hands, while others are ripping out walls and wiring new rooms.

The lean side: less JavaScript, more browser

A couple of posts quietly cheer for doing less JavaScript. Thomas Hunter II writes about htmx after building RFC Hub. He’s been around the block. He’s used full-stack, single-page, server-rendered, you name it. And htmx, he says, let him build a CRUD app without the typical JavaScript scaffolding. Sounds a bit like using a good old kettle instead of some trendy espresso machine. You still get hot water. You still get coffee. But you didn't buy an alchemy set.

I’d say the main win here is simplicity. htmx moves bits of interactivity back to the server and to HTML responses. That reduces the amount of client-side state to juggle. It’s appealing if you want less JavaScript but still want snappy forms and partial page updates. Thomas points out limits too. It can lean on HTTP response headers to decide UI behaviour. That’s not always neat. It’s like trying to navigate by the stars on a cloudy night — possible, but awkward.

Then there’s Jeremy Keith arguing against the Not-Invented-Here habit in frameworks. He’s blunt about it: sometimes you reach for a big tool when the browser already has what you need. He nudges developers to use built-in features more and to avoid splicing a framework into everything. To me, it’s the same tune as a neighbour telling you not to hire a plumber when you just need to unclog the sink with a plunger. Jeremy’s point hits a recurring theme: the browser has gotten clever, and leaning on that cleverness can save time and speed things up.

Dariusz Więckiewicz(/a/dariuszwickiewicz) also fits this theme but from the CSS angle. He moved a JavaScript color-theme switcher to a pure HTML/CSS solution. He uses new CSS like light-dark() and color-scheme. The result? Less JavaScript to maintain and fewer spots for bugs to hide. He keeps a backward-compatible fallback for old browsers, which feels practical and thoughtful. I would describe that move as tidying the toolbox — keep the axe, but stop using it to hammer nails.

There’s repetition here because people keep circling back to the same idea: use the platform more. Use htmx. Use modern CSS. Use browser features. You’ll hear it in a few posts. It may seem obvious, but seeing concrete examples helps. It’s like when someone finally shows you a trick for peeling garlic in one swing. You think, why didn’t I do that before?

Native APIs and the messy middle

Not everyone is celebrating the platform. Some posts remind you that built-in APIs can be helpful but also riddled with browser quirks.

Christian Ekrem revisits the Clipboard API and asks a blunt question: how did something so seemingly simple get so complicated? Support is patchy. Permissions behave differently across browsers. Safari remains a puzzle box. Christian’s write-up has a weary tone. He points out that while modern APIs look tidy on paper, real life gives you edge cases and weird permission prompts. It’s like buying a new phone and discovering your favourite app won’t run on it. The post doesn’t just complain. It traces the history and gives context. It’s the kind of piece that nudges you to test across browsers, and then test again.

That theme — new features plus real-world friction — shows up in Michał Sapka and reader.tymoon.eu(/a/readertymooneu) who both describe Anubis, a defensive measure to slow down aggressive scraping. Anubis depends on modern JavaScript features. The idea is to make scraping expensive by requiring a Proof-of-Work response and modern APIs. The interesting twist here is the arms race angle. You need modern JS to block scraping at scale, but requiring modern JS also risks breaking things for regular users on older browsers or weird environments. It’s a trade-off. It’s like installing a new security gate that also makes it awkward for your elderly neighbour to enter.

Morphing DOM and keeping state intact

A different technical rabbit hole appeared: DOM morphing. Joel Drapper introduces Morphlex 1.0. This is a focused answer to a real pain: how to update the DOM without losing user state — for example, caret position in an input during a re-render. Morphing aims to change the structure but preserve the identity of nodes when it makes sense.

Joel’s solution feels thoughtful. He zeroes in on the node identity problem. Morphlex matches nodes using an algorithm and keeps the state where it matters. It’s like swapping the engine of a car while keeping the driver in place. The driver doesn’t notice the change, and that’s the victory.

There’s a performance angle too. Morphlex claims improvements over other libraries. But the larger idea is that manipulating the DOM doesn’t have to erase user interactions. That’s important. It’s also one part of the broader conversation about whether to use full frameworks or smaller, precise tools.

Embedding JavaScript and running untrusted code

This week also had some deeper technical reads about JavaScript as an extension language. Andrew Sampson writes about Hako, a JavaScript engine built on QuickJS and designed to be embedded safely. The key problems Andrew raises are real: JavaScript engines can be heavy to bind, and security matters if you’ll run untrusted code.

Hako’s approach uses WebAssembly sandboxing and a cleaner foreign function interface (FFI). The idea is to strip types from TypeScript so you can share types safely, yet keep a tidy, secure boundary. This is a different kind of “less JavaScript” argument. It’s not about writing fewer lines. It’s about controlling JavaScript when you need it as a plugin or extension language. I’d say Hako feels like a locked toolbox. You can still lend someone your drill, but you also keep the keys in your pocket.

Security comes up again when authors talk about automated tooling that touches code. Simon Willison describes upgrading a Datasette plugin to match a new alpha release. He leaned on OpenAI Codex to automate parts of the work. That’s both neat and a little alarming. Neat because it speeds up repetitive fixes. Alarming because when you automate code changes, you still need tests and care. Simon walks through running tests, fixing version mismatches, and using tests as the guardrail. It’s the classic: automated help is useful, but it doesn’t replace human attention.

Small scripts, neat tricks, and the joy of tiny wins

Several posts are tiny but sweet. They remind you that not everything has to be a big framework or a new engine. Sometimes a good snippet does the job.

ReedyBear shared two BearBlog-focused helpers. One grabs RSS markup from the current page. The other is a bookmark script to jump to the edit button for a BearBlog post. Both are practical. They’re the sort of Saturday-afternoon scripts you write when you’re annoyed by a repetitive task. They’re quick wins. I’d describe them as pocket tools — like a small Swiss knife in the back pocket.

There’s also a post on implementing a system-wide custom cursor toggle. The author (Unlisted Retrograde Holdout(/a/unlistedretrogradeholdout@trackerninja.codeberg.page)) offers PUG, CSS, and JS snippets to store user preferences via LocalStorage and cookies. It’s not groundbreaking, but it’s useful for a site with personality. A site with a custom cursor feels like a cafe with mismatched chairs. It’s charming, and a toggle keeps it polite.

And then Micah R Ledbetter(/a/micahrledbetter@me.micahrl.com) wrote about automating GitHub issue searches with a GitHub Action called API Issue Watcher. He outlines improvements — multiple search terms, better JavaScript logic, scheduled runs. This one is the sort of infrastructure piece that makes day-to-day life smoother. People who manage projects will nod at this and then steal parts of the code.

Games, performance, and real-time pain

A more human corner of the week: JSLegendDev asking for help with an RPG made using KAPLAY. The game chugs during battles. The author asks people to test and record gameplay on different platforms. This is the blunt, hands-on problem: performance is visible and unforgiving. Developers may argue about micro-optimizations, but when a player sees the lag, they don’t care what you think — they just feel it.

I liked the openness. Asking for feedback and recordings is a good move. It’s like asking friends to drive your car and tell you which weird noise freaks them out. The post sits in a recurring theme: JavaScript is powerful enough to build games, but it’s also easy to hit platform-specific performance cliffs. There are no silver bullets. You test, you profile, you fix.

Anti-scraping and the modern-JS requirement

Two posts touched the same thing: Anubis, the anti-scraping measure. One from Michał Sapka and a near-duplicate from reader.tymoon.eu(/a/readertymooneu). Both explain the Proof-of-Work approach and the need for modern JavaScript features. It’s interesting because it flips the usual complaint. Sites often bemoan JavaScript complexity. Here, complexity is a shield.

There’s a tension. Anubis will make scraping harder. But it raises the bar for legitimate users on older platforms. It’s a bit like setting up a complicated front door lock to stop burglars and then wondering why the postman can’t get the mail through.

A few small but resonant technical threads

• Testing and automation: Simon Willison’s plugin upgrade and Micah’s GitHub Action show people leaning on automation. Tests are the guardrail. Automation can help, but you still need to look at the results. That’s been a repeating note all week.

• Node identity and preserving user input: Joel Drapper’s Morphlex piece is part of a continuing conversation about how to update the UI without breaking what users are doing. This matters in forms, editors, and any interactive UI.

• Security and sandboxing: Hako and Anubis put security in focus from different angles — Hako to safely embed scripts, Anubis to thwart mass scraping. Both assume modern JavaScript features, which in turn ties back to the question of who you expect in your audience.

• Small utilities matter: From the cursor toggle to BearBlog bookmarklets, small scripts crop up because they solve real friction. They’re tiny, but the people who need them are grateful.

Tensions and agreements

If you squint, you can see two camps. One is conservatory: keep things simple, use built-in browser features, try lighter-weight tools. The htmx and CSS-only posts fit here. The other is pragmatic and experimental: use JS where it’s necessary, build engines for embedding, automate upgrades with AI helpers, and defend your data with modern JS checks. Hako, Simon’s Codex experiments, and Anubis fit that side.

But the camps don’t fight. They talk past each other more than they clash. It’s like two people in a kitchen — one says, let’s make soup with the basics, and the other says, I’m going to experiment with smoke and sous-vide. Both want lunch. Both care about good results.

Small takeaways that stuck with me

• Try not to reach for a framework as the first reflex. Check if the browser already handles it. Jeremy’s note felt like a gentle elbow. Use the right tool.

• Don’t underestimate the trouble of modern APIs. Clipboard is a tiny feature that can crop up with big cross-browser headaches.

• Preserve user state when updating the DOM. Morphing can be clever, but the node identity problem is subtle and worth solving cleanly.

• Embedding JavaScript safely matters more as we trust third-party plugins. Sandboxing and tidy FFIs are good ideas.

• Tiny scripts are still useful. That bookmarklet you write at 2 a.m. might save half your week later.

• Automation helps, but tests save you. Using AI to suggest code changes is handy, but you need to run the tests and watch the results.

A quick tour: who wrote what and why you might want to read it

• If you want a taste of minimal interactivity without a full frontend framework, read Thomas Hunter II on htmx.
• If your site needs small practical helpers for BearBlog, check ReedyBear.
• If your project uses PUG and you want a site-wide cursor toggle, that PUG/CSS/JS recipe from Unlisted Retrograde Holdout(/a/unlistedretrogradeholdout@trackerninja.codeberg.page) is handy.
• If you care about embedding JS safely, or TypeScript as an extension language, Andrew Sampson gives a deeper read.
• If you’re upgrading plugins and want to see a workflow where OpenAI Codex helps, Simon Willison walks it through, with tests and video notes.
• If you deal with forms and interactive UIs, Joel Drapper on Morphlex is something to bookmark.
• If you manage issues and want to automate watching GitHub searches, look at Micah R Ledbetter.
• If you’re building a game and want feedback on performance, try the rough-and-ready note from JSLegendDev and maybe test their build.
• If you’re guarding a site from scraping and want to see a Proof-of-Work approach relying on modern JS, read Michał Sapka and reader.tymoon.eu(/a/readertymooneu).
• If you want a readable dig into the Clipboard API, and why it can be hairier than it looks, read Christian Ekrem.
• And if you want a neat little migration from JS theme switchers to HTML/CSS-only themes, Dariusz Więckiewicz(/a/dariuszwickiewicz) shows how.

Some of those posts are practical, some are exploratory, and some are defensive. They’re short reads that aim to solve one problem each. They don’t bother pretending to be exhaustive manuals. They’re the kind of blog posts you skim over a cuppa and tuck away a tip or two.

A few things kept nudging at me as I read. One: the web platform keeps maturing. That means choices. Two: developers are balancing convenience and control more deliberately. And three: small, focused tools and scripts continue to feel valuable.

If you want to go deeper, follow the links and poke around the examples. The posts are meant to be read with the code open. Many include snippets that will save you time. They’re not polished magazine features. They’re practical notes. They’re little lights on a foggy night.

There’s an openness in these posts that I like. People share fixes. They show mistakes. They admit complexity. It’s not all swagger about the newest framework or the shiniest build tool. It’s people trying to do their jobs better.

So, if your week needs a few ideas — less JS, better polymorphism in the DOM, safer embedding, or just a bookmarklet to save a minute every morning — this week’s small pile of writing about JavaScript has something for you. Read a few. Tinker with the code. And then, later, maybe come back to that kettle versus espresso decision again. It’s fine to change your mind.