Deno De-emphasizes HTTP Imports

I’ve been a long-time fan of Deno and their ethos of following the web platform. But I’m not sure how I feel about their latest admission which makes their dependency story more like npm and less like the web.

Designing Deno’s module system around HTTP imports was ambitious. It aimed to replace npm with a distributed system over HTTP, aligning with how ES Modules work in browsers. This eliminated the need for package.json files and node_modules folders, simplifying project structures. Deno scripts could scale down to single-file programs without a project directory or configuration.

Deno’s HTTP imports were one of my favorite features! But alas, it seem the dream is dead. Or rather, there were trade-offs.

One trade-off to HTTP imports was decentralization^[1], which by definition entails a lack of centralized control. But, when you can’t control the end-user experience of your product, your brand suffers even when it’s not your fault.

It seems this began happening to Deno where folks pointed their module dependencies at a variety of hosts and any poor performance from a third-party was a perceived poor performance on the part of Deno.

while Deno ensures high availability for its deno.land/x registry, it can’t control other hosts, making overall availability dependent on the least reliable host in your dependency graph.

So Deno ends up being perceived as problematic by end users, but the reality is it’s working precisely the way it was designed to, which cedes control of module availability and reliability to third-parties.

Decentralization is a great philosophical idea, but if you can’t control brand, image, and experience — especially as a startup on venture money^[2] — that’s not good for business. (Decentralization is a terrible way to centralize making money.)

To fix this, Deno made a new registry (JSR) and now their story for modules de-emphasizes module imports via URLs:

JSR for sharing modules instead of random file servers.

While I can understand this decision from a certain product perspective, I don’t understand it from the “align yourself with the web platform” ethos Deno originated from.

If you want to be like the web, serving files from random file servers is about as close as you can get^[3].

I like Deno’s original philosophy and, at least for now, you can still import from URLs. But there are caveats, as David Bushell thoroughly points out.

Maybe it’s a good product decision? I don’t know. My feelings are inline with Baldur on this:

Focusing on node compatibility might look on paper like a good strategy for adoption, but it both sabotages your own ecosystem and condemns you to forever follow, not lead, node

I don’t doubt it’s what people want. npm-style package names are familiar (devs love familiar), and even more they’re terse (devs love typing less). I don’t know if there are two things developers love more than that.