3 ms·

Why do you treat adding a feature (npm compatibility) like you’re losing something? You don’t have to use any Node API’s in your app - Deno’s API’s are pretty c

Why do you treat adding a feature (npm compatibility) like you’re losing something? You don’t have to use any Node API’s in your app - Deno’s API’s are pretty comprehensive. You can also stick with the libraries available on jsr.io if you’re satisfied with what you can find there. If you want the developer experience of using something that’s not Node, you can still get it from Deno. But it turns out that few people care that much about purity, so it’s fortunate that they’re not relying on that.

nicce 1y ago
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.
- skybrian 1y ago
  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?
  - nicce 1y ago
    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.
rtpg 1y ago
by adding node compatibility it reduces pressure for libs to be written "the deno way". Libraries that could be cleaner! At least that's the theory. To be honest I don't see Deno's value add. The runtime is like... I mean node works fine at this point? And the capabilities system is both too pedantic and too simplistic, so it's not actually useful. I don't understand the value add of Bun much either. "Native" Typescript support but at the end of the day I need a bundler that does more than what these tools tend to offer. Now if one of these basically had "esbuild but built in"....
- int_19h 1y ago
  Bundler is for shipping code, but then you need hacks like tsx to use TS in tests, build scripts etc, and configuring all that can be surprisingly gnarly and prone to breakage (e.g. tsx uses unstable Node APIs). Although now that Node itself has basic TS support with type-stripping, this substantially improves matter. But that's a fairly recent thing, both Deno and Bun predate it by a long time. Also Bun has a built-in bundler? I'm not sure how it compares with esbuild tho.
  - rtpg 1y ago
    what I've done is run the bundler across test code so that my test suite is also "just" JS, but that precludes certain kind of code flows without some hacks, so I get why people don't like it much.
    - int_19h 1y ago
      I'm also doing this in Node, but it slows things down quite a bit, which for tests in particular can be painful if you have them set up to run automatically in the background. And for build scripts, it's not a usable approach because those are the ones that run the bundler. Now, one can argue that you shouldn't really need static typing for build scripts... and yet I have found valid bugs when switching them from JS to TS in the past. Anyway, Node is rapidly improving its TS integration story, which is probably translating to less interest in Deno (and Bun). Although in case of Bun, the appeal of having a single coherent tool that covers building, testing, and publishing is very enticing after spending a few years in the Node ecosystem duck taping together various third party solutions to all of these.
lolinder 1y ago
An equivalent argument to yours could be made to defend the introduction of async/await to a language that has previously not had it (edit: like Rust): if you don't like async/await, just don't use it! What does it hurt you to have another feature added? The answer is obvious in the programming language case: for those who do not want async, the addition of async/await begins to poison the ecosystem. Now they have a growing list of libraries that they cannot use if they want to avoid async, so the effort involved in picking a library goes up and the odds get increasingly high that they're locked out of some of the key tools in the ecosystem because new libraries without async become harder and harder to find. For those who really hate colored functions, the addition of async is the removal of a feature: colorless functions are replaced with colored functions. The same can be said of NPM compatibility. Sure, I can try to avoid it and stick to Deno imports and inspect each library that I use for NPM dependencies. But it gets harder and harder as time goes on, because a key feature of Deno has been removed: it's no longer an ecosystem reset.
- skybrian 1y ago
  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.
  - lolinder 1y ago
    > 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.
afavour 1y ago
> Why do you treat adding a feature (npm compatibility) like you’re losing something? Because you are losing something: a better ecosystem. Standardizing around… standards is a good thing. When I dive into the dependencies of any given Node app it’s a mess of transpiled code, sometimes minified even, there’s no guarantee what API it’ll be using and whether it’ll run outside Node (is it using the W3C streams API or the Node streams API?). But inertia is a powerful force. People will just use what’s there if they can. So the ecosystem never gets made. > But it turns out that few people care that much about purity, so it’s fortunate that they’re not relying on that. By that logic we never build anything newer or better. Python 3 is better than Python 2 and sets the language up for a better future. Transitioning between the two was absolutely torturous and if they just prioritised popularity it would never have happened.
- pjmlp 1y ago
  And now Python remains as the quoted example, alongside Perl 6, on what happens when breaking an ecosystem.
pier25 1y ago
> Why do you treat adding a feature (npm compatibility) like you’re losing something? Because they are losing something. All the time and money they are investing into node compat could have been used towards a Deno first party ecosystem. It's not like they have hundreds millions to spare. Deno is a small company with limited resources. People kept complaining that they couldn't use Deno with NPM packages so Deno ended up focusing in providing faster horses.
- hombre_fatal 1y ago
  I think the upsides of Deno having its own isolated ecosystem are way overstated. In practice, it would stay a small group of hobbyists responsible for doing weird things like maintaining ports of npm libraries that deno users want, like official SDKs. It’s a grim end state if you’re trying to be more than that. And it seems to only appeal to people with a weird vendetta against Node/NPM which is also a crappy user to cater to.
  - pier25 1y ago
    I'm not saying Deno should leave the ecosystem up to "a small group of hobbyists". What I'm arguing is that Deno investing in an official ecosystem would have been a better early investment than Node compat.
danbolt 1y ago
I haven’t used Deno, but I can imagine it can be a bit like finding a C library that doesn’t malloc under the hood. You end up having to search through a hidden subset of the broader ecosystem.

nicce 1y ago

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.

skybrian 1y ago
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?
- nicce 1y ago
  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.

rtpg 1y ago

by adding node compatibility it reduces pressure for libs to be written "the deno way". Libraries that could be cleaner! At least that's the theory. To be honest I don't see Deno's value add. The runtime is like... I mean node works fine at this point? And the capabilities system is both too pedantic and too simplistic, so it's not actually useful. I don't understand the value add of Bun much either. "Native" Typescript support but at the end of the day I need a bundler that does more than what these tools tend to offer. Now if one of these basically had "esbuild but built in"....

int_19h 1y ago
Bundler is for shipping code, but then you need hacks like tsx to use TS in tests, build scripts etc, and configuring all that can be surprisingly gnarly and prone to breakage (e.g. tsx uses unstable Node APIs). Although now that Node itself has basic TS support with type-stripping, this substantially improves matter. But that's a fairly recent thing, both Deno and Bun predate it by a long time. Also Bun has a built-in bundler? I'm not sure how it compares with esbuild tho.
- rtpg 1y ago
  what I've done is run the bundler across test code so that my test suite is also "just" JS, but that precludes certain kind of code flows without some hacks, so I get why people don't like it much.
  - int_19h 1y ago
    I'm also doing this in Node, but it slows things down quite a bit, which for tests in particular can be painful if you have them set up to run automatically in the background. And for build scripts, it's not a usable approach because those are the ones that run the bundler. Now, one can argue that you shouldn't really need static typing for build scripts... and yet I have found valid bugs when switching them from JS to TS in the past. Anyway, Node is rapidly improving its TS integration story, which is probably translating to less interest in Deno (and Bun). Although in case of Bun, the appeal of having a single coherent tool that covers building, testing, and publishing is very enticing after spending a few years in the Node ecosystem duck taping together various third party solutions to all of these.

lolinder 1y ago

An equivalent argument to yours could be made to defend the introduction of async/await to a language that has previously not had it (edit: like Rust): if you don't like async/await, just don't use it! What does it hurt you to have another feature added? The answer is obvious in the programming language case: for those who do not want async, the addition of async/await begins to poison the ecosystem. Now they have a growing list of libraries that they cannot use if they want to avoid async, so the effort involved in picking a library goes up and the odds get increasingly high that they're locked out of some of the key tools in the ecosystem because new libraries without async become harder and harder to find. For those who really hate colored functions, the addition of async is the removal of a feature: colorless functions are replaced with colored functions. The same can be said of NPM compatibility. Sure, I can try to avoid it and stick to Deno imports and inspect each library that I use for NPM dependencies. But it gets harder and harder as time goes on, because a key feature of Deno has been removed: it's no longer an ecosystem reset.

skybrian 1y ago
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.
- lolinder 1y ago
  > 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.

afavour 1y ago

> Why do you treat adding a feature (npm compatibility) like you’re losing something? Because you are losing something: a better ecosystem. Standardizing around… standards is a good thing. When I dive into the dependencies of any given Node app it’s a mess of transpiled code, sometimes minified even, there’s no guarantee what API it’ll be using and whether it’ll run outside Node (is it using the W3C streams API or the Node streams API?). But inertia is a powerful force. People will just use what’s there if they can. So the ecosystem never gets made. > But it turns out that few people care that much about purity, so it’s fortunate that they’re not relying on that. By that logic we never build anything newer or better. Python 3 is better than Python 2 and sets the language up for a better future. Transitioning between the two was absolutely torturous and if they just prioritised popularity it would never have happened.

pjmlp 1y ago
And now Python remains as the quoted example, alongside Perl 6, on what happens when breaking an ecosystem.

pier25 1y ago

> Why do you treat adding a feature (npm compatibility) like you’re losing something? Because they are losing something. All the time and money they are investing into node compat could have been used towards a Deno first party ecosystem. It's not like they have hundreds millions to spare. Deno is a small company with limited resources. People kept complaining that they couldn't use Deno with NPM packages so Deno ended up focusing in providing faster horses.

hombre_fatal 1y ago
I think the upsides of Deno having its own isolated ecosystem are way overstated. In practice, it would stay a small group of hobbyists responsible for doing weird things like maintaining ports of npm libraries that deno users want, like official SDKs. It’s a grim end state if you’re trying to be more than that. And it seems to only appeal to people with a weird vendetta against Node/NPM which is also a crappy user to cater to.
- pier25 1y ago
  I'm not saying Deno should leave the ecosystem up to "a small group of hobbyists". What I'm arguing is that Deno investing in an official ecosystem would have been a better early investment than Node compat.

danbolt 1y ago

I haven’t used Deno, but I can imagine it can be a bit like finding a C library that doesn’t malloc under the hood. You end up having to search through a hidden subset of the broader ecosystem.