8 ms·

Deno is becoming more and more useful, but at the same time it feels like the project moves further and further away from the initial presentation of ry.

Already__Taken 3y ago
one of the main take aways I got from Ryan's deno intro was pragmatism over preferences.
- lolinder 3y ago
  Are we talking about the same talk? 10 Things I Regret about Node.js [0]? Goal #2 (after security) was to simplify the module system, and the very first thing he said about that was no node compatibility. [0] https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
  - jitl 3y ago
    Supporting NPM allows the entire ecosystem to gradually migrate from CommonJS/NPM packages to ESM/Deno imports. New developers in Deno will still write pure code - not NPM code that has slow require; they don’t bear any mental complexity - it’s only legacy code that pays a runtime complexity cost.
8K832d7tNmiQ 3y ago
another perspective is that you can gradually move away your project dependencies into deno while still using node modules.
- lolinder 3y ago
  In practice that's not going to happen, though. People will add their npm dependencies and move on, and instead of solving JS dependency hell Deno will become a layer of abstraction on top of it. A lot of us were hoping Deno would do the Gopher thing and force a complete reset. Yes, that means less/slower adoption, but it means that when you pick up a Deno library you know you're not getting all of npm with it. The further we move along the less likely it seems that any Deno project will be able to be npm-free.
  - jitl 3y ago
    What’s the “gopher” thing? A fringe system no one uses in the long run isn’t a reset. It’s a blip.
toastercat 3y ago
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?
rubenfiszel 3y ago
For deno to grow, it needs to be used in production systems. Deno seems to be betting most of it business in serverless/edge deployment (deno deploy, supabase functions, netlify functions). We also support it for self-hosted infra/internal tools production use-case at windmill.dev. The #1 feedback that we get is that people are frustrated that they have this one script or library they cannot use and that otherwise work with node. Deno is a marvelous piece of engineering that require a team of very qualified engineers, those need to get paid, so some tradeoffs need to be made.
- deleted 3y ago
  [deleted]
veidr 3y ago
Maybe, but as an(other) aficionado of Deno for smallish projects where Node is irrelevant, I don't feel like these panders to the mainstream hurt anything. To the contrary, they make every conversation about using Deno easier, even where we don't and won't use Node (including NPM packages). I mean sure, they consume some of their resources that might in some ideal (to me) world be spent on something more relevant (to me), but in this world it seems like engineering resources well spent. ¯\_(ಠ_ಠ)_/¯
benatkin 3y ago
I disagree. If it had become powerful enough for them to support node/npm sooner they would have supported it sooner. Pure Deno stuff like fresh is still packaged in a Golang-like way.
deleted 3y ago
[deleted]

Already__Taken 3y ago

one of the main take aways I got from Ryan's deno intro was pragmatism over preferences.

lolinder 3y ago
Are we talking about the same talk? 10 Things I Regret about Node.js [0]? Goal #2 (after security) was to simplify the module system, and the very first thing he said about that was no node compatibility. [0] https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
- jitl 3y ago
  Supporting NPM allows the entire ecosystem to gradually migrate from CommonJS/NPM packages to ESM/Deno imports. New developers in Deno will still write pure code - not NPM code that has slow require; they don’t bear any mental complexity - it’s only legacy code that pays a runtime complexity cost.

8K832d7tNmiQ 3y ago

another perspective is that you can gradually move away your project dependencies into deno while still using node modules.

lolinder 3y ago
In practice that's not going to happen, though. People will add their npm dependencies and move on, and instead of solving JS dependency hell Deno will become a layer of abstraction on top of it. A lot of us were hoping Deno would do the Gopher thing and force a complete reset. Yes, that means less/slower adoption, but it means that when you pick up a Deno library you know you're not getting all of npm with it. The further we move along the less likely it seems that any Deno project will be able to be npm-free.
- jitl 3y ago
  What’s the “gopher” thing? A fringe system no one uses in the long run isn’t a reset. It’s a blip.

toastercat 3y ago

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?

rubenfiszel 3y ago

For deno to grow, it needs to be used in production systems. Deno seems to be betting most of it business in serverless/edge deployment (deno deploy, supabase functions, netlify functions). We also support it for self-hosted infra/internal tools production use-case at windmill.dev. The #1 feedback that we get is that people are frustrated that they have this one script or library they cannot use and that otherwise work with node. Deno is a marvelous piece of engineering that require a team of very qualified engineers, those need to get paid, so some tradeoffs need to be made.

deleted 3y ago
[deleted]

veidr 3y ago

Maybe, but as an(other) aficionado of Deno for smallish projects where Node is irrelevant, I don't feel like these panders to the mainstream hurt anything. To the contrary, they make every conversation about using Deno easier, even where we don't and won't use Node (including NPM packages). I mean sure, they consume some of their resources that might in some ideal (to me) world be spent on something more relevant (to me), but in this world it seems like engineering resources well spent. ¯\_(ಠ_ಠ)_/¯

benatkin 3y ago

I disagree. If it had become powerful enough for them to support node/npm sooner they would have supported it sooner. Pure Deno stuff like fresh is still packaged in a Golang-like way.

deleted 3y ago

[deleted]