Hacker News Reader

Comment by nchmy | Hacker News Reader

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

View on HN

> 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

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.

Announcing Oden...

when it hits 1.0 they can feature freeze and call it "done"

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.

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.

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.

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.

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.

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.

> "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?

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.

> 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.

Deno created JSR, and it already has TS (node may take a while to implement that) and plenty more.

JSR is essentially NPM with a couple of extra improvements.

And it's only a matter of time until Node has full TS support.

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.

Reply on news.ycombinator.com