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

161–170 of 210 posts

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

#161

Post by nchmy »

pier25 wrote: post #120
nchmy wrote: post #15

Earlier quoted context omitted.

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 certai…

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

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

#162

Post by nchmy »

WorldMaker wrote: post #133
afavour wrote: post #94

Earlier quoted context omitted.

> 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 compro…

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…

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.

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

#163

Post by pier25 »

nchmy wrote: post #161
pier25 wrote: post #120

Earlier quoted context omitted.

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

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

#164

Post by afavour »

nchmy wrote: post #162
WorldMaker wrote: post #133

Earlier quoted context omitted.

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…

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.

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

#165

Post by ctz »

k__ wrote: post #99

It might just be my perception, but I had the impression Deno got his ass whooped by Bun and Node.js. While some people whine about the Node.js compat, I'd assume it's the main point that kept Deno on life-support in the long run. Bun did it right from the start and it seems people love it. Being quite a bit faster than Node.js (even with the compat APIs) and Deno obviously helps too. If they keep that going, they'd…

It is instructive to compare Bun and Deno's issue tracker. Like, the five most recent issues for Bun at the time of writing are all crashes. Some of these are controlled panics or assertion failures, but others are like "we are now executing from address -1" or "we are trying to read from address 0x00000069." Recently written software simply should not have these classes of problem.

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

#166

Post by HideousKojima »

lolinder wrote: post #154
HideousKojima wrote: post #131

Earlier quoted context omitted.

>but every time I've tried to figure out how to install it I get lost in the morass of nearly-identical names for totally different platforms and forget which one I'm supposed to be installing on Linux these days. I realize Microsoft is terrible at naming things, but for .NET/C# it's really not that hard these days. If you want to use the new, cross platform .NET on Linux then just install .NET 8 or 9. New versions c…

Fair enough, I guess I haven't looked in the last few years. The last time that I did a search for .NET there were about five different names that were available and Mono still turned up as the runtime of choice for cross platform (even though I knew it wasn't any more).

To clear things up for you a bit more (hopefully, or I'll just make it worse):

Any legacy .NET projects are made with .NET Framework 4.x (4.8.1 8s the latest). So if it's 4.x, or called .NET Framework instead of just .NET, it's referring to the old one.

.NET Core is no longer used as a name, and hasn't been since .NET Core 3.1. They skipped .NET Core t completely (to avoid confusion with the old one vut I think they caused confusion with this decision instead) and dropped the Core for .NET 5. Some people will still call .NET 5+ .NET Core (including several of my coworkers) which I'm sure doesn't help matters.

Mono isn't 100% completely dead yet, but you'll have little if any reason to use it (directly). I think the Mono Common Language Runtime is still used behind the scenes by the newer .NET when publishing on platforms that don't allow JIT (like iOS). They've started adding AOT compilation options in the newest versions of .NET so I expect Mono will be dropped completely at some point. Unless you want to run C# on platforms like BSD or Solaris or other exotic options that Mono supports but the newer .NET doesn't.

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

#167

Post by afavour »

nchmy wrote: post #160
afavour wrote: post #94

Earlier quoted context omitted.

> 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 compro…

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.

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

#168

Post by silverwind »

coffeebeqn wrote: post #111
ChocolateGod wrote: post #25

Earlier quoted context omitted.

> But if you're on the backend, and don't need anything JS, why limit yourself to TypeScript Why not use it? What high level programming language would you suggest instead with the same level of performance and ecosystem support.

Go. If by same level of performance you mean much better performance. The language even comes with a http server built into it so you never have to deal with something like node

Performance maybe, but you will suffer go's rudimentary language features and it's very limited type system.

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

#169

Post by int_19h »

rtpg wrote: post #56
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…

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-in bundler? I'm not sure how it compares with esbuild tho.

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

#170

Post by int_19h »

lolinder wrote: post #154
HideousKojima wrote: post #131

Earlier quoted context omitted.

>but every time I've tried to figure out how to install it I get lost in the morass of nearly-identical names for totally different platforms and forget which one I'm supposed to be installing on Linux these days. I realize Microsoft is terrible at naming things, but for .NET/C# it's really not that hard these days. If you want to use the new, cross platform .NET on Linux then just install .NET 8 or 9. New versions c…

Fair enough, I guess I haven't looked in the last few years. The last time that I did a search for .NET there were about five different names that were available and Mono still turned up as the runtime of choice for cross platform (even though I knew it wasn't any more).

This is mostly the legacy stuff still ranking high up in search results.

These days you just add the Microsoft package repo for your distro and then do `apt install dotnet-sdk-9.0` or whatever.

It's also been spreading into the official distro repos. Nix, Arch, and Homebrew all have it.

Post reply on HN