You could say the same thing about jspm, yarn, pnpm, bun, deno, typescript, nix, umd, esm, and a lot of other things. In the end, it makes dealing with projects a lot harder since NOTHING is standard and you effectively have to be familiar with a mix of any of these js technologies to contribute/troubleshoot a simple project. People like to just make competing standards and adopting them hastily to multiply the hellscape that is JS projects.
@@bob_kazamakis I completely disagree, you don't need to learn all the topics you listed to be a good js programmer, the only thing you need are nodejs, npm and react (to take the two most popular) and for 70% of the projects that's pretty much it. It's your personal choice to learn the other technologies and to adopt them, but nobody forces you to work on angular or with yarn if you don't want. Otherwise anyone can respond that even Go ecosystem is bad because you have to learn: templ, gin, errgroup, conc, zerolog and 10 different testing frameworks
I don't see npm going anywhere any time soon, for better or worse. I really like the Deno approach to things more than where Node.js is. Of course, entropy counts for a lot and I don't think JSR will take over... I do think it could gain a lot of ground... but it would take something like React, Redux and MUI all using that as the main/supported target, and even then would probably piss a lot of people off. It took moving the earth and moon for npm to take hold over bowser (I think that was the name of it)
Is there a way to publish the sources? For example, for Vue libraries it makes a lot of sense to publish the source alongside the esm/cjs/umd, because using source directly leads to better tree-shaking.
I'd argue NPM is a complete heckshow (self censored expletive). How many times have we installed something into an existing project and we get that "Cannot resolve dependency tree" error. Some dependency deep down your tree is not peer-compatible with something else you have installed, and good luck finding what it is, since these error messages are so verbose and really offer no suggestion on how to fix it. If NPM is to survive, its DX needs drastic improvement. Oh. Don't get me started on these single-function packages like is-odd. It'd be nice to have a JSR somewhere that's curated and administered so low-quality libraries don't get published.
I am curious about why you chose to have a "jsr.json" file instead of "jsr.ts" file? Adding support for a typescript config file would provide so many benefits.
Having something that executes and might have side effects in order to derive a package metadata would be troublesome. Imagine if jsr.ts read from Env, or worse - did network calls.
Any other tooling that needs to modify the configuration programatically, now needs to deal with a full AST parsing of the file to make a single change as opposed to simple editing of json data. Also, you can define a schema for your json files as well so you can have full autocomplete hints and docs.
@@jvliwanag Even with these limitations in JSON file, if people wanted to do something like this, they end up adding some hacks by executing bash scripts or npm scripts that modify the JSON file and then do the post-processing stuff. JSON config files don't solve that problem, they just make it harder. And this complexity also makes it harder to add some logical configurations that acually makes sense. This works for package configuration files like ("tsup.config.ts", "eslint.config.js", etc and even other languages like Kotlin with Gradle), I don't understand how it will be problematic for jsr
@@niktek7020 In this case, deno already has a typescript/javascript executor (deno itself). They can just run the script and get the exported configuration (or any other way of returning configuration). They don't need to build a separate AST parser because TS is not a new DSL. It is the primary language that they support.
how does iot handle exports , like i want a componet library that puts @ui/button and @ui/accordion separately because one need a use client to play nice with rscs but the other can be used directly in an RSC
honestly .. it is already bad because it interops with NPM ... npm is not bad for the reasons you mentioned but because of the dependency-hell it generates
I feel esm only will throw 90% of node projects as of today. I don’t see myself using it as several libraries I depend on doesn’t have ESM. I get the feeling that in near future the benefits will be monetised to pay the server cost to run the transpilation etc on server side.
The main highlight for me is the open ID things to publish packages, something npm does wrong. If you are optimizing for maintainers, downloads stats are critical IMHO. Is the audio AI generated? It makes me feel strange.
Great question. Turns out federated URL imports (which will always be supported btw) creates some issues around duplicate and disappearing dependencies. e.g. it is difficult to de-dup dependencies because we couldn't use semantic versions. In these situations we learned it is better for a central registry. Hope this answers your question!
it's pseudo code to indicate a break in the code. but thanks for your comment, i can see how that is confusing. we will probably do something else in the future.
when you create an astro project, it will scaffold a few files. the file being edited at 5:10 is "src/components/Card.astro". maybe the video should include the file path in the window title to make this more obvious.
Not having native support for TypeScript is most definitely a problem I have encountered with NPM. With jsx support landing soon as well, that's another major win.
@@RustIsWinning all it does is complicate module resolution for a package manifest. Npm can do all the same stuff. It’s just “yet another js” thing because js devs don’t know when to stop.
@@RustIsWinning you can do literally all of what has been mentioned with npm normally. Do you even know how package resolution works? npm (et al) form a tree of what dependencies a package needs and resolves them. This works nicely when they are all on npm. Now what happens when one npm one has a dep on something hosted on jsr, but now the ones on jsr have deps to those back on npm. You now have this expanded and bloated community where packages are hosted in varying locations and they themselves point to other locations. You have just complicated the source graph and have changed nothing theoretically about a problem that exists. And we just expect security tools to put up with the js industry’s BS on hosting things in a new place in a new year because no one has the nerve to stand up for this crap and say stop? And, by the way, packages on npm don’t require types package installations. You can export types in your npm package as well. I take it since you pulled that out as somehow a core benefit of jsr, that you really don’t know of a true benefit of this system, seeing as how 95% of the packages I use support ts natively and I rarely have to do @types/* installs.
@@RustIsWinning I don't think you understand how this works, at all. Everything mentioned here is something you can pretty much already do with npm, but now you have to complicate where you got it from. Now there will be some cases where the only thing you need is hosted on jsr, and that will have a dep graph of things from npm, and then things from npm will reference things from jsr. This just creates a tangled web of "where did it come from?" to complicate package locks, users just looking to download something and use it, security tools that need to keep track of supply chain attacks. And there was no mention of how to handle interop with cjs/esm since this new bad idea is "esm only". And your strongest argument is somehow that you won't need a @ types package? You do know that you can natively bundle types in your package and @ types accounts for < 5% of my package manifest? What kind of argument is that? This is just another tool created because no one has the strength to tell js devs to just stop. No other language has all of this bs going on
Despite the natural scepticism around, I'm really happy that somebody actually decided to build JSR.
Thanks and good luck!
This is a major improvement of the JS ecosystem, lovely
There is no such thing as "improvement" in JS ecosystem
You could say the same thing about jspm, yarn, pnpm, bun, deno, typescript, nix, umd, esm, and a lot of other things. In the end, it makes dealing with projects a lot harder since NOTHING is standard and you effectively have to be familiar with a mix of any of these js technologies to contribute/troubleshoot a simple project. People like to just make competing standards and adopting them hastily to multiply the hellscape that is JS projects.
@@bob_kazamakis I completely disagree, you don't need to learn all the topics you listed to be a good js programmer, the only thing you need are nodejs, npm and react (to take the two most popular) and for 70% of the projects that's pretty much it. It's your personal choice to learn the other technologies and to adopt them, but nobody forces you to work on angular or with yarn if you don't want.
Otherwise anyone can respond that even Go ecosystem is bad because you have to learn: templ, gin, errgroup, conc, zerolog and 10 different testing frameworks
I'm sure JSR will take over NPM's job as it doesn't do it well enough. I'll be waiting for that day.
Like deno will take node's job?
I don't see npm going anywhere any time soon, for better or worse. I really like the Deno approach to things more than where Node.js is. Of course, entropy counts for a lot and I don't think JSR will take over... I do think it could gain a lot of ground... but it would take something like React, Redux and MUI all using that as the main/supported target, and even then would probably piss a lot of people off. It took moving the earth and moon for npm to take hold over bowser (I think that was the name of it)
Mind providing a few of those things that NPM doesn't do well?
@@echoptic775 JSR is not Deno. I'm only talking about the registry. [scratch that], fair point.
@@aztracker1 Yeah, it makes sense. I guess I stated my wish as a fact 😄
Damn ... This will definitely be the norm ❤️🙌
this is why I love competition
Its a bit rocky for packages not using deps already on JSR, but this is reallt cool. It'll get better with time
this looks very cool
Deno hired Awesome !
I didn't realize I was in the deno channel until I exited
Amazing im so happy to see this!
Is there a way to publish the sources?
For example, for Vue libraries it makes a lot of sense to publish the source alongside the esm/cjs/umd, because using source directly leads to better tree-shaking.
we only publish the sources :) jsr.io/docs/publishing-packages
I'd argue NPM is a complete heckshow (self censored expletive). How many times have we installed something into an existing project and we get that "Cannot resolve dependency tree" error. Some dependency deep down your tree is not peer-compatible with something else you have installed, and good luck finding what it is, since these error messages are so verbose and really offer no suggestion on how to fix it. If NPM is to survive, its DX needs drastic improvement.
Oh. Don't get me started on these single-function packages like is-odd. It'd be nice to have a JSR somewhere that's curated and administered so low-quality libraries don't get published.
Thanks for your comment!
man npm reallly is the battle tested....npm install everything.
I am curious about why you chose to have a "jsr.json" file instead of "jsr.ts" file? Adding support for a typescript config file would provide so many benefits.
Having something that executes and might have side effects in order to derive a package metadata would be troublesome. Imagine if jsr.ts read from Env, or worse - did network calls.
Any other tooling that needs to modify the configuration programatically, now needs to deal with a full AST parsing of the file to make a single change as opposed to simple editing of json data. Also, you can define a schema for your json files as well so you can have full autocomplete hints and docs.
@@niktek7020 > full AST parsing
JSON.parse(jsrJson)
@@jvliwanag Even with these limitations in JSON file, if people wanted to do something like this, they end up adding some hacks by executing bash scripts or npm scripts that modify the JSON file and then do the post-processing stuff. JSON config files don't solve that problem, they just make it harder. And this complexity also makes it harder to add some logical configurations that acually makes sense. This works for package configuration files like ("tsup.config.ts", "eslint.config.js", etc and even other languages like Kotlin with Gradle), I don't understand how it will be problematic for jsr
@@niktek7020 In this case, deno already has a typescript/javascript executor (deno itself). They can just run the script and get the exported configuration (or any other way of returning configuration). They don't need to build a separate AST parser because TS is not a new DSL. It is the primary language that they support.
I should have been like this from the beginning all the way back in 2010!!!
how does iot handle exports , like i want a componet library that puts @ui/button and @ui/accordion separately because one need a use client to play nice with rscs but the other can be used directly in an RSC
Hahaha what a preview picture 😂
Having auto generated docs is huge!
We think so too!
honestly .. it is already bad because it interops with NPM ... npm is not bad for the reasons you mentioned but because of the dependency-hell it generates
The current interop is only as a migration path to encourage users to write modern modules (e.g. ESM). Hopefully one day no one has to use npm 😬
@@deno_land Based Deno... Love it!
It's far better than NPM, but…
Why not do it like Go ?
Can I it or do I have to npx it?
I feel esm only will throw 90% of node projects as of today. I don’t see myself using it as several libraries I depend on doesn’t have ESM.
I get the feeling that in near future the benefits will be monetised to pay the server cost to run the transpilation etc on server side.
The main highlight for me is the open ID things to publish packages, something npm does wrong. If you are optimizing for maintainers, downloads stats are critical IMHO.
Is the audio AI generated? It makes me feel strange.
Did it solved the { version: "*" } stuff tho?
Brilliant
Deno was launched with a strong argument against centralized package repositories. Why is this not federated from the start?
Great question. Turns out federated URL imports (which will always be supported btw) creates some issues around duplicate and disappearing dependencies. e.g. it is difficult to de-dup dependencies because we couldn't use semantic versions. In these situations we learned it is better for a central registry. Hope this answers your question!
@@deno_landDon't Go do this purely decentralized?
It is basically downloaded directly from GitHub.
Being a superset of NPM guarantees that JSR will never fix the issues with the javascript ecosystem.
What library syntax at 5:10 with "---" separators? Or it's just pseudo-code?
it's pseudo code to indicate a break in the code. but thanks for your comment, i can see how that is confusing. we will probably do something else in the future.
@@deno_land Isn't that actual Astro component syntax though?
when you create an astro project, it will scaffold a few files. the file being edited at 5:10 is "src/components/Card.astro". maybe the video should include the file path in the window title to make this more obvious.
@@dtinth thats a good point, thank you!
Thank you.
looks good
best i love it
It happened!!
indeed!
What about browser compatibility?
AFAIK as long as the code doesn't use anything that is server side specific (deno, bun or node) it should work fine in the browser via http imports
npm is too annoying this is good
oh shouldn't it be tsr ?
It’s pretty difficult to listen to that ai generated voice.
😂
so npm users can't use my package now? if so how is it possible?
npm users can also use JSR, since JSR is a superset of npm: jsr.io/docs/npm-compatibility
how secure is this?
Is the narrator is 'awesome' ?
Yes
It could have been broken into two separate videos
No
Can reactjs able to use jsr?
Yes definitely! Any node project can use JSR: jsr.io/docs/npm-compatibility
i just use git://
jsr is better than npm lets be honest
It good for package publisher not for end user I think pnpm is better
First you need to make sure deno demo work first 😂
Its unhinged that a simple install demo does not work as is especially in older server environment
@@RustIsWinning Yea indeed the dev of deno has skill issues. Even their literally install steps does not work. How cool is that?
ahahahahahahahahaahahahahahahahahahahahahaahahahah this is sooooooooo funnyyy)))))) really. Trying to solve problems that not even exist lol
Not having native support for TypeScript is most definitely a problem I have encountered with NPM. With jsx support landing soon as well, that's another major win.
@@ollierkul look here is our new registry that supports both npm and jsr or whatever) a lot of JS devs should mature a bit)
@@ordinarygg I have no idea how to interpret your comment
@@ollierkul use WinterJS, new engine for JS)))))
no-god-please-no-michael-scott.gif
@@RustIsWinning all it does is complicate module resolution for a package manifest. Npm can do all the same stuff. It’s just “yet another js” thing because js devs don’t know when to stop.
@@RustIsWinning you can do literally all of what has been mentioned with npm normally. Do you even know how package resolution works? npm (et al) form a tree of what dependencies a package needs and resolves them. This works nicely when they are all on npm. Now what happens when one npm one has a dep on something hosted on jsr, but now the ones on jsr have deps to those back on npm. You now have this expanded and bloated community where packages are hosted in varying locations and they themselves point to other locations. You have just complicated the source graph and have changed nothing theoretically about a problem that exists. And we just expect security tools to put up with the js industry’s BS on hosting things in a new place in a new year because no one has the nerve to stand up for this crap and say stop?
And, by the way, packages on npm don’t require types package installations. You can export types in your npm package as well. I take it since you pulled that out as somehow a core benefit of jsr, that you really don’t know of a true benefit of this system, seeing as how 95% of the packages I use support ts natively and I rarely have to do @types/* installs.
@@RustIsWinning I don't think you understand how this works, at all. Everything mentioned here is something you can pretty much already do with npm, but now you have to complicate where you got it from. Now there will be some cases where the only thing you need is hosted on jsr, and that will have a dep graph of things from npm, and then things from npm will reference things from jsr. This just creates a tangled web of "where did it come from?" to complicate package locks, users just looking to download something and use it, security tools that need to keep track of supply chain attacks. And there was no mention of how to handle interop with cjs/esm since this new bad idea is "esm only". And your strongest argument is somehow that you won't need a @ types package? You do know that you can natively bundle types in your package and @ types accounts for < 5% of my package manifest? What kind of argument is that? This is just another tool created because no one has the strength to tell js devs to just stop. No other language has all of this bs going on