This definitely looks like a bit more complicated indeed.
But I like that someone is working on a standardized alternative to bundling, which also comes with its host of problems:
- it makes debugging harder (I know source maps, but they are not a full replacement to just plain old javascript files downloaded separately by the browser and come with their own costs)
- when you want to update something, the whole bundles needs to be updated, and every clients needs to redownload everything from scratch - for applications that are deployed often, you might as well not have cache at all
- bundles are often full of unused parts, and dead code elimination doesn't do everything because you can't determine if a code is dead for everything
- they are hard on unreliable connections / slow hardware: there's one big thing to download and then parse, and if the connection fails in the middle, you probably have to redownload everything again. But then again, having to connect to many hosts or to download many files is also problematic in its own way.
- they mix up dependency management, compiling optimization, polyfilling, browser support… it's a mess, especially when you want to address one of those issues separately, or just to set it up. You end up depending on some bundle you don't control that makes choices different from what you would have made.
- The centralization has issues. Now, it sounds like we are back to centralized again with JSR, I hope someone can provide their own JSR server if they want to. It doesn't seem impossible from a cursory read.
The problem here is orthogonal to bundling, unless I've missed something in the discussion. You can have a Node/NPM-style package manager without doing bundling, and you can bundle together a Deno project if you wanted.
Bundling is mainly a front-end technique used for performance reasons - you don't want to resolve and load each import separately, so you combine all the files into a single one for the sake of efficiency. But for server-side Javascript - be that NodeJS or Demo - you typically don't need to bundle anything because resolving files doesn't take a slow network call.
IMO Package.json is beautiful. Become gold standard for package management. But it looks like deno seriously hates npm, and cooking up solutions like this. If npm had to be replaced they could do go like packagement with direct links to github. Which package.json already supports.
I think the biggest issue with npm these days is the same as Node.js in general... you wind up in a weird effort to mix/use ESM and CJS packages, which winds up being a bit of a convoluted mess. Where Deno/jsr is based in TS/JS source trees with ESM patterns as the primarily supported method, with npm/cjs as a compatibility shim.
Http (with and without import-maps) supports direct links to github as well.
