5 ms·

I’m sure a bunch of the criticism of Deno is exaggerated. But there’s something fundamental holding me back from investing my time in Deno, or Bun for that matt

I’m sure a bunch of the criticism of Deno is exaggerated. But there’s something fundamental holding me back from investing my time in Deno, or Bun for that matter: they’re both VC funded. The post is a good illustration of why that matters. Very little of it is about Deno itself, instead it’s mostly about the paid-for services Deno Inc offers. They have to prioritise and chase that because their investors want to see financial growth. It’s the same reason they abandoned the idea of Deno being a fresh start in the JS ecosystem (an idea I loved) and instead started patching in Node compatibility layers. They had to reduce friction, not add to it. But for me that compromised the reason for using it in the first place. Node has many flaws. And it’s boring. But its existence doesn’t depend upon the whims of random investors who might decide to pull the plug at any moment. So I’m just going to stick with it.

nchmy 1y ago
Could it be that they added node compatibility because people wanted node compatibility. If investors pushed for it as well, then they were just being sensible... I started working with JS/TS just before Deno 2 came out and having, essentially, full node (and TypeScript) compatibility was the primary reason I switched to it. It is all just so simple in comparison to node. But, I agree about the VC funding - it certainly gives cause for concern about Deno's direction and longevity. But what other option is there, really? Hopefully what was said in this post about reduction of Deno Deploy locations being a function of use rather than economics was true
- afavour 1y ago
  > Could it be that they added node compatibility because people wanted node compatibility I imagine that’s exactly the reason! But they outlined their reasoning for a clean break pretty well in their 1.0 announcement post[1] and they haven’t, to my knowledge, posted a follow up “here’s why we were wrong about all that” post. All of which is to say I understand the business reasons why they did it, but to me it compromises the original technical promise of Deno. A rebooted, sensible JS ecosystem was the reason I was interested in Deno originally. I use Node every day and I’m mostly happy with it but whenever I need to dive into a dependency to see what’s going on it’s a five layer deep rats nest of transpiled and sometimes even minifed code using different module formats and platform specific APIs. I’d love to be done with all that. Sometimes it pays to be bold when you’re challenging an entrenched incumbent. Any non-Node JS platform has to pitch "don't use the status quo, take a risk, use me" and absent the original benefit I don’t see a good argument to use Deno, especially when factoring in the risk of VC-driven priorities. I’m not saying everyone has to agree with me on that but it’s my personal perspective. [1] https://deno.com/blog/v1 https://deno.com/blog/v1
  - bityard 1y ago
    I almost never write server-side JS/TS so I don't have a horse in this race, but it sounds like a good time and reason for a community fork that eschews legacy compatibility in order to focus on only modern features.
    - afavour 1y ago
      Announcing Oden...
      - zem 1y ago
        when it hits 1.0 they can feature freeze and call it "done"
  - WorldMaker 1y ago
    A lot of the boldness stands though, even with the compatibility layer, and it's a "layer" more than a pivot for Deno. deno.json is still far simpler than package.json. Deno still takes a batteries included approach with smart defaults by default. Deno still pushes you toward a modern-standards "native" approach: ESM by default; ESM native libraries including a growing "standard library" on JSR; your dependency graph is still mostly an importmap you can also dump directly into a browser, too (even some of the compatibility shims with the npm ecosystem). Deno still has a permissions model that is very different and far more opt-in than Node. This post makes a case for thinking of Deno's deep, native OpenTelemetry support as something very new and different from Node's approach, and clearly important to the future of application deployment and observability. Technically Deno is still very interesting in technical promise, especially compared to Node, even with a larger compatibility layer.
    - nchmy 1y ago
      You nailed it. Its incredible how many dunces here are lamenting how Deno abandoned everything, when all they really did was add a compatibility layer.
- wink 1y ago
  yes of course, more people probably wanted node compat than people explicitly didn't want it (like the person who you replied to, and me too). You have to decide where to go and apparently not being a niche product was one the reasons, that's fine - but now they have to live with at least 2+ unhappy (ex?) users.
- pier25 1y ago
  > If investors pushed for it as well, then they were just being sensible... Not really. The biggest issue with Node is the dependance on the fragile NPM ecosystem. Strategically, fixing this is the thing that would distinguish Deno and make it more valuable. And Node is already adding TS and other features that were initially the reason to leave for Deno.
  - nchmy 1y ago
    Deno created JSR, and it already has TS (node may take a while to implement that) and plenty more.
    - pier25 1y ago
      JSR is essentially NPM with a couple of extra improvements. And it's only a matter of time until Node has full TS support.
- vegadw 1y ago
  > "But what other option is there, really?" Not taking VC funding, having slow organic growth, making a good product, and having pride in your work? Like, maybe I'm missing something, but why does the end goal always have to be VC funding and acquisition? Is it too much to ask to stay independent and just make something you take pride in and enjoy the craft over many years of a successful, but not self-canibalizing, business? I dunno man, I just keep seeing every smaller business's end goal to be acquired or turn into a money pumping SASS and it's just depressing. Lets make good things, enjoy delivering a product that people like, and spread good. Keep you and, if you have employees, making a good living and be happy?
  - nchmy 1y ago
    Have you considered that its a much larger job than someone can just bootstrap? Also, Node itself was initially sponsored by a corporate entity, and it lead to considerable problems as well. Now it has backing in many other ways. Also, are you aware that Deno is being built by literally the creator of Node? This isn't some get rich quick scheme - its something that he deeply wants to see exist. He's also leading the charge against Oracle (a genuine parasite) for the copyright/trademark of Javascript.
lolinder 1y ago
Yep. Honestly, the pivot to Node/NPM compatibility was the moment I lost interest in Deno. I know why they did it, and as you say from a financial perspective it makes complete sense, but they had the chance to be a fresh start to the whole ecosystem and they gave that up. I really like coding in TypeScript and think that most of people's irritation with JavaScript isn't actually related to the language so much as the ecosystem of NPM. The exponentially growing web of dependencies and the constant churn of deprecations are exhausting, detracting from a core language that is now pretty solid. Deno set out to change that and be something new, but they squandered that chance because it was too risky for their investors. And again, that's totally fair—resetting an ecosystem is risky and probably wouldn't have yielded the return they needed! But giving up on that was giving up on what made Deno different and interesting. If I'm going to use NPM anyway why not stick with Node while I'm at it?
- skydhash 1y ago
  Yeah. JavaScript is fine if you’re dealing with the DOM and vendor libraries, or if you’re using it in some scripting environment like GNOME. Node were ok too, but failed to develop a standard library like Go or Python. Addressing that failure would go a long way towards a better JS ecosystem.
  - skybrian 1y ago
    Deno’s standard libraries [1] seem pretty nice, but to be honest I never used them much, because lots of stuff on MDN works fine in Deno. [1] https://jsr.io/@std https://jsr.io/@std
    - indigodaddy 1y ago
      I stumbled upon Deno when I needed to spin up a simple API to add to/update a CSV file, and really the only thing I found was deno-csv library, and it worked great. I was pleased with how easy it was with Deno, had it going in under an hour.
- the_gipsy 1y ago
bredren 1y ago
Yes. And m this is also why Poetry remains good enough in the face of PDM. That said, next.js achieved widespread adoption and displaced create react app. And however you feel about the framework, react itself, are possibly reasons to believe. What others are out there?
ramesh31 1y ago
>And it’s boring. This is a feature. Once upon a time, Node was the new hotness that all the cutting edge hackers were excited to play around with, and needed a hard sell to management. It has since graduated to IBM status - i.e. "no one ever got fired for...". And thank god for that. It's the most mature possible ecosystem choice at this point for the niche it fills, and we are able to build rock solid maintainable systems with it (and hire people who know it deeply). That didn't come cheaply or easily (IO.js drama anyone?), and anything that wants to take its place will need to make it through the same process.
Lerc 1y ago
>it’s mostly about the paid-for services Deno Inc offers. In a way I think that's a good thing. Their plan for making money is to provide those services. That goal is enhanced by Deno being healthy. I would be more concerned if Deno was the product they were wanting to sell. As long as Deno itself is FOSS, then I think I'm ok with it.
- WorldMaker 1y ago
  Also, I've been using Deno Deploy for hobby projects and it is a delight to work with so far. In terms of finding a product that is a good complement to the open source Deno, they seem to have good ideas. Though I'm still in the VC-subsidized freeloader category in my hobby usage today, so I haven't experienced it yet as a paid product.
1vuio0pswjnm7 1y ago
"But there's something fundamental holding me back from investing my time in Deno, or Bun for that matter: they're both VC funded." For me it is the lack of support for musl. Perhaps there is a connection between inattention to certain details and being VC-funded.
deleted 1y ago
[deleted]
deleted 1y ago
[deleted]

nchmy 1y ago

Could it be that they added node compatibility because people wanted node compatibility. If investors pushed for it as well, then they were just being sensible... I started working with JS/TS just before Deno 2 came out and having, essentially, full node (and TypeScript) compatibility was the primary reason I switched to it. It is all just so simple in comparison to node. But, I agree about the VC funding - it certainly gives cause for concern about Deno's direction and longevity. But what other option is there, really? Hopefully what was said in this post about reduction of Deno Deploy locations being a function of use rather than economics was true

afavour 1y ago
> Could it be that they added node compatibility because people wanted node compatibility I imagine that’s exactly the reason! But they outlined their reasoning for a clean break pretty well in their 1.0 announcement post[1] and they haven’t, to my knowledge, posted a follow up “here’s why we were wrong about all that” post. All of which is to say I understand the business reasons why they did it, but to me it compromises the original technical promise of Deno. A rebooted, sensible JS ecosystem was the reason I was interested in Deno originally. I use Node every day and I’m mostly happy with it but whenever I need to dive into a dependency to see what’s going on it’s a five layer deep rats nest of transpiled and sometimes even minifed code using different module formats and platform specific APIs. I’d love to be done with all that. Sometimes it pays to be bold when you’re challenging an entrenched incumbent. Any non-Node JS platform has to pitch "don't use the status quo, take a risk, use me" and absent the original benefit I don’t see a good argument to use Deno, especially when factoring in the risk of VC-driven priorities. I’m not saying everyone has to agree with me on that but it’s my personal perspective. [1] https://deno.com/blog/v1 https://deno.com/blog/v1
- bityard 1y ago
  I almost never write server-side JS/TS so I don't have a horse in this race, but it sounds like a good time and reason for a community fork that eschews legacy compatibility in order to focus on only modern features.
  - afavour 1y ago
    Announcing Oden...
    - zem 1y ago
      when it hits 1.0 they can feature freeze and call it "done"
- WorldMaker 1y ago
  A lot of the boldness stands though, even with the compatibility layer, and it's a "layer" more than a pivot for Deno. deno.json is still far simpler than package.json. Deno still takes a batteries included approach with smart defaults by default. Deno still pushes you toward a modern-standards "native" approach: ESM by default; ESM native libraries including a growing "standard library" on JSR; your dependency graph is still mostly an importmap you can also dump directly into a browser, too (even some of the compatibility shims with the npm ecosystem). Deno still has a permissions model that is very different and far more opt-in than Node. This post makes a case for thinking of Deno's deep, native OpenTelemetry support as something very new and different from Node's approach, and clearly important to the future of application deployment and observability. Technically Deno is still very interesting in technical promise, especially compared to Node, even with a larger compatibility layer.
  - nchmy 1y ago
    You nailed it. Its incredible how many dunces here are lamenting how Deno abandoned everything, when all they really did was add a compatibility layer.
wink 1y ago
yes of course, more people probably wanted node compat than people explicitly didn't want it (like the person who you replied to, and me too). You have to decide where to go and apparently not being a niche product was one the reasons, that's fine - but now they have to live with at least 2+ unhappy (ex?) users.
pier25 1y ago
> If investors pushed for it as well, then they were just being sensible... Not really. The biggest issue with Node is the dependance on the fragile NPM ecosystem. Strategically, fixing this is the thing that would distinguish Deno and make it more valuable. And Node is already adding TS and other features that were initially the reason to leave for Deno.
- nchmy 1y ago
  Deno created JSR, and it already has TS (node may take a while to implement that) and plenty more.
  - pier25 1y ago
    JSR is essentially NPM with a couple of extra improvements. And it's only a matter of time until Node has full TS support.
vegadw 1y ago
> "But what other option is there, really?" Not taking VC funding, having slow organic growth, making a good product, and having pride in your work? Like, maybe I'm missing something, but why does the end goal always have to be VC funding and acquisition? Is it too much to ask to stay independent and just make something you take pride in and enjoy the craft over many years of a successful, but not self-canibalizing, business? I dunno man, I just keep seeing every smaller business's end goal to be acquired or turn into a money pumping SASS and it's just depressing. Lets make good things, enjoy delivering a product that people like, and spread good. Keep you and, if you have employees, making a good living and be happy?
- nchmy 1y ago
  Have you considered that its a much larger job than someone can just bootstrap? Also, Node itself was initially sponsored by a corporate entity, and it lead to considerable problems as well. Now it has backing in many other ways. Also, are you aware that Deno is being built by literally the creator of Node? This isn't some get rich quick scheme - its something that he deeply wants to see exist. He's also leading the charge against Oracle (a genuine parasite) for the copyright/trademark of Javascript.

lolinder 1y ago

Yep. Honestly, the pivot to Node/NPM compatibility was the moment I lost interest in Deno. I know why they did it, and as you say from a financial perspective it makes complete sense, but they had the chance to be a fresh start to the whole ecosystem and they gave that up. I really like coding in TypeScript and think that most of people's irritation with JavaScript isn't actually related to the language so much as the ecosystem of NPM. The exponentially growing web of dependencies and the constant churn of deprecations are exhausting, detracting from a core language that is now pretty solid. Deno set out to change that and be something new, but they squandered that chance because it was too risky for their investors. And again, that's totally fair—resetting an ecosystem is risky and probably wouldn't have yielded the return they needed! But giving up on that was giving up on what made Deno different and interesting. If I'm going to use NPM anyway why not stick with Node while I'm at it?

skydhash 1y ago
Yeah. JavaScript is fine if you’re dealing with the DOM and vendor libraries, or if you’re using it in some scripting environment like GNOME. Node were ok too, but failed to develop a standard library like Go or Python. Addressing that failure would go a long way towards a better JS ecosystem.
- skybrian 1y ago
  Deno’s standard libraries [1] seem pretty nice, but to be honest I never used them much, because lots of stuff on MDN works fine in Deno. [1] https://jsr.io/@std https://jsr.io/@std
  - indigodaddy 1y ago
    I stumbled upon Deno when I needed to spin up a simple API to add to/update a CSV file, and really the only thing I found was deno-csv library, and it worked great. I was pleased with how easy it was with Deno, had it going in under an hour.
the_gipsy 1y ago

bredren 1y ago

Yes. And m this is also why Poetry remains good enough in the face of PDM. That said, next.js achieved widespread adoption and displaced create react app. And however you feel about the framework, react itself, are possibly reasons to believe. What others are out there?

ramesh31 1y ago

>And it’s boring. This is a feature. Once upon a time, Node was the new hotness that all the cutting edge hackers were excited to play around with, and needed a hard sell to management. It has since graduated to IBM status - i.e. "no one ever got fired for...". And thank god for that. It's the most mature possible ecosystem choice at this point for the niche it fills, and we are able to build rock solid maintainable systems with it (and hire people who know it deeply). That didn't come cheaply or easily (IO.js drama anyone?), and anything that wants to take its place will need to make it through the same process.

Lerc 1y ago

>it’s mostly about the paid-for services Deno Inc offers. In a way I think that's a good thing. Their plan for making money is to provide those services. That goal is enhanced by Deno being healthy. I would be more concerned if Deno was the product they were wanting to sell. As long as Deno itself is FOSS, then I think I'm ok with it.

WorldMaker 1y ago
Also, I've been using Deno Deploy for hobby projects and it is a delight to work with so far. In terms of finding a product that is a good complement to the open source Deno, they seem to have good ideas. Though I'm still in the VC-subsidized freeloader category in my hobby usage today, so I haven't experienced it yet as a paid product.

1vuio0pswjnm7 1y ago

"But there's something fundamental holding me back from investing my time in Deno, or Bun for that matter: they're both VC funded." For me it is the lack of support for musl. Perhaps there is a connection between inattention to certain details and being VC-funded.

deleted 1y ago

[deleted]

deleted 1y ago

[deleted]