But Do We Really Need More ’left-pad’s Anyway?; What, No Fire?; It’s Always DNS

Before heading into the sections, I have one more Drop “plug” for Grist. I recently moved it off local OrbStack containers on my Macs and centralized it on the homelab dev server. It’s so useful, and way nicer to work in than gSheets, O365 Excel, or Numbers.

Today, we look at three radically different kinds of “sources”.

---

TL;DR

(This is an LLM/GPT-generated summary of today’s Drop. This week, I continue to play with Ollama’s “cloud” models for fun and for $WORK (free tier, so far), and gave gpt-oss:120b-cloud a go with the Zed task. Even with shunting context to the cloud and back, the response was almost instantaneous. They claim not to keep logs, context, or answers, but I need to dig into that a bit more.)

• The referenced article questions the future of tiny npm packages like blob‑util in an AI‑driven development world, referencing Nolan Lawson’s post on small‑open‑source projects (https://nolanlawson.com/2025/11/16/the-fate-of-small-open-source/)
• This section highlights Brimstone, a Rust‑written JavaScript engine achieving 97% ECMAScript compliance with its own parser, bytecode VM, and compacting GC, linking to the project repository (https://github.com/Hans-Halverson/brimstone)
• The referenced article explains how DNS lookups add hidden latency to modern sites and recommends using dns‑prefetch, preconnect, and preload, citing Alex MacArthur’s detailed guide (https://macarthur.me/posts/dns/)

---

But Do We Really Need More ’left-pad’s Anyway?

(RE: ‘left-pad’. Also, this was something shared to me at $WORK vs. me finding it on the internets.)

“AI” is killing many things, but I never pondered what Nolan just pondered, and I feel like that take is probably warranted.

For anyone who has used or still uses coding assistants, you likely know (even without consciously knowing) that they are tediously verbose. They constantly reinvent the wheel, adding in helper methods/functions that exist in the wild in packages across every programming language ecosystem.

Nolan has a ten-year old JS package — blob-util — that’s handy when working with JS ArrayBuffers. His post is based on the assertion that use of said package will likely be in decline, since so many developers are using “AI”-assissted tooling. Rather than pull from solid, working code (which does create a dependency), Claude (et. al.) will probabilistically manifest bespoke code instead.

As Nolan notes:

“I suppose some people would see this as progress: fewer dependencies, more robust code (even if it’s a bit more verbose), quicker turnaround time than the old “search npm, find a package, read the docs, install it” approach.”

So, where’s the incentive to build tiny packages if they’ll just collect dust in CRAN, PyPI, Crates, or NPM?

Nathan’s post goes into that, and more. Plus there are some really good comments. It’s worth the (short) reading time.

I, for one, will still make focused, small packages in Go, JS/TS, and R for as long as I can input text into an editor.

---

What, No Fire?

Longtime Drop fam know I am the dude in that meme who’s walking with one JS engine but will gladly turn my attention to new ones that pop up, especially if they’re Rust-based.

Brimstone fits that description and was clearly built by someone (Hans Halverson) who loves the craft (of both Rust and JS). It’s a from-the-ground-up JavaScript engine written in Rust, and despite being labeled “not production-ready,” it’s already hitting over 97% compliance with the ECMAScript test262 suite. That alone puts it in rare company.

While anyone can brag about a compliance score, the whole thing is engineered in a much different way than many other contenders. Instead of leaning on existing parsers or regex engines (or even garbage collectors), Brimstone reimplements nearly everything itself, with the only major dependency being ICU4X for internationalization. Did I hear someone way “modern systems project with an almost old-school hacker ethos?” I’m in, if so.

The foundation of Brimstone is a bytecode virtual machine modeled after V8’s Ignition interpreter. It compiles JavaScript into bytecode instead of interpreting the AST (abstract syntax tree) directly or emitting native code, landing in that lovely middle ground between performance and complexity. Beneath that lives a compacting garbage collector (GC) written in what the author cheerfully describes as “very unsafe Rust,” because moving GC algorithms simply can’t be done within the guardrails of borrow checking. That design choice alone says a lot about the ambition level here, as one usually reserves compacting collectors for mature engines, not early-stage personal projects. The fact that Brimstone has its own parser, its own RegExp engine, and nearly all ECMAScript built-ins implemented to spec paints a picture of a developer deeply interested in how things actually work.

Security and research folks should take a look at this project since it’s a clean-slate implementation that’s making great choices out of the gate. Alternative JS engines are also fantastic tools for probing whether a bug or exploit technique is tied to quirks of V8 or SpiderMonkey, or whether it’s rooted in the language semantics themselves. A Rust-based engine also shifts the vulnerability landscape; while the GC necessarily dips into unsafe territory, you avoid whole classes of memory hazards that come with large C++ codebases. Beyond that, a lightweight, embeddable engine like this could eventually serve as a scripting layer inside Rust applications without dragging along the complexity of V8.

Brimstone does not seem to be trying to replace production engines. I think it’s more offering a deeply educational, thoughtfully architected alternative. There are missing pieces, like SharedArrayBuffer and Atomics, which are mostly related to parallelism, meaning everyday single-threaded code runs just fine. For now it’s a tool for learning, experimenting, and embedding, but the level of engineering on display hints at a future where Rust-based JS engines are more than curiosities. Brimstone might just be the one that blazes that trail.

---

It’s Always DNS

(This 100% counts as “source” since you’re using DNS as a source for name resolution.)

Most front-end developers have spent enough time staring at waterfall charts to know where the big, ugly delays are. But tucked between the obvious culprits such as images, scripts, and chunky style sheets, there’s a quieter tax you pay over and over: DNS lookups. They’re quick on their own, usually just a few dozen milliseconds, but modern sites talk to a small village of domains. This post by Alex MacArthur highlights cases where 5–12 domains added up to a couple hundred milliseconds of pure DNS overhead. Nothing catastrophic, but enough to make a snappy site feel a hair sluggish.

You can 100% just head over there vs. read my summary, since Alex has some super cool diagrams and examples I will not steal.

If you’ve stuck around here, great!

Shaving off some precious milliseconds is where dns-prefetch comes in, and the trick is that it’s most valuable not for your obvious external resources, but for the ones the browser can’t see coming, like the analytics script that fires on click, the CDN image that loads on scroll, or the (ugh) ad network called only if the user behaves a certain way. Because these requests aren’t in the initial HTML, the preload scanner can’t prepare for them. A speculative dns-prefetch lets the browser resolve the domain early as a low-priority background task. When the JavaScript finally triggers the network fetch, the DNS step is already done, and that little blue bar in the waterfall quietly disappears.

Of course, dns-prefetch is just one tool in a small but potent hierarchy. If you know you’ll definitely hit a domain soon, preconnect warms up the whole handshake (DNS, TCP, TLS) at a higher cost. And if there’s a specific resource you need as early as possible, preload is the heavyweight option that fetches the entire thing up front. The trick is choosing the hint that matches your confidence level. Guessing wrong can mean wasted work or even duplicate downloads, especially with preload’s unforgiving insistence on exact URLs.

Where this pays off is in sites with sprawling third-party dependencies or dynamic loading patterns: e-commerce platforms pulling from multiple CDNs, media sites relying on analytics vendors, ad-supported pages triggering unpredictable domains. You’re not saving seconds here, but you are tightening the bolts on the places the browser can’t optimize for you.

---

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

☮️