@@LeoPlaw The introduction literally says "JSR packages are written in JavaScript or TypeScript". Not sure why you are hell bent on pushing misinformation on this. They don't enforce it, I've tested it. You do however receive a warning if you dont include a type declaration (d.ts) file, because they encourage the use of fast type checking.
"Since then, there hasn't been much innovation.". That take is kinda weird because it implies that if something exists for a long time, it has to do something different at some point. What if it "just works?", like works well for a long time... and doesn't need to change. But yes JSR and Volt is cool.
my problem with native TS runners like Deno is that TS is still slave to JS decisions. Upgrading the package manager is an exciting development, but not enough to give me much hope on the future of JS/node/TS/etc. And all these new package manager proposals are just looking to me like an excuse to centralize compute resources and charge for it. I don't want "the cloud" to generate docs for me, we need a smart way of storing assets and a reliable verification process for clients, not more cloud services.
I'm not really sure why we haven't seen a language that takes friendly TS syntax that most people know, fix the types & JS legacies & have it compile to native. We will know 95% of the language from day 0, it gets rid of the legacy / odd behaviour & it's plenty fast enough for most. Rust fast? No.. Go fast... probably. We can still work in JS/TS land with ease, but can use a faster & still approachable language on the server. I can only speak for myself, but I enjoy ease of use & I don't need blazing fast 99.9% of the time, so Rust is a step too far & Go is a bit meh. Whitespace significant languages burn my eyes too, so that leaves few modern options. Maybe I am too fussy & unrealistic though 😂
@@everyhandletaken that could he great indeed, but very unlikely to happen imo. Building a new language would also require building a strong set of tools, ecosystem and community. This can work when you have something clearly different to offer like Go and Rust had. But if you have something that looks like TS, but isn't really, and you can't benefit from all the JS/TS ecosystem - and you can only run it on the server - I don't think people would have enough motivations to follow.
@@timmeehan2365 well, I think you could offer a migration path to bring packages over etc- I mean the Rust & Go ecosystems are laughably small in comparison, but they are still popular languages too. Idk, there is a gap that I think a lot of people struggle to decide on a way to fill at the moment & end up bouncing around solutions, none of which might really suit them, given their TS/JS background.
I was about four and a half minutes in when I realized something: I don't use JavaScript and I don't want to. Why am I watching this? Liked anyway because I appreciate you, Theo.
It should be obvious that a code repository for a language should be closely integrated with the language, and in case of an open source language, it should be kept away from control by commercial interests. CPAN worked reasonably fine 30 years ago, and still does, afaik.
We are going to talk about JSR in this video, nop actually, were are going to talk about other things. We are not going to use JSR or actually see how it works, were are just going to do a lazy text read. lol.
You're just going to ignore that composer exists? The nearest thing you can think of is a python package manager? But not the package manager for PHP, one of the languages closest to Javascript in that ecosystem?
8:30 how do you create an executable then? im currently writing a grpc framework and started out with commonjs, then i wanted to switch to esm, but it turn out so many packages dont support esm like pkg, or commander. so i had to move back to commonjs and luckily i had a it saved using github. but i still think this is a really flawed thing.
@@arden6725 ahh you mean like wrapping it and then transpile it to commonjs from esm+typescript? i actually dont like typescript. i started out using vanilla and then tried typescript. i dont like it for prototyping
What I would really like to see is a single package registry for everything. Why does every tool/platform/language need their own? Package resolution may be individual, but in the end everyone downloads a bunch of files and puts them in the filesystem. Standardize the last step and give me a single software that handles that stuff. Maybe we can then work towards easier integration between multiple languages and tools.
It would have been nice if you actually showed JSR instead of just reading the introduction, just so people can see that it is in fact a real thing that works right now.
i think it has turned out pretty good honestly. with the new fullstack frameworks pushing the envelope, i genuinely have a hard time thinking of a reason to develop my api in a language other than ts
I don't want guys like this.... I like this today, that tomorrow.... Defining npm. Npm kinda sucks. But it's been super reliable. Adding golang style url-based dependencies would be great. Also... You know a project is well maintained and has a team because there are docs, types (if you care) and bundled releases. This is the next J's cluster*** extended to my package manager. I do not want all this extra stuff added.
I've had nothing but bad interactions with Isaac. I hope his attitude has changed over the years since the days when he had an open dislike of all other developers and fought with everyone about everything, however small. On the other extreme I have had nothing but good interactions with Guillermo. His involvement in anything always makes me feel like the project will be good and ship.
In an attempt to solve a few issues on the publication side of packages, these projects are nothing but a way to introduce new complexity for all the consumers. They should really understand that the numbers of consumers of npm far exceeds the number of publishers. Ngl, we are in a javascript bubble.
Okay, about "innovation": innovation for the sake of innovation is no go. You have been watching npm do nothing, and do you know why nothing happens? Because nobody really needs anything new. If it was needed for real, there wpuld be a ton of activity around those needs, but because we observe none, it seems only you need that stuff. Or do you? Innovation for sake of innovation is no go
It's still weird to me that so many projects keep getting made for one of the worst programming languages there is. Hopefully WASM leads to JavaScript being replaced in the browser space. I'd love to see some major browser based apps programmed with C.
Kinda think we are losing the freedom of engineering with all of apple like toolsets and frameworks. Everyhting is turing into a paid to develop model. But lately im seeing more and more open source development projects fighting back.
IMO go's packaging system rocks. very simple and intuitive design. And npm looks completely the opposite. No worries fellow developers AI will fix this for us.
Y'all JS devs got way too much drama. Not every part of the stack needs to be a competition. Sometimes there are just sensible ways to do things that you can just run with. Like how Go realized that Git is basically already sufficient as a package registry? Like that.
