JavaScript: Weekly Summary (December 29 - January 04, 2026)

I’d describe this week in JavaScript blogs as a messy, useful kitchen. People moved things around, tested a few recipes, and wrote sticky notes about what worked. Some posts are about tightening screws on things you already have. Others are about ripping out a counter and installing a new one — and yes, there are a couple of folks who found screws where a bolt should be. To me, it feels like a week where the web kept being both a toolbox and a living room you keep fixing while guests are over.

Small libraries and custom elements — making pieces behave

There are two posts that kept bouncing off each other, both from Heydon Works. One is a how-to about dynamically installing custom elements, and the other digs into when and how to use super in class-based custom elements. They’re like two sides of the same coin. One talks about the plumbing, the other talks about how to write the pipes.

The dynamic install piece is practical and hands-on. It walks through naming conventions, defining elements, and how to handle dependencies when elements show up after initial load. The author leans on MutationObserver as the tool of choice for elements that get appended later. There’s a clear urge to avoid brittle setups — the kind that break when a small file loads a fraction later — and to aim for architecture that behaves predictably. I’d say the post reads like someone who’s tired of chasing race conditions at 2 a.m. and decided to put anchors in place.

The super-focused post is almost a small sociology lesson about inheritance in custom elements. It clears up a few confusions: when you actually need to call super() and when it’s okay to use super outside the constructor. There’s an insistence that inheritance is not a bad word here. Instead, it’s framed as a tool to make libraries smaller and easier to maintain. To me, it feels like advice from a neighbor who’s fixed a leaky faucet three times and finally figured out a proper wrench.

Read both if you work with web components. They’re short, but they point at little traps. They’re like instructions that tell you not to tighten a screw the wrong way.

Rewrites, site maintenance, and the itch to modernize

David Brownman wrote about yet another site rewrite. If you’ve ever rebuilt a site because “it felt five years old,” you’ll nod along. His history runs from static HTML, to Ruby, to Gatsby, and now Astro. That trajectory is a good snapshot of how many of us move with the tooling: we chase ergonomics, build times, and what feels modern.

The write-up is not a boast. It’s more like a confession that rewrites are painful but sometimes necessary. David lists trade-offs and small practical wins: build speed, developer experience, and maintenance costs. He’s pragmatic about the time sunk into older stacks and the relief that comes from pruning cruft. I’d say it reads like someone who finally cleared out their garage and is showing you the tidy shelves.

This ties into a recurring theme across several posts: maintenance matters. Not the glossy, blog-post kind of maintenance that gets turned into a tweet, but the everyday stuff — cache headers, hosting quirks, dependency updates, and the small scripts people rely on. It’s the background rhythm of web work.

Tools for scraping, hosting, and tiny utilities

Simon Willison had a couple of interesting, tiny-tool posts this week. One is about shot-scraper 1.9. The release adds an extract flag to pull resources out of pages during scraping, and it updates compatibility with the latest Playwright. That’s the sort of change you don’t notice until you need it, and then you really need it. The author frames the tool for things like taking screenshots and basic digital forensics. I’d say it’s a reminder that a good CLI can save you hours.

The other Simon post describes a forked project, gisthost.github.io, based on gistpreview.github.io. He explains how gist rendering works, HTTP headers, and file-size limits — then shows how his fork addresses URL handling and size issues. It’s nerdy in the best way. If you ever shove HTML into a Gist and expect it to behave, this is the post to skim. It explains why sometimes a tiny hack is better than a bigger tool, and how a small fix can unblock a whole workflow.

Peter Rukavina’s Bookbinder JS is a different sort of utility. It’s an app for binding PDFs into books for imposition printing. That’s niche and oddly satisfying. The post is straightforward: here’s a tool that turns PDFs into printable signatures. It’s aimed at people who actually print and bind. If that’s you, it sounds like a neat piece of kit. If not, it’s still a reminder that JavaScript isn’t just for flashy UI — sometimes it’s for making physical things behave.

From web to native — SvelteKit + Capacitor

Bryan Hogan walked through turning a SvelteKit web app into a native mobile app using Capacitor. The guide covers project setup, adding platforms, live reload, and hosting advice. It feels like a pragmatic “do this, then this” walkthrough rather than a theory manifesto. I’d describe it as the kind of how-to that helps someone who’s already got a site and wants to ship it as an app without learning a bunch of native mumbo-jumbo.

There’s a smell of convenience here. The idea that you can take your web code and wrap it into a native experience is comfortable, like putting a sweater on a plant to protect it from frost. But of course there are trade-offs. The post nudges you to think about hosting and asset serving in the context of mobile, and to consider native nuances you might otherwise ignore.

Performance chatter — the surprising speed of for...of

Suren Enfiajyan ran some benchmarks that felt slightly like a friendly bench race. The subject: are JavaScript for...of loops actually fast? The answer is nuanced. For many years, classic indexed loops were the speed king. That still often holds true. But for...of has improved, and in some cases it’s nearly as fast. The post tests different array shapes and sizes and shows where for...of catches up and where it still falls short.

The takeaway isn’t a soundbite. It’s more like: know your data, test in your environment, and don’t make micro-optimizations unless you have to. I’d say the post is a practical reminder not to let a performance article become dogma. Treat it like a map, not a law. Also, if you’re a bit obsessive about loops, you’ll love the graphs.

Small wins in content presentation — related posts on Blogger

There’s a Turkish post by İsmail Şevik about adding a "Related Posts" feature to Blogger using CSS, HTML, and JavaScript. It’s the kind of post that helps people who host on legacy or low-tech platforms. The code is shared with explanations about how the widget looks and works. It’s modest, but useful.

This is a reminder that a lot of JavaScript work is about small user-facing improvements. Not every story is about frameworks or crazy build setups. Sometimes it’s about making a blog feel a bit smarter and keeping people reading. That’s low-effort and high-value in many cases.

The ethics and friction of modern browsing

Nicolas Magand takes a different tone. His piece is a personal reflection on web browsing setups, content blocking, and the ethics of ad blocking. He talks about StopTheScript and the constant tension: blocking scripts improves speed and privacy but can also hurt publishers and break functionality. He admits to wanting a more disciplined approach.

It reads like a late-night thought: you close the laptop and realize you’ve been letting scripts run everywhere. The author doesn’t drop a prescriptive answer. Instead, it’s a confessional and a nudge to be mindful. I’d describe it as a tiny moral argument wrapped in browser preferences.

There’s a through-line with other pieces: small choices matter. Whether you’re deciding how aggressively to block third-party scripts, or whether to dynamically import a custom element, those choices ripple outward. The ethics post highlights that ripple on the user side.

Patterns I kept seeing

• Maintenance and rewrites: A few posts showed the fatigue and relief that come with rewrites. David’s site story is a classic case. People keep redoing things not for the fun of it, but because of build times, ergonomics, and the mental weight of old configs.

• Small, pragmatic tools: Simon’s work on CLI tools and gist hosting, Peter’s Bookbinder JS, and Bryan’s SvelteKit/Capacitor guide — these are all about doing something specific well. No grand frameworks, just tools that shave hours off a workflow.

• Components and dependencies: Heydon’s two posts put the spotlight on predictable component behavior and the little rules (like when to call super) that keep libraries manageable. There’s an insistence that small API choices matter long-term.

• Real-world performance: Suren’s benchmarks remind us that speed talk needs context. The engine keeps changing, so yesterday’s advice might not be as strong tomorrow.

• User-level ethics and control: Nicolas’ take on ad blocking shows a human side to what otherwise looks like a technical conversation.

You see agreement and gentle tension. Most authors want things to be maintainable and simple. But they differ on what that looks like in practice. Some favor lightweight tooling and fewer layers. Others tolerate more complexity to get features or convenience. I’d say everyone’s aiming for the same spot on the compass, just traveling different paths.

Little disagreements and tiny debates

There aren’t any headline-grabbing feuds. But some small differences of opinion are visible if you read between the lines. For example:

• For-of vs indexed loops: Suren is careful. For-of is better than it used to be, but indexed loops still often win. The tone is “don’t assume.” Implicitly, that nudges against blanket recommendations to always prefer one style.

• Inheritance vs composition in custom elements: Heydon leans into inheritance as useful, not frightening. That nudges against some modern trends that push composition as the only sane route. It’s not a loud debate, but the subtext matters for library authors.

• Rewrites: David’s rewrite story is practical and frank. The implicit counterpoint you sometimes see online — “never rewrite, only refactor” — is not present. David accepts rewrites as a sometimes-necessary evil. That’s a small but honest stance.

These are not battles. They’re trade-offs, and the authors are telling you why they made certain calls. That’s more useful than a declarative argument.

Who might want to read which posts

• If you maintain a set of web components or a design system: start with Heydon Works. The posts are focused and give specific tactics for real problems — naming, dependency handling, and when to use super in classes.

• If you run or keep a site alive and sometimes feel the itch to rewrite: read David Brownman. It’s honest and practical, not a brag about fast builds.

• If you do scraping, screenshots, or need a small CLI to automate forensic-like tasks: peek at Simon Willison. shot-scraper’s new extract option is small but handy.

• If you need to host HTML in Gists or tinker with tiny hosting quirks: Simon’s gisthost post walks through real-world limitations and fixes.

• If you’re building a mobile wrapper around a web app: Bryan Hogan gives a straightforward how-to with SvelteKit and Capacitor.

• If you’re curious about JS micro-performance and loop choices: Suren’s benchmarks are worth a slow read. The graphs show where for-of is fine and where classic loops still matter.

• If you run a Blogger site and want a related-posts widget without a heavy CMS: İsmail Şevik provides code to copy and tweak.

• If you care about the ethics of blocking content and want to think through a personal setup: Nicolas Magand writes like someone talking to a friend about habits.

Small practical notes and curiosities

• MutationObserver keeps popping up as the go-to for handling elements inserted after load. It’s useful, but it can become noisy if used without throttling. Think of it like a smoke alarm — great to have, but annoying if it goes off every time you toast bread.

• The super() discussion is quietly important. Small mistakes there lead to weird inheritance bugs. Calling super at the right time is like giving the dog his breakfast before taking him for a walk — timing matters.

• For folks packaging web apps for mobile, the live-reload setups people share are worth stealing. They save time. But remember, the hosted assets still need to be treated kindly; mobile packaging can mask latency issues until you ship.

• CLI tools keep getting better at covering edge cases. The new shot-scraper extract flag is a good example: it’s not sexy, but it handles situations that used to require duct tape and patience.

A small tangent about nostalgia (that connects back)

There’s a faint vein of nostalgia in several posts. David’s history of rewrites recalls static HTML days. Simon’s work with Gists has a tinker-y vibe that echoes the early web. Even the Blogger widget feels like a throwback to DIY blogging. But that nostalgia isn’t purely sentimental. It’s practical. People miss simplicity and the direct control that came with simpler stacks. They’re trying to get some of that back while keeping modern conveniences.

This is where the theme of trade-offs really lands: you can have a sleek modern dev experience, or you can keep things tiny and hand-controlled. The posts this week are mostly about finding the middle path.

If you want to dig in, the posts are short and focused. They reward a careful skim and a click or two. If you like hands-on fixes, you’ll find little gems. If you like big-picture arguments, there are hints and perspectives to chew on. The web keeps being both a toolbox and a living room, and this week’s posts help tidy both.

Go read the posts if you want the code samples and step-by-step bits. They’re worth a look. The links are right there with the authors’ names.