Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reports of Deno's Demise Have Been Greatly Exaggerated

deno.com

Post reply on HN
Print view View original

181–190 of 210 posts

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#181

Post by danbolt »

skybrian wrote: post #45
mattlondon wrote: post #6

I was super-excited about Deno right up until they threw away their earlier commitments and added backwards compatibility for node and all the shite that comes with it. The whole selling point for me was that deno was node without the bullshit and baggage, but they dropped that and basically just turned it into node with built in typescript support and a few other minor things like the permissions. Similar story with…

Why do you treat adding a feature (npm compatibility) like you’re losing something? You don’t have to use any Node API’s in your app - Deno’s API’s are pretty comprehensive. You can also stick with the libraries available on jsr.io if you’re satisfied with what you can find there. If you want the developer experience of using something that’s not Node, you can still get it from Deno. But it turns out that few people…

I haven’t used Deno, but I can imagine it can be a bit like finding a C library that doesn’t malloc under the hood. You end up having to search through a hidden subset of the broader ecosystem.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#182

Post by WorldMaker »

afavour wrote: post #164
nchmy wrote: post #162

Earlier quoted context omitted.

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.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#183

Post by rtpg »

int_19h wrote: post #169
rtpg wrote: post #56

Earlier quoted context omitted.

by adding node compatibility it reduces pressure for libs to be written "the deno way". Libraries that could be cleaner! At least that's the theory. To be honest I don't see Deno's value add. The runtime is like... I mean node works fine at this point? And the capabilities system is both too pedantic and too simplistic, so it's not actually useful. I don't understand the value add of Bun much either. "Native" Typescr…

Bundler is for shipping code, but then you need hacks like tsx to use TS in tests, build scripts etc, and configuring all that can be surprisingly gnarly and prone to breakage (e.g. tsx uses unstable Node APIs). Although now that Node itself has basic TS support with type-stripping, this substantially improves matter. But that's a fairly recent thing, both Deno and Bun predate it by a long time. Also Bun has a built-…

what I've done is run the bundler across test code so that my test suite is also "just" JS, but that precludes certain kind of code flows without some hacks, so I get why people don't like it much.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#184

Post by drewbitt »

teucris wrote: post #127

I’m seeing some debate on Deno’s decision to ensure Node compatibility, apparently as it gives up a core value prop of early Deno to try and hit the reset button. Can someone help me understand what was lost here? Is there no longer a way to use Deno without using the Node ecosystem?

It adds complexity. Instead of being forced to do things the Deno way, now users don't migrate at all from node code and then (not unreasonably, due to their mission of node compat) complain when they don't work. A large amount of feature work stalled due to the node compat work for over a year. Even now, in 2.3.0 over 30% of all listed changelog items are node compat. They started pushing you to use config files to better integrate with your dependencies as a new default. etc

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#186

Post by anon7000 »

skybrian wrote: post #54
diggan wrote: post #11

> There’s been some criticism lately about Deno - about Deploy, KV, Fresh, and our momentum in general. It seems like they never replied to the criticism against their momentum (something I haven't seen myself, what would the argument even be), was that intentional or just missed? > Some of that criticism is valid. Would have been great to also outline what criticism is/was valid, and how they're aiming to solve thos…

Here’s how they addressed momentum: > Since the release of Deno 2 last October - barely over six months ago! - Deno adoption has more than doubled according to our monthly active user metrics. The obvious question is: doubled, but compared to what? And what are they measuring? They’re not disclosing any real metrics on adoption. I think what happened is that people were giving them the benefit of the doubt because th…

Monthly active users is a real measurement.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#187

Post by anon7000 »

sholladay wrote: post #81

I was excited about Deno precisely because it was a greenfield approach without backwards compatibility. Early on, they focused on reducing complexity and it worked. There were definitely some new pain points compared to Node, but I found them pretty manageable. At some point, rather than coming up with native solutions to those pain points, they retreated and started leaning on backwards compatibility as a workaroun…

Why are you complaining about npm compatibility while also complaining that they don’t have enough compatibility? Sounds like you want it both ways — for it to be very simple and purposeful, but also to broadly support lots of options from the Node ecosystem.

Their purpose is to be a single toolchain & system for JS, and they’re solving a lot of problems in that area. No need to configure huge number of tools for a reasonable professional, production setup — even built in Otel! And if that’s their goal, why would they spend time on complete eslint compatibility? That’s the old world.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#188

Post by int_19h »

rtpg wrote: post #183
int_19h wrote: post #169

Earlier quoted context omitted.

Bundler is for shipping code, but then you need hacks like tsx to use TS in tests, build scripts etc, and configuring all that can be surprisingly gnarly and prone to breakage (e.g. tsx uses unstable Node APIs). Although now that Node itself has basic TS support with type-stripping, this substantially improves matter. But that's a fairly recent thing, both Deno and Bun predate it by a long time. Also Bun has a built-…

what I've done is run the bundler across test code so that my test suite is also "just" JS, but that precludes certain kind of code flows without some hacks, so I get why people don't like it much.

I'm also doing this in Node, but it slows things down quite a bit, which for tests in particular can be painful if you have them set up to run automatically in the background.

And for build scripts, it's not a usable approach because those are the ones that run the bundler. Now, one can argue that you shouldn't really need static typing for build scripts... and yet I have found valid bugs when switching them from JS to TS in the past.

Anyway, Node is rapidly improving its TS integration story, which is probably translating to less interest in Deno (and Bun). Although in case of Bun, the appeal of having a single coherent tool that covers building, testing, and publishing is very enticing after spending a few years in the Node ecosystem duck taping together various third party solutions to all of these.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#189

Post by hombre_fatal »

pier25 wrote: post #148
skybrian wrote: post #45

Earlier quoted context omitted.

Why do you treat adding a feature (npm compatibility) like you’re losing something? You don’t have to use any Node API’s in your app - Deno’s API’s are pretty comprehensive. You can also stick with the libraries available on jsr.io if you’re satisfied with what you can find there. If you want the developer experience of using something that’s not Node, you can still get it from Deno. But it turns out that few people…

> Why do you treat adding a feature (npm compatibility) like you’re losing something? Because they are losing something. All the time and money they are investing into node compat could have been used towards a Deno first party ecosystem. It's not like they have hundreds millions to spare. Deno is a small company with limited resources. People kept complaining that they couldn't use Deno with NPM packages so Deno end…

I think the upsides of Deno having its own isolated ecosystem are way overstated.

In practice, it would stay a small group of hobbyists responsible for doing weird things like maintaining ports of npm libraries that deno users want, like official SDKs.

It’s a grim end state if you’re trying to be more than that. And it seems to only appeal to people with a weird vendetta against Node/NPM which is also a crappy user to cater to.

Re: Reports of Deno's Demise Have Been Greatly Exaggerated

#190

Post by yencabulator »

rafram wrote: post #57

I’m not sure why anyone would want their JS runtime to be their package manager, code formatter, compiler, bundler, web framework, KV store, and cloud provider(!) all at the same time. There’s just no way that they can ship the best product in all of those categories.

Skip the last 3 and it's a pretty sweet combo.
Post reply on HN