Microdependency Hell: The Cost of Package Culture

Sun, 17 May 2026 00:00:00 +0000

One thing I highlighted in my almost as an afterthought: the Rust binary ships with no runtime dependencies. Download it, run it, nothing to install. The more time I spend across C/C++, Rust, and Godot, the more that property looks less like a convenience and more like a design goal worth chasing on purpose, because the alternative has a cost.

The incident

A perfect example in the JavaScript ecosystem is what happened on March 22, 2016. Azer Koçulu published a small npm package called left-pad, 17 lines that padded strings on the left. When Kik Messenger wanted the package name kik for their own use, npm sided with the company and transferred ownership away from Koçulu. In protest, he unpublished all 273 of his packages. When left-pad vanished, Babel and React Native broke. Thousands of projects at Facebook, PayPal, Netflix, Spotify and many others stopped building. Not because of a sophisticated attack. Because a justifiably angry maintainer deleted code he had written for free.

How the ecosystem got here

npm hosts over 4 million packages, not a measure of creativity, but of incentive. Each package is its own GitHub repo, its own resume line, and its own download counter. The ecosystem rewards fragmentation, because each successful package is a credential with a counter attached, and the ecosystem has never learned to care what the counter is counting. The result is packages like is-odd, which checks whether a number is odd, depending on is-number, depending on kind-of. Three packages, three maintainers, three supply chain entry points for a question you can answer in one line. A typical React or Next.js app pulls between 1,200 and 1,800 transitive dependencies. No human reads them. When I’m building something in Godot, I don’t npm install physics, the engine ships with it, one curated trust boundary maintained by a team. That contrast is hard to unsee.

The real risk

Tools like Snyk scan for known vulnerabilities, by definition, ones that have already burned someone else. What they don’t catch: a package three levels deep maintained by someone who hasn’t logged in years, whose npm account gets taken over by an untrusted maintainer, who publishes a new version with a helpful postinstall script that reads your environment variables. This isn’t hypothetical. In 2018, event-stream was handed off to a stranger who volunteered to help, then used that access to exfiltrate Bitcoin private keys, downloaded 2 million times a week for two months before anyone noticed. In 2022, the maintainer of colors and faker pushed a self-sabotaging update as a protest. No hack, no zero-day. A maintainer in a bad mood, 20 million weekly downloads, production builds broken overnight. These aren’t bugs in the trust model. They are the trust model.

The correction

Sindre Sorhus, the person more responsible than anyone for the small-modules culture, now publicly argues for fewer dependencies and bigger standard libraries. Node already added native fetch, a test runner, and SQLite without a single install in the last few years. The platform is starting to absorb what fragmentation spread. The instinct to keep surface area small, to understand what runs in your process, isn’t NIH (Not Invented Here) syndrome. It’s engineering. The JavaScript ecosystem spent 15 years treating it as optional. The supply chain incidents are the cost.

From a Forgotten Python Script to a 2500x Faster Rust Tool: The Evolution of PNGToSVG

Sun, 19 Apr 2026 00:00:00 +0000

I just wanted to share the story behind a tool I’ve been working on called . As you can probably guess, it converts PNG images into SVG vectors.

The project started back in 2019 as a small Python script I wrote for a frontend job. Sometimes we needed to work with SVGs, and I just wanted a quick way to convert images locally without uploading them to some random remote service. When I switched jobs, I took that code, tossed it onto GitHub, and completely forgot about it.

Fast forward five years. Out of nowhere, a contributor (“Kartik Nayak” on GitHub) made the first Rust implementation of the tool. A few months later, someone else (“Salman Sali”) jumped in and improved it by adding parallelization.

This was late 2024. Seeing the community breathe new life into my old script blew my mind and gave me the perfect excuse to dive in and learn Rust myself. Since then, I’ve been rewriting, polishing, and tweaking the tool, focusing heavily on ease of use and performance.

What used to be a sluggish script that took a couple of seconds to process a tiny 64x64 icon can now chew through 8000x8000 images in a fraction of that time. To put this performance leap into perspective, I ran a benchmark using a relatively complex ~900KB image.

Here is how the evolution of the project looks:

Version	Time (Seconds)	Relative Performance	Speedup Strategy
Python (Legacy)	1,124.14s	100% (Baseline)	Original implementation
v0.4.0 / v0.4.1	~24.50s	~2.18%	Initial Rust Port (O(n) lookups)
v0.5.0	1.15s	0.10%	O(1) Hash-Set Optimization
v0.6.0	0.43s	0.04%	Memory Reuse & Direct IO

Going from over 18 minutes in the original Python implementation to under half a second in Rust represents a massive ~2580x speedup. But the numbers only tell half the story. Translating this project into Rust became an amazing learning exercise, and the technical journey went roughly like this:

Phase 1: The Rust Port (v0.4.x): Moving to Rust gave us a huge baseline boost (about 45x faster than Python), but the code still relied on linear searches for neighbor lookups, which struggled under the heavy weight of complex paths.
Phase 2: The Breakthrough (v0.5.0): As I learned more, I realized we could replace vector-based neighbor checks with O(1) Hash-Set lookups. This single change killed the quadratic scaling bottleneck and dropped processing time from 24 seconds to just 1.1 seconds—a 20x jump just within the Rust codebase.
Phase 3: Total Efficiency (v0.6.0): Finally, I focused on memory efficiency. Instead of constantly allocating new structures for every shape, we now reuse memory buffers, read pixel data directly via raw buffers, and use sorted edge lookups to trace shapes.

Recently, I published the latest release (v0.6.1), which polishes a few rough edges and includes a shiny new (and very “programmer art”) icon, hahaha. Since then, I’ve received plenty of feedback from the community. Based on that, I’m already planning the improvements for v0.6.2, as well as a v0.7.0 release (which will include some breaking API changes, hence the version bump).