5 ms·

Agree; I preferred Deno as the small-ish, Web API-compatible, focused JS/TS runtime that wasn't Node compatible. I personally feel all this NPM-compatiblity is

Agree; I preferred Deno as the small-ish, Web API-compatible, focused JS/TS runtime that wasn't Node compatible. I personally feel all this NPM-compatiblity is a big waste of time. That being said, I still like Deno.

lytedev 3y ago
On the other hand, at $DAYJOB, being able to say that Deno has access to everything node can do goes a long way. Not having to reinvent the wheels is definitely nice!
- toastercat 3y ago
  True but I think trying to make a tool useful to everyone's $DAYJOB is kind of overrated. Instead of trying to make the tool the best it can be on its own merits, you're trying to please the millions of folks who already bought into another ecosystem.
  - electroly 3y ago
    This is tough/impossible when you're VC-funded like Deno is. Once they took VC funding, they didn't have a choice but to shoot for the moon. Deno without NPM support wasn't seeing the uptake they wanted.
    - toastercat 3y ago
      Yep, agree. I think things went a little wayward when they took the VC funding.
- pxc 3y ago
  Depends on your role and organizational goals. If you work in application security, it makes Deno harder to recommend, because then the recommendation (or perhaps even mandate) has to come with extra instrumentation in order to enforce the additional security the runtime is supposed to bring. It also makes you question the priorities of the project, given that this is still early days. If the supposed focus on security is already being compromised on and whittled away today, would a recommendation to build with Deno even prove meaningful in 5 or 10 years?
qbasic_forever 3y ago
If you don't use the node compatibility do you even notice or care one bit about it? It doesn't hurt a pure deno project at all.
- lolinder 3y ago
  If Deno has no Node compatibility then you know that no Deno library pulls Node modules in with it, because it's impossible. The more seamless node interop becomes, the harder it will be to sift the Pure Organic Deno libraries from the NPM-infused Deno libraries. So, on the contrary: Node becoming embraced by the wider ecosystem absolutely hurts pure Deno projects because they'll rapidly become perceived as a fundamentalist minority that doesn't need to be catered to, where the original idea was that all projects would be pure.
  - qbasic_forever 3y ago
    I don't buy it, you can already use stuff like skypack or other bundling CDNs to import npm modules in deno just by their URL. You have a very bizarre argument that I don't follow. I don't care about the "purity" of the project, I care about getting shit done and deno is helping greatly there.
    - toastercat 3y ago
      > I don't buy it, you can already use stuff like skypack or other bundling CDNs to import npm modules in deno just by their URL. It's not that simple if the project you are importing uses Node-specific APIs. By the way, this is an area that can really confuse newbies.
    - no_wizard 3y ago
      then you're stuck with a CDN you don't control. The runtime (Deno) being able to work directly with most packages on npm is a huge win because I don't have to trust a 3rd party for this anymore, and that to me is a big win.
      - 3y ago
brundolf 3y ago
It's become clear that it's a hard requirement for wide adoption, especially with the new competition from bun. Personal anecdote: I tried to pitch Deno last year at my job, and as soon as I mentioned that it can't use the NPM ecosystem they went "ahh..." and the conversation basically stopped. So I don't blame the team for being practical. You can still make things better without a clean break
- lolinder 3y ago
  > especially with the new competition from bun Competition seems to always lead companies to drop what makes them special in pursuit of the other guy's customers. They could have chosen to let bun take the npm-compatibility crowd and stick to their guns, but VC funding precludes that.
  - brundolf 3y ago
    You're making some bad-faith assumptions. Ecosystems die without adoption. A runtime that plugs its ears to the practical needs of users is a runtime that nobody but enthusiasts ever use. And you can't build any kind of sustainable business on an enthusiast-only runtime, VC or no VC. Idealism requires pragmatism to succeed.
    - toastercat 3y ago
      I don't disagree with your general sentiment, but you can be pragmatic and useful to users without bending to their every need. It's doesn't mean you're plugging your ears, it means you're being careful. Node and NPM are moving targets; chasing compatibility itself is not practical, and Dahl explicitly mentioned in his intro to Deno that Node compatibility was not a great idea (he was right). If your team/company is reliant on Node packages, it does not make any sense to go for another runtime.
      - pavon 3y ago
        There is a difference between Node compatibility and NPM compatibility though. NPM may have started with Node, but it has become part of the core development process for front-end web development. One of the main purposes of Deno is to decrease the gap between frontend JS development and backend JS development, and adding NPM support furthers that goal. What doesn't make sense is adding a compatibility layer for all the Node specific functionality that has since become redundant with new Web standards.
guykdm 3y ago
I'm using deno in production and npm compat is, for me, a must.
MuffinFlavored 3y ago
> I personally feel all this NPM-compatiblity is a big waste of time. You feel like being compatible with one of (if not the) biggest package management ecosystems for any programming language is a big waste of time?
- toastercat 3y ago
  Yes.
rnmkr 3y ago
No. Deno would've been widely adopted if they were compatible with Node from the beginning.

lytedev 3y ago

On the other hand, at $DAYJOB, being able to say that Deno has access to everything node can do goes a long way. Not having to reinvent the wheels is definitely nice!

toastercat 3y ago
True but I think trying to make a tool useful to everyone's $DAYJOB is kind of overrated. Instead of trying to make the tool the best it can be on its own merits, you're trying to please the millions of folks who already bought into another ecosystem.
- electroly 3y ago
  This is tough/impossible when you're VC-funded like Deno is. Once they took VC funding, they didn't have a choice but to shoot for the moon. Deno without NPM support wasn't seeing the uptake they wanted.
  - toastercat 3y ago
    Yep, agree. I think things went a little wayward when they took the VC funding.
pxc 3y ago
Depends on your role and organizational goals. If you work in application security, it makes Deno harder to recommend, because then the recommendation (or perhaps even mandate) has to come with extra instrumentation in order to enforce the additional security the runtime is supposed to bring. It also makes you question the priorities of the project, given that this is still early days. If the supposed focus on security is already being compromised on and whittled away today, would a recommendation to build with Deno even prove meaningful in 5 or 10 years?

qbasic_forever 3y ago

If you don't use the node compatibility do you even notice or care one bit about it? It doesn't hurt a pure deno project at all.

lolinder 3y ago
If Deno has no Node compatibility then you know that no Deno library pulls Node modules in with it, because it's impossible. The more seamless node interop becomes, the harder it will be to sift the Pure Organic Deno libraries from the NPM-infused Deno libraries. So, on the contrary: Node becoming embraced by the wider ecosystem absolutely hurts pure Deno projects because they'll rapidly become perceived as a fundamentalist minority that doesn't need to be catered to, where the original idea was that all projects would be pure.
- qbasic_forever 3y ago
  I don't buy it, you can already use stuff like skypack or other bundling CDNs to import npm modules in deno just by their URL. You have a very bizarre argument that I don't follow. I don't care about the "purity" of the project, I care about getting shit done and deno is helping greatly there.
  - toastercat 3y ago
    > I don't buy it, you can already use stuff like skypack or other bundling CDNs to import npm modules in deno just by their URL. It's not that simple if the project you are importing uses Node-specific APIs. By the way, this is an area that can really confuse newbies.
  - no_wizard 3y ago
    then you're stuck with a CDN you don't control. The runtime (Deno) being able to work directly with most packages on npm is a huge win because I don't have to trust a 3rd party for this anymore, and that to me is a big win.
    - 3y ago

brundolf 3y ago

It's become clear that it's a hard requirement for wide adoption, especially with the new competition from bun. Personal anecdote: I tried to pitch Deno last year at my job, and as soon as I mentioned that it can't use the NPM ecosystem they went "ahh..." and the conversation basically stopped. So I don't blame the team for being practical. You can still make things better without a clean break

lolinder 3y ago
> especially with the new competition from bun Competition seems to always lead companies to drop what makes them special in pursuit of the other guy's customers. They could have chosen to let bun take the npm-compatibility crowd and stick to their guns, but VC funding precludes that.
- brundolf 3y ago
  You're making some bad-faith assumptions. Ecosystems die without adoption. A runtime that plugs its ears to the practical needs of users is a runtime that nobody but enthusiasts ever use. And you can't build any kind of sustainable business on an enthusiast-only runtime, VC or no VC. Idealism requires pragmatism to succeed.
  - toastercat 3y ago
    I don't disagree with your general sentiment, but you can be pragmatic and useful to users without bending to their every need. It's doesn't mean you're plugging your ears, it means you're being careful. Node and NPM are moving targets; chasing compatibility itself is not practical, and Dahl explicitly mentioned in his intro to Deno that Node compatibility was not a great idea (he was right). If your team/company is reliant on Node packages, it does not make any sense to go for another runtime.
    - pavon 3y ago
      There is a difference between Node compatibility and NPM compatibility though. NPM may have started with Node, but it has become part of the core development process for front-end web development. One of the main purposes of Deno is to decrease the gap between frontend JS development and backend JS development, and adding NPM support furthers that goal. What doesn't make sense is adding a compatibility layer for all the Node specific functionality that has since become redundant with new Web standards.

guykdm 3y ago

I'm using deno in production and npm compat is, for me, a must.

MuffinFlavored 3y ago

> I personally feel all this NPM-compatiblity is a big waste of time. You feel like being compatible with one of (if not the) biggest package management ecosystems for any programming language is a big waste of time?

toastercat 3y ago
Yes.

rnmkr 3y ago

No. Deno would've been widely adopted if they were compatible with Node from the beginning.