3 ms·

> Could it be that they added node compatibility because people wanted node compatibility I imagine that’s exactly the reason! But they outlined their reasonin

> 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.
  - afavour 1y ago
    Maybe next time instead of name calling you could consider that other people simply have different perspectives to you? I and others are lamenting that the compatibility layer removed incentive to help create a new JS ecosystem that isn’t layers of garbage piled on top of each other. That new ecosystem is what I wanted and Deno is no longer the path to it. If that makes me a “dunce”, so be it.
    - WorldMaker 1y ago
      Have you spent much time on JSR yet? Even for Node projects I've started searching JSR first and comparing JSR scores of libraries. If a project advertises first-class JSR support now, I pay more attention. The compatibility layer works in both directions here. JSR is a fascinating growing home of Typescript-first, typedocs everywhere, ESM-native ecosystem. Most of those install just as well into Node as Deno (though they are easier to use in Deno, by far). I want Typescript-first. I want ESM-native. I have a registry now that gives me some indicator if and how much a package author cares about those things. The compatibility layer didn't remove the incentive for Deno (the Company) to help create a JS ecosystem that isn't just layers of garbage dependencies piled into trenchcoats, the compatibility layer encouraged Deno to expand their horizons and make Node better too by providing a Registry like JSR. I think JSR is a better way to promote a new, fresher JS ecosystem (for all) than restricting what sorts of packages are compatible with the Deno runtime. It's got gamified test scores! It's got provenance data and supply chain transparency! If they hadn't added the compatibility layer to Deno too many people would have chicken-and-egg excuses that all the packages they need are in npm and never even tried Deno. With the compatibility layer in place Deno gets to shine in its own place of what it can do better than Node, then suggest you try JSR in all your hobby projects, then get you using JSR even in Production on Node packages until it is even easier to convince your day job to switch to Deno for better performance and increased security and deep OpenTelemetry support… Deno's still helping a lot to create a new JS ecosystem with fewer layers of garbage, compatibility or not with the old layers of garbage.
nchmy 1y ago
Evidently people didn't sufficiently value the technical promise of Deno and just wanted a (MUCH) better node. But, it also has plenty of new, bold, extra things (a sibling comment elaborates on it much better than I can). I, for one, am quite happy with it. Given that you still use Node, you might want to try Deno 2 out... It'll likely solve a lot of your headaches.
- afavour 1y ago
  I’ve tried it, I like it, but the positives for me personally aren’t worth investing in a VC backed product. I don’t have many headaches with Node itself these days.

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.
- afavour 1y ago
  Maybe next time instead of name calling you could consider that other people simply have different perspectives to you? I and others are lamenting that the compatibility layer removed incentive to help create a new JS ecosystem that isn’t layers of garbage piled on top of each other. That new ecosystem is what I wanted and Deno is no longer the path to it. If that makes me a “dunce”, so be it.
  - WorldMaker 1y ago
    Have you spent much time on JSR yet? Even for Node projects I've started searching JSR first and comparing JSR scores of libraries. If a project advertises first-class JSR support now, I pay more attention. The compatibility layer works in both directions here. JSR is a fascinating growing home of Typescript-first, typedocs everywhere, ESM-native ecosystem. Most of those install just as well into Node as Deno (though they are easier to use in Deno, by far). I want Typescript-first. I want ESM-native. I have a registry now that gives me some indicator if and how much a package author cares about those things. The compatibility layer didn't remove the incentive for Deno (the Company) to help create a JS ecosystem that isn't just layers of garbage dependencies piled into trenchcoats, the compatibility layer encouraged Deno to expand their horizons and make Node better too by providing a Registry like JSR. I think JSR is a better way to promote a new, fresher JS ecosystem (for all) than restricting what sorts of packages are compatible with the Deno runtime. It's got gamified test scores! It's got provenance data and supply chain transparency! If they hadn't added the compatibility layer to Deno too many people would have chicken-and-egg excuses that all the packages they need are in npm and never even tried Deno. With the compatibility layer in place Deno gets to shine in its own place of what it can do better than Node, then suggest you try JSR in all your hobby projects, then get you using JSR even in Production on Node packages until it is even easier to convince your day job to switch to Deno for better performance and increased security and deep OpenTelemetry support… Deno's still helping a lot to create a new JS ecosystem with fewer layers of garbage, compatibility or not with the old layers of garbage.

nchmy 1y ago

Evidently people didn't sufficiently value the technical promise of Deno and just wanted a (MUCH) better node. But, it also has plenty of new, bold, extra things (a sibling comment elaborates on it much better than I can). I, for one, am quite happy with it. Given that you still use Node, you might want to try Deno 2 out... It'll likely solve a lot of your headaches.

afavour 1y ago
I’ve tried it, I like it, but the positives for me personally aren’t worth investing in a VC backed product. I don’t have many headaches with Node itself these days.