This article provides a detailed review of JSR (the JavaScript Registry) and its relationship with Deno. It covers various aspects such as search functionality, TypeScript support, Deno support, and overall user experience.

Search-ish: JSR was expected to improve on NPM's stagnant search. However, searching for the Deno standard library yields poor results, including packages with zero score, unofficial mirrors, and deprecated versions. The official response about the search ordering being arbitrary by the third-party tool "orama" is not satisfactory. Issues have been raised but ignored.

TypeScript-ish: JSR is marketed as designed for TypeScript but struggles with it, imposing strict type restrictions. For example, all exported symbols must explicitly specify types. This leads to a "slow types" issue that shifts the blame onto TypeScript and the user. Opting out comes at the cost of incomplete documentation.

Deno-ish: JSR has limited Deno support. Deno has taken a U-turn on HTTP imports, which are not allowed in JSR. This has broken the importing of many pre-JSR Deno packages and led to a fragmented Deno package ecosystem. The move to JSR appears rushed, and local development with JSR is tricky due to the use of a magic shim. Node package developers are not affected.

Bad Vibes: JSR has failed to deliver as expected, causing a Deno package debacle. There is a lack of engagement with users, and many reported issues are not addressed. Deno has become a commercial product-driven business, and there are concerns about vendor lock-in. The author feels disappointed with Deno and no longer has enthusiasm for it.

In conclusion, JSR has several major problems that need to be addressed to become a worthy replacement for NPM. The limited Deno support and issues with search and TypeScript undermine its potential. The overall user experience is lacking, and the lack of engagement with users is a cause for concern.