{"id":301,"date":"2025-01-30T09:00:05","date_gmt":"2025-01-30T09:00:05","guid":{"rendered":"https:\/\/redmonk.com\/kholterhoff\/?p=301"},"modified":"2025-01-31T23:57:24","modified_gmt":"2025-01-31T23:57:24","slug":"is-npm-enough","status":"publish","type":"post","link":"https:\/\/redmonk.com\/kholterhoff\/2025\/01\/30\/is-npm-enough\/","title":{"rendered":"Is npm Enough? Why Startups are Coming after this JavaScript Package Registry"},"content":{"rendered":"

\"\"<\/p>\n

There\u2019s been significant disruption in the JavaScript package management space recently. While npm continues to be the de facto JavaScript 1) package registry and 2) package manager used in Node.js runtime environments, it is worth discussing how these shifts factor into the larger Problem of JavaScript Code Delivery<\/a>. Specifically, I am thinking of the recent appearance of Deno\u2019s JSR (the JavaScript Registry) and vlt\u2019s vsr (vlt Serverless Registry). Deno markets JSR as an \u201copen-source package registry for modern JavaScript.\u201d It was developed by Ryan Dahl<\/a>, creator of the Node.js JavaScript runtime and Co-Founder & CEO of Deno, and has some<\/a> good<\/a> momentum<\/a> within the JS community. Meanwhile vsr has also been generating some buzz since it debuted<\/a> in November 2024 at NodeConf EU in Ireland. The folks at vlt position vsr as offering \u201ca streamlined, privacy-first environment for private development and seamless distribution.\u201d Created by Ruy Adorno<\/a>, Darcy Clarke<\/a>, and Isaac Schlueter<\/a> (the creator of npm), vsr is looking to make inroads on the space. Both Deno and vlt have deep DNA in the Node and npm space, and both are entering the package registry space by way of package management\u2014let\u2019s talk about why.<\/p>\n

 <\/p>\n

Package Managers<\/h2>\n

So what even is a package manager? Software packages are archived files that include a computer program along with metadata needed for its deployment. Package managers find, install, maintain and uninstall software packages. They also manage information on software dependencies and versions to avoid compatibility issues and missing requirements. While computer operating systems call for managers like Linux\u2019s Yellowdog Updater Modified (YUM), Debian Linux\u2019s dpkg, Arch Linux\u2019s pacman, Windows\u2019s WinGet, and macOS\u2019s Homebrew, software app developers require managers to handle packages necessary for building applications.<\/p>\n

RedMonk has been following<\/a> package<\/a> management<\/a> forever<\/a>, but what has only become more true in 2025 is that building modern applications requires pulling down and managing a boatload of dependencies. Running the command npm install in the CLI for a React Native project, for instance, can add close to 1,500 dependencies<\/a> to the package.json file. What is more, these dependencies often have their own dependencies. This heaviness is not exclusive to JavaScript and TypeScript applications, but has been a sticking point in the SPA wars<\/a>. JS has a bias to feature development. Setting aside the question of whether all of these dependencies are necessary, even the most pared down applications have enough packages that a third party manager becomes essential. Managers like npm (JavaScript), CPAN (Perl), PEAR (PHP), and PyPI (Python), all promise to simplify dependency management. Which brings us to the entwined subject of package registries.<\/p>\n

Because package managers are responsible for pulling down external repositories, they must integrate tightly with software repositories like GitHub, GitLab, and BitBucket that store code. They also depend upon package registries to publish and share these packages. It is unsurprising that GitHub<\/a> and GitLab<\/a> offer package hosting as a service. Packages, after all, are just code that is published and consumed in a particular manner.<\/p>\n

 <\/p>\n

Managing the JS Ecosystem<\/h2>\n

In the JavaScript (JS) ecosystem, package managers are clients to and limited by npm’s Public Registry API\/ infrastructure. Whoa, whoa, whoa, Kate. I thought you said that vsr and JSR were going to replace npm!? Nope. While all registries facilitate publishing and sharing code, today, for complex technical reasons relating to dependencies, ecosystem lock-in (CI\/CD pipelines, workflows), integration with the Node.js runtime, and framework interdependency issues (React, Angular), there are few if not zero alternative JS registries to npm. This means that the Bun runtime, pnpm (Performant Node Package Manager), and Yarn (a JS package manager for the Node) all use the npm registry. Today JSR and vsr are both essentially npm-compatible layers. According to the JSR website<\/a>: \u201cJSR isn’t a replacement for the npm registry; it’s a superset of npm.\u201d Although the vlt team is marketing<\/a> vsr as a \u201cdrop-in replacement for your existing package manager\u201d (presumably npm), like JSR, vsr does not replace the npm registry but instead offers privacy and a more optimized developer experience through additional features such as \u201cdependency query selector syntax, export formats (including Mermaid) & GUI experience to help lower the bar for understanding your dependency graphs.\u201d<\/p>\n

\n

Holy crap! Vlt \u2014 the new JavaScript package manager \u2014 just announced Isaac Schlueter is on the team. <\/p>\n

Isaac is the creator of npm.<\/p>\n

So now we have the guy who made Node working on JSR, and the guy who made npm working on vlt.<\/p>\n

exciting times https:\/\/t.co\/W6h1qctdr6<\/a><\/p>\n

— Wes Bos (@wesbos) March 20, 2024<\/a><\/p><\/blockquote>\n