71–80 of 183 posts
Speaking of which, the new deno.com site looks like a marketing website designed by an AI. Lacks all of the pragmatic unix-y character that Deno originally had, and is just filled with meaningless numbers and metrics and way too much blank space. It's like they're selling a product... which I guess is what Deno is now. VC funding will do that to you.
> JSR isn't a replacement for the npm registry; it's a superset of npm. I first read this line to mean that JSR contains every package on NPM, and was just doing some post-processing on them. But it does seem to be its own registry. Maybe the intent of the line was to communicate that you can install packages from both?
I think this is mostly right - "superset" in that JSR modules can depend on npm modules, and projects using npm can use the npm registry and JSR together. The bottom line we'd want to communicate is that JSR is additive to npm, and the two can be used at the same time.
I would recommend to use other terms such as "Additive" or "Complementary" to describe JSR.
I tried to look for something lately that:
1. Makes it easy to download specified versions of JS libs.
2. Exposes these libs as proper ES6 modules.
I get why (2) is a bit tricky, it'd be fantastic but more of a nice to have anyway.
I don't really get why there's no popular tool for (1) yet. Sure, I can just fetch the files I want from a CDN and commit them to a vendor directory, or I can write a little script that downloads them from a CDN. Or hey, I can fetch frontend dependencies via NPM and have a script that builds/copies the stuff. But that's a bit much labour for something that I thought would be a relatively common requirement.
Am I in the minority to occasionally want to build web apps _without_ bundlers? Being able to skip the build step is very powerful both for keeping things simple and turnaround times fast, IMHO.
As a long-time front-end developer, I'm not seeing a strong value proposition here to justify the further fragmentation another package registry is going to cause. > You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility. This sounds like another building service I don't control. There's already too much magic in publishing transpiled…
JSR is a registry, not a package manager. npm allows you to add multiple registries and JSR provides an npm API endpoint. From npm's point of view packages coming from JSR are the same as those coming from the npm registry itself. The only difference is where the package is coming from, but all semver resolution, etc are done as usual by whatever package manager you use.
Disclaimer: I wrote a good portion of the npm tarball generation code.
This is a terrible name. JSR already stands for "Java Specification Request" which is basically an RFC or standard for Java (not JavaScript). This is going to make Google searches even more difficult. Searching for Java jobs and getting JavaScript jobs is already bad enough. This name is just making a big mess with semantic name collision in our mental namespaces. Just make it "RfJS" maybe for "Registry for JavaScrip…
Given that you're going to have a hard time pulling up the JSR you're looking for without adding qualifiers anyway, I don't think this name choice is going to substantially change anything.
Earlier quoted context omitted.
The project is called "The JavaScript Registry" > The JavaScript Registry (JSR) is a modern package registry for JavaScript and TypeScript. https://jsr.io/docs/introduction
Yeah, this is what I'm complaining about. If you're building something that is designed for TypeScript , made for TypeScript and publishes TypeScript sources, then I find it really hard to understand why you'd name it "The JavaScript Registry".
Glad the pinnacle of programming is still there: left-pad
The entire source code: export function leftPad(str, len, ch) { return new Array(len - str.length).fill(ch || ch === 0 ? ch : ' ').join('') + str }
const bespokePad = (x) => ('000000' + x).slice(-6)
As a long-time front-end developer, I'm not seeing a strong value proposition here to justify the further fragmentation another package registry is going to cause. > You publish TypeScript source, and JSR handles generating API docs, .d.ts files, and transpiling your code for cross-runtime compatibility. This sounds like another building service I don't control. There's already too much magic in publishing transpiled…
For tools that natively support TypeScript, you can directly consume the TypeScript source code. No transpilation necessary. The complexities are only introduced (well not really introduced, just moved somewhere else) for tools that do not natively support JS.
> The "web standard" part is meaningless considering that most production websites will bundle the files together as part of their build/optimization process for size and loading speed, leaving only a giant chunk(s) that resembles nothing like the original ES modules.
That doesn't matter. If everyone settles on one standard, even if you do post process, tools become simpler. The idea is not that you must ship your code unbundled to the browser. It is to reduce the amount of complexity incurred in the process from source -> dist. I am sure you agree that the lower the difference between source and dist, the easier debugging and developement in general are :)
> A super of npm means that the packages created for this repository will not work in the npm ecosystem. What is this if not a "replacement" of the npm registry and further fragmentation of the JS ecosystem?
They do work in npm. In npm packages you can depend on JSR packages, and on JSR you can depend on npm packages.
> This makes the already complicated module resolution logic in most bundler/packaging tools even more complicated as they must account for the intricacies of another package manager. A house of cards being stacked on another house of cards...
Nope! JSR is not a package manager. JSR is only a runtime. When you install into a node_modules folder, the layout in this folder is the same between JSR and npm packages. So any downstream tool does not even need to know JSR is in the loop - it just works. This is one of the key points to ensure easy adoption of JSR by anyone.
> It seems like every benefit that this project offers can be fixed in the current ecosystem by better client-side tooling that enforces standards during the publishing process while keeping full backward compatibility with over a decade of packages published and without fragmenting the ecosystem.
I understand this.
The problem is the following: npm is owned by GitHub/Microsoft, and GitHub/Microsoft does not care about npm. To GitHub, npm is a cost center. npm has no dedicated product manager at GitHub. Last I heard, npm has _two_ dedicated engineers working on it. The last real new feature npm shipped was package provenance (last year). It took npm 5 years to ship the file browser (because GitHub/Microsoft did not care about npm, and thus effectively froze all feature dev work on npm).
If we want innovation in the space, we need to do it in a way that a) keeps backwards compat with npm (which JSR does, both ways), but b) we need to move away from npm in the long term. JSR is an attempt at this (while trying to stay within the constraints posed).
Oh boy. Reading the title ("JSR: The JavaScript Registry" at the time of writing) I had high hopes this might be what I'm looking for: Dependency management for JavaScript in the browser. It's something entirely different. I tried to look for something lately that: 1. Makes it easy to download specified versions of JS libs. 2. Exposes these libs as proper ES6 modules. I get why (2) is a bit tricky, it'd be fantastic…
Oh boy. Reading the title ("JSR: The JavaScript Registry" at the time of writing) I had high hopes this might be what I'm looking for: Dependency management for JavaScript in the browser. It's something entirely different. I tried to look for something lately that: 1. Makes it easy to download specified versions of JS libs. 2. Exposes these libs as proper ES6 modules. I get why (2) is a bit tricky, it'd be fantastic…
We don't do this natively (yet?), but esm.sh supports JSR alreay: https://twitter.com/jexia_/status/1762516242626416750