It is less about purity and more about why continue improving Deno APIs since now we can handle the stuff with Node or Node-powered library? Especially, if you are driven by profits. That means that all possible hours will be removed from the future Deno API development. Also, it does not force older libraries to adapt and make versions that use Deno API.
What Deno API’s do you miss, compared to Node? It seems like they’re pretty built out?
I’m looking forward to whatever they’re going to do instead of KV, which I tried and is too limited, even for a KV store. (64k values are too small.) Something like Cloudflare’s Durable Objects might be nice.
You can’t “force” maintainers of old libraries to do anything. Deno never had that power. For people who are interested in supporting multiple alternate platforms, jsr.io seems pretty nice?
You should think Deno as standard library for JavaScript/TypeScript. Node was that. How well Node compares to Go/Python for example? We would like to see most used small Node libraries to merged at some level into Deno's standard library so that the amount of dependencies and deprecations would go downwards.
> You can’t “force” maintainers of old libraries to do anything. Deno never had that power. For people who are interested in supporting multiple alternate platforms, jsr.io seems pretty nice?
If enough people find Deno useful enough to skip some old libraries, maintainers are "forced", even thought Deno is not forcing anyone. If they do not adapt, then someone will just create a new library with better practices. In both cases there is pressure for better JS/TS evolution.
