IMHO, the decoupling of build step and runtime step in JavaScript was a terrible mistake. I've wasted hours just trying to find tsconfig settings that are compatible with the other parts I'm using. Shipping a transpiler with a known-good configuration alongside the runtime forces everyone to write their packages in a way that are compatible with that configuration, instead of creating a wild west.
The current state of modules and npm reminds me a bit of the bad old ”php.ini” days, where you would have to make sure you enabled the language features enabled by the code you wanted to import. What a mess.
Deno only “solves” that problem by not having a legacy ecosystem, and that’s only if you stick to the happy path of only using modules with first class Deno support. If you try to tap into the vast Node ecosystem, where Deno’s lacking, through e.g. esm.dev, you can waste hours just as easily. Even packages that claim Deno support sometimes have minor problems.
Also speaking of wild west, Deno did not even manage to have their TS be the same as everyone else, as apparently they do import with .ts file extension, while everyone else is using .js. I feel like this would be creating more mess than fixing anything...
