Speculations on the Democratization of OSS via Deno and JSR

Introduction

With the release of Deno 2.0 just around the corner, I'm going to write about my hopeful delusion that "Deno and JSR will bring about the democratization of OSS."

This is something I wrote down aimlessly while watching the Automattic vs. WP Engine dispute and feeling down, thinking, "Sigh, is OSS finally reaching its limits?" but then getting energized while playing with the Deno 2.0 RC and JSR. It's a very subjective piece.

What It Means for Deno to Support TypeScript Natively

If you look at the Deno official website, you'll see a huge banner in a prominent place on the top page that says:

Native TypeScript support
The Deno runtime natively supports TypeScript ... (omitted)

(As of October 2024).

Personally, I think this is Deno's biggest selling point and an extremely important point for modern web programmers, but I also feel like this benefit isn't quite being communicated as effectively as it could be.

With Deno, npm install -D typescript is unnecessary, and you can start writing programs in TypeScript immediately without preparing a tsconfig.json. When running the program you've created, there's no need to do things like running tsc and then executing the contents of dist.

This is actually very pleasing. First of all, the lack of overhead and lead time when your motivation to start writing a program is high is always wonderful, and the reduction in execution steps is, of course, very welcome.

On the other hand, I feel that if you simply take this to mean "Native TypeScript support" at face value, you might slightly miss the essence of it.

In short, you might think, "Even with Node.js, I can execute TypeScript code using ts-node or tsx, and if I use Vite (esbuild), I don't really have to be conscious of transpilation, right?" and start wondering what the big deal is about Deno supporting TypeScript natively. As I quoted earlier from the top page of the official site, it also says, "Deno is the open-source JavaScript runtime."

Well, my initial impression was similar to that, but after using Deno for quite a long time, that impression has changed considerably, and that's what I want to convey.

The Package Source Code is TypeScript

In conclusion, this is pretty much all I want to say here. Deno packages are written in TypeScript and published in TypeScript.

In other words, when you install a Deno package, its source code is written in TypeScript.

Well, that didn't really rephrase it at all. To be specific, if you jump to the definition of an API provided by a package in your IDE, you jump directly to the TypeScript implementation. This might sound like a given, but anyone who has developed with Node.js will surely understand why this is so great.

That's right—instead of jumping to a type definition, you jump to the actual implementation code of that API and can see what it does.

By the way, I haven't actually tried this, but according to this page, Bun also allows you to publish TypeScript code directly to NPM without transpiling it. In that respect, what I've written here isn't unique to Deno. However, this leads into the part where Deno went as far as creating JSR!

To add one more clarification, you can only jump to the TypeScript implementation in Deno for things implemented in TypeScript. For instance, you can jump to and read the implementation of std/* or various libraries, but you cannot jump to the implementation of core Deno built-in APIs like Deno.*. While TypeScript type definitions are provided for these, they are actually implemented in the Rust and JavaScript runtime layers.

Of course, VS Code, for example, has a "TypeScript: Go to Source Definition" command that—in theory—allows you to jump to JavaScript symbols. However, if you actually try it, you'll find that it unfortunately rarely gives the result you expect.

This is often a point of contention from engineers when adopting Node.js, especially for backend projects. I've personally gotten used to it—having experienced the transition from the JavaScript era to TypeScript, I tend to think, "This is just how it is. It's much better than before, so don't complain." But when I snap back to reality, I think, "Wait, even with programming languages that compile to native code, it's perfectly normal these days to quickly jump to definitions or debug at the code level. Why can't I do that here?"

Putting that aside, this experience specific to TypeScript development made me feel a strong sense of "distance" between the code I wrote myself and the code from libraries or elsewhere.

The Issue of "Code Distance"

"Code distance" is an expression I haven't really used before, but when I put it into words, it feels like the most fitting description. I believe this code distance is a fairly serious issue.

There is no difference between product code and library code. All the code used in your product is your product code.

This is something I once heard from a Rubyist. It left a strong impression on me because I thought, "That's exactly right," and it has become one of the foundations of my awareness regarding code. I understand this to be exactly a conversation about "code distance."

I believe that in order to recognize someone else's code as being the same as your own without distinction, it is very important that you are in a state where you can immediately touch and tinker with it. Of course, with enough knowledge and experience, you can tinker with anything, but the fact that such high levels of skill are required simply acts as a hurdle.

With interpreted languages, even for library code, you can simply open it in a text editor, change it, and save it, and it will run exactly as you modified it. Wasn't this closeness in distance the very charm of interpreted languages (scripting languages)? And wasn't JavaScript originally like that too? While trying to make JavaScript more convenient to handle, it somehow became too complex, and code written by others—even code used every day—has become a distant presence.

Ultimately, what I fear for is the survival of OSS culture. I'm afraid that fewer opportunities to tinker with OSS code might directly lead to the decline of the OSS community. Yes, I've said that "the code distance imposed by TypeScript is a serious issue," but until now I hadn't clarified what exactly it was an issue for—I believe it is "an issue for OSS." It's quite alarming. I'm not trying to suddenly act like a spokesperson for free software or say something grandiose with a broad subject; it's just a desperate feeling from someone who has walked alongside OSS in both work and private life and doesn't know any other way to live. Well, maybe a future where AI takes over everything awaits.

I'm writing as things come to mind, but no one would disagree that the democratization of OSS accelerated rapidly thanks to GitHub. Until then, sending patches to software was a privilege (?) reserved for a rare breed of people—programmers—and among them, only a very limited few. I think many people, including myself, were shocked by the appearance of GitHub, but the web programming world at that time was at the peak of scripting languages called "lightweight languages," and most of the code hosted on GitHub was indeed written in Ruby, Python, PHP, and JavaScript. I believe the birth and success of GitHub were strongly related to the characteristics of these programming languages—or rather, it was inevitable because friendly scripting languages were popular.

It's a bit reductive to lump it all under "TypeScript," but in the world of modern JavaScript, due to the diversification and complexity of toolchains, you sometimes visit a GitHub repository and give up because there's so much you have to understand before you can even start reading. This itself is a concrete problem shared by many. For example, while Rome unfortunately didn't make it, its spirit has been carried on by Biome, Vite, and others.

Deno has also been communicating its awareness of these DX issues from a very early stage. Of course, since they are a business, they probably pitched it as "Here are the good things about using Deno," but in any case, it linked perfectly with how I felt, and I had a gut feeling from the start that this was something I could truly love. Watching Deno's blog and YouTube channel, I can see that their direction—consistently providing a programmer-friendly environment in terms of both features and proposed concepts—has never wavered, confirming that my intuition was correct.

Then, following Deno Deploy and Deno KV, JSR was released—something I feel fills the final and largest piece of the DX that Deno brings.

TypeScript DX Completed with JSR

In March 2024, the public beta of JSR was released.

Regarding this, most of what I want to say is covered in the release post. The following parts are particularly relevant to the content of this post:

Modules are published to JSR as TypeScript source code. API documentation generation, type declarations for Node-like environments, and transpilation are all handled by JSR. Module authors can focus on writing TypeScript only.

It should be designed for TypeScript from first principles
It should be simple, fast, and provide an excellent developer experience

https://deno.com/blog/jsr_open_beta

I remember when my colleague mottox2 posted on our company Slack on the day of the release, with a kind preamble: "I think only Wakasugi-san would be interested, but," saying, "JSR has been released. It looks like it has many features that library authors would appreciate." I recall replying something like, "It makes perfect sense that this came from Deno."

As I've mentioned multiple times, I believe Deno has repeatedly made moves to pursue the DX of a TypeScript-centric ecosystem. Naturally, that DX included making it easier for anyone to publish packages. In fact, if we only consider Deno, the functionality of JSR as a web service was almost entirely provided by denoland/x from a very early stage, so I see this as a way to further expand that philosophy.

I was reading the comments on HN and Reddit when the release post mentioned above came out, and while there were both pros and cons, it felt like the negatives were more prominent. I can sympathize with those negative opinions. Some of the notable critical comments included the following:

• Instead of adding yet another package registry to the world, they should improve existing ones.
  • Specifically, they should cooperate to improve NPM.
• If the issue is that NPM is operated as closed-source by Microsoft, doesn't it defeat the purpose to create a superset that depends on NPM?
  • If Deno operates it, the vendor lock-in simply shifts, and it doesn't solve the root problem.
  • In fact, calling it a "superset" in the first place might be misleading.
• A package registry shouldn't take on the responsibility of package building (compiling/transpiling).
• Security against supply chain attacks and other threats might be insufficient.

However, Deno developers directly replied to most of these critical remarks, and most of their responses were reasonably convincing. For example, they noted that "for MS/GitHub, NPM is treated as a cost center, and since improvements can't be expected, there was no choice."

I can't list everything here, so I hope those interested will look it up, but I would like to quote an HN post by someone who was a Deno DevRel at the time.

For module authors, we're hoping JSR will be helpful in the following ways:

1.) You can develop and publish TypeScript source, and let JSR handle transpilation and generating .d.ts files for runtimes that don't natively support TypeScript. Especially nice if you are using Deno or Bun (that do natively support TypeScript), and don't have tsc in your workflow otherwise.
2.) JSR generates API docs for you on your package page based on your source code and comments.
3.) JSR has a great DX around publishing packages from GitHub Actions using OIDC (no juggling tokens)
4.) JSR automatically provides provenance for published versions of packages

For module consumers, it helps too:

1.) Compatible with both Deno and existing npm-based projects
2.) Package info and docs provided centralized on the jsr.io site
3.) Quality scores that encourage authors to make their packages fast and well documented
4.) Access to TypeScript source for packages (not just transpiled output)

I think the benefits for both module authors and consumers are very well summarized.

To get a feel for being a "module author," I actually tried developing a module with Deno and publishing it to JSR, and it was a great experience that lived up to those words.

...Actually, I must confess that there were many pitfalls, and the DX was quite terrible at times. I got stuck forever, didn't get answers even after asking on Deno's Discord, and sometimes had to solve things with reckless workarounds. However, all of those pain points were due to the coexistence of dependencies on esm.sh and denoland/x, so I believe they aren't fundamental issues and will be resolved over time.

But above all, I felt that:

• The act of publishing a package to JSR itself is quite fun.

This is a major theme of this post. While it overlaps with the comments quoted above, the following is achieved by running just a few simple commands:

• Suggestions are provided for better documentation.
• A package score is displayed (though it's quite easy to reach 100 points).
• Your documentation and code are published with a beautiful web UI.
• GitHub Actions using OIDC for authentication and authorization are configured, and pushing a "bump up version" commit immediately triggers an automatic release of the new version.

It's always fun to see something you've created being published. Also, as seen in the symbolic mod.ts file, the influence from the Rust community—which Deno also uses in its implementation—seems to be working in a purely positive way, and the fact that there's almost no confusion in using the toolchain is a big plus. It's fun, and there's no unnecessary worrying. Anyone would want to use something like that. Probably.

In this way, I believe the DX proposed by Deno is completed with JSR. Furthermore, it solves the current DX issues surrounding TypeScript development, and I'm imagining that this might be the path leading to a democratized OSS where anyone can participate. So, I highly recommend Deno to everyone. And with that, I'll end this quite abruptly.