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.
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.