Node compatibility isn’t a language feature, though, and it doesn’t result in “colored” functions. If a Deno library uses a Node API or an npm library somewhere, it can be entirely encapsulated, so you might not even notice until you see it in a stack trace. That doesn’t seem very intrusive?
So it reminds me more of trying to avoid CGO in Go or avoid “unsafe” in Rust.
It would be worse if Node-specific types started appearing as function parameters or return types, but that seems fairly rare even in npm libraries, so it seems easy to avoid.
> If a Deno library uses a Node API or an npm library somewhere, it can be entirely encapsulated, so you might not even notice until you see it in a stack trace. That doesn’t seem very intrusive?
Node API yes, NPM library no. If you add a dependency on a library that uses NPM you now depend on an entire web of transitive NPM dependencies, with all of the problems that entails. People don't dislike NPM because it's aesthetically displeasing—you can't just abstract away the problems with NPM. The ecosystem causes real problems with real software, and Deno initially recognized those real problems and set out to reset the ecosystem.
The only way in which NPM-compat is different than colored functions is that there's no static compiler feature telling you when you've added a dependency on a bunch of NPM libraries.
I think that’s best addressed by avoiding dependencies and looking for libraries with few indirect dependencies. There are lots of npms that advertise few or no dependencies as a feature.
Though, it is nicer if it’s on jsr.io because you’ll see Typescript source code in the debugger.
There’s nothing about starting over that prevents ending up with a whole new rat’s nest of dependencies, if you’re not careful.
I'm not saying it's a realistic view, but I had hoped without any inclusions from NPM there would exist a couple more clean-room (or at least decoupled) implementations of things in TS, leaving everything JS behind.
So it reminds me more of trying to avoid CGO in Go or avoid “unsafe” in Rust.
It would be worse if Node-specific types started appearing as function parameters or return types, but that seems fairly rare even in npm libraries, so it seems easy to avoid.