Tracking where open resources like timers were invoked is something that is quite literally a game changer
People sleep on how good the Deno test runner is, but I can't for the life of me stress enough how many times the resource leak feature has saved my ass (developer of x/postgres)
They are different, currently no Deno registries have dynamic version resolution (no greater than operator). Once you have locked in on a version you are in it for good unless you change it manually
However if the argument is: updating libraries break stuff, that is gonna happen every time in every language. There is no guarantee the next version will just work as the last one did
If I have learned anything from working long time with NPM is you can't trust a single command with updating your dependencies and you can't trust developers to respect semver on the long run.
I can't stress how many times I had to review and undo automated dependency bumps because my app suddenly stopped working, and the times I was forced to I had to bump said dependencies in the lock file myself
In a compiled language, where code is compiled once and valid there 'til the end of times this is not even a problem. In an interpreted language where all code is evaluated every time you run your program, this makes automated dependency management an impossible task
For frontend TypeScript I assume you mean TypeScript that doesn't use JS modules but extensionless modules, the TypeScript folks sadly have decided to not bring compatibility here ATM.
You don't ever lose productivity or knowledge on a tool when a new one comes out though. A new thing that people like becomes popular and people start using it, old one becomes less used but it doesn't dissapear.
You only really "switch" to a new tool if that's what you like the most, not because that's what people like now.
They had to remove it from the Deno build process so Deno internals didn't need a compiler. However TypeScript support remains untouched and receives constant updates