This content originally appeared on dbushell.com and was authored by dbushell.com
With my first impressions and second look of JSR (the JavaScript Registry) I tried to be positive and optimistic. I saw the potential that JSR could offer something more than NPM. Half a year after public launch, how is JSR looking now?
Well… not good. But let’s start on a high note.
(Yeah, I know it’s uncouth to use the litter bin emoji in the title but I’ll convince you that it’s appropriate.)
The Small Things
JSR added official badges. They’re an easy win.
Other small improvements to JSR have been made in areas like package scoring and presentation. These small things do add up. My request for more nuanced JavaScript API compatibility hasn’t landed but I can’t be too selfish.
Unfortunately, it’s hard to muster any more positivity than cute badges. These past few months I tried to go all-in with JSR and Deno. I felt it deserved a fair try and time to mature. My experience has left me soured on both projects.
Below I’ll focus on four major problems for JSR:
Search-ish…
JSR was supposed to innovate where NPM stagnated. Search was a prime candidate for improvement. A simply search for the Deno standard library yields abysmal results:
Before any expected results are listed you’ll find:
- A package with zero score and no documentation
- An unofficial “All-in-one mirror of Deno’s Standard Library.”
- An empty package with no files and 1 yanked version
- “PRIVATE: The internal package for @std. Do not use this directly.”
- Two “DEPRECATED” @std packages
GitHub issue #311 from March 20th raised similar concerns. The official response was:
the ordering is completely arbitrary by orama, and we currently have 0 influence on it
“orama” is the 3rd party tool powering JSR search. Orama is obviously not fit for purpose and is embarrassing JSR. Issue #312 posted the next day requested a better search module. It has been ignored and is stuck in “Needs Triage” limbo.
Considering search is the primary user interface for JSR — the homepage has a Google-like design — one would think this feature would be prioritised. Yet we’re many months after issues were raised and search remains in a dire state.
Search is just one example of the promised features and functionality that would make JSR a worthy replacement to NPM.
TypeScript-ish…
JSR is heavily marketed as “designed for TypeScript” but in reality it struggles with TypeScript at the cost of user experience. JSR has a long list of TypeScript restrictions. Publishing your first package to JSR will likely lead to the linter crying foul.
Here is an example restriction from the JSR docs:
All symbols exported from a package must explicitly specify types.
- export function add(a: number, b: number) {
+ export function add(a: number, b: number): number {
return a + b;
}I bet even the strictest of TypeScripters have left the compiler to infer the return type of a simple math function.
JSR has branded its problem “slow types” and JSR makes it your problem to deal with. If you scroll all the way down the ‘About “slow types”’ page you’ll find how to opt-out. You can tell the linter to shut up at a cost:
Doing this results in incomplete documentation and type declarations for the package
While I can sympathise with JSR — we all know how difficult TypeScript can be — this “slow types” thing is disingenuous. JSR struggles to deliver on the TypeScript utopia it promises. JSR shifts the blame onto TypeScript and the burden onto the user. In reality JSR has to impose limits on TypeScript support in order to delivery much of its functionality.
This must change for JSR to be taken seriously as a TypeScript registry.
Deno-ish…
JSR, surprisingly, has limited Deno support. That may sound facetious, but I’ve written a comprehensive overview of “The Deno Package Paradox” explaining this problem.
Basically, Deno has taken a U-turn on HTTP imports and JSR does NOT allow them. JSR allows node:, npm:, and jsr: imports, but not http:.
This is a big deal because every single pre-JSR Deno package with dependencies used HTTP imports. That was the Deno way. Those packages are now blocked from publishing on JSR until upstream packages do — if they do. Few are. Curiously, for an immutable registry, the package count is dropping.
Deno has compounded this issue by publishing the Deno standard library @std exclusively on JSR. This change has broken importing from source and left 7500+ packages abandoned on deno.land/x — the old official package hosting service. Deno only published versions of @std from v0.196 onwards to JSR. Package authors who wish to republish on JSR must bump versions and face refactoring to fix the many @std breaking changes and deprecations prior to v1.0.
The net result is a fragmented Deno package ecosystem.
JSR is now the official place to publish Deno. JSR itself is listed as a “product” on deno.com. Independence from Deno Land Inc. is unclear. Anyway, one would expect Deno development to be a smooth experience using JSR given its adoption.
The Deno CLI only provides deno add for managing dependencies. Would a remove be too much to expect? It’s a minor thing but speaks volumes. The whole move to JSR appears rushed and ill-considered.
I can live without CLI commands. I cannot live with broken local development. The move away from HTTP imports makes local dev tricky. JSR uses a magic shim to fix import maps for Deno because Deno cannot resolve sub-dependencies like Node does. Developers are forced to create their own tools with extensive documentation on the issue.
In short, JSR does not play well with Deno.
Node package developers are unaffected by these issues. The question still remains: what is compelling them to publish anywhere other than NPM?
Bad Vibes
JSR has so far failed to deliver. I don’t see any other conclusion. JSR has caused a Deno package debacle that actively harms both projects.
I’ve been noticing a trend with Deno Land Inc. products. Engagement with users is fleeting. Engagement from JSR has been more PR (public relations) than PR (pull requests). Sorry, that’s a painful pun. What I mean is that many reported issues with Deno products are never addressed. Often they’re not even acknowledged. From Deno KV architecture, to Deno Deploy startup times, I keep running into show stopping issues with little to suggest they’ll ever be fixed. It’s not a good look.
I understand all too well that managing GitHub issues isn’t easy. I don’t expect miracles, nor my specific issues to be addressed above others. But observed trends reveal a pattern. Bad vibes are hard to ignore.
Exhibit A
Deno has gone from a fun community focused project to a commercial product-driven business. With Deno Land Inc. you have a VC-backed company keeping their cards held close. I finally understand what Dahl meant by saying JSR is “Not Another Package Manager” — JSR is just another product aimed at driving growth and vendor lock-in. It doesn’t matter how “open source” products like JSR claim to be. Outside developers would be foolish to contribute for free. Should we really believe that backtracking on HTTP imports was about developer experience? I wonder, who benefits from a centralised package platform?
I feel “done” with Deno. I feel a fool for championing it.
I have no more enthusiasm for anything related to Deno. It is now merely a tool that is — for the time being — slightly more convenient than Node.
This content originally appeared on dbushell.com and was authored by dbushell.com
dbushell.com | Sciencx (2024-08-09T10:00:00+00:00) JSR and Deno: Final Review đźš®. Retrieved from https://www.scien.cx/2024/08/09/jsr-and-deno-final-review-%f0%9f%9a%ae/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.