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

81–90 of 210 posts

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

#81

Post by sholladay »

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

Today, Deno feels more complex than Node does because it contains both approaches. And now there are lots of edge cases where a Node package ought to work, but doesn’t because of one unimplemented API or option or a bug that exists only in Deno. My favorite testing framework, AVA, still isn’t supported.

I used to just ignore the npm compatibility layer and target Deno itself, but that’s become more cumbersome to do over time. For example, look at `deno run —help` and look at how many command line options and env vars there are. It’s exploded in the past few years. A lot of that is for npm interoperability. For me, it’s just a lot of noise.

The one area of Node compatibility that I want the most is support for ESLint configs in the Deno linter. Yet they don’t seem to want to do that.

I really want Deno to succeed, if for no other reason than because it’s pushing Node to do things that they should’ve done years ago, such as adding a permission system. I just don’t think the current vision for Deno is very coherent or consistent with its original purpose.

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

#82

Post by dkarl »

lolinder wrote: post #32
afavour wrote: post #7

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…

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

> Deno set out to change that and be something new, but they squandered that chance because it was too risky for their investors

Maybe it was too risky for users? The people with the most appetite for a new start and a new way of doing things are people who are suffering from their existing investment in Node. Making a halfway jump to a new platform with no path to completing the migration would leave their customers running on two platforms indefinitely. It's the worst-case outcome for a migration, going halfway and getting stuck with your feet in two canoes.

By supporting Node, Deno lets customers switch to something new and better and bring their legacy baggage along as well.

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

#83

Post by lolinder »

incrudible wrote: post #77
lolinder wrote: post #67

Earlier quoted context omitted.

An equivalent argument to yours could be made to defend the introduction of async/await to a language that has previously not had it (edit: like Rust): if you don't like async/await, just don't use it! What does it hurt you to have another feature added? The answer is obvious in the programming language case: for those who do not want async, the addition of async/await begins to poison the ecosystem. Now they have a…

There is no such thing as a "colorless" alternative to colored functions[1] in Javascript, at least as far as browser-compatibility is concerned. Promises are a convention for what used to be all the colors in the rainbow (and then some imaginary ones). Async/await is syntactic sugar on top that makes it more readable. The inherent pitfalls of asynchronous code don't disappear if you remove that sugar. If you're gonn…

To be clear, I like async. I just don't think "you don't have to use it if you don't like it" is a good argument in favor of it because it's obviously not true.

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

#84

Post by mattlondon »

diggan wrote: post #13
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…

> Does anyone know of a server-side typescript scripting engine that is not trying to be backwards compatible with node? What's the point? If you're in love with static types, but have to do JavaScript because you're targeting the browser, I kind of understand why'd you go for TypeScript. But if you're on the backend, and don't need anything JS, why limit yourself to TypeScript which is a "Compile-to-JS" language? Yo…

Yep I control the stack, and I want it to be typescript.

At this stage, I don't think anyone needs to try and persuade anyone why JavaScript and typescript are the Lingua Franca of software engineering.

Performant, expressive, amazing tooling (not including node/npm), natively cross-platform.

An absolute joy to code with. Why would anyone want to use anything else for general purpose coding?

In my mind there are two alternative approaches in the current ecosystem: C++ where absolute 100% maximal performance is the overriding primary objective and be damned with the consequences, then for everything else just use Typescript

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

#86

Post by fallinditch »

dbushell wrote: post #10

Doesn't inspire confidence. I guess we’ll see soon enough what Deploy will become since that's "imminent". KV is dead if they've no desire to develop it out of beta and are working on something new. No reason to ever use it for a new project now. Fresh is being refactored with an alpha in "late Q3 2025 (likely September)". It was a fairly basic framework to being with. The no compilation/build step was the only inter…

> KV is dead if they've no desire to develop it out of beta and are working on something new. No reason to ever use it for a new project now.

I think you're right, I was just about to use it for something but now I'm considering other options...

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

#87

Post by lolinder »

dkarl wrote: post #82
lolinder wrote: post #32

Earlier quoted context omitted.

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

> Deno set out to change that and be something new, but they squandered that chance because it was too risky for their investors Maybe it was too risky for users? The people with the most appetite for a new start and a new way of doing things are people who are suffering from their existing investment in Node. Making a halfway jump to a new platform with no path to completing the migration would leave their customers…

It was always going to be too risky for a subset of users, from the moment they announced it. That would not have stopped a project that was not VC funded—a smaller project with less at stake could easily have stuck to their guns and just appealed to the people who were actually interested in pioneering a new ecosystem.

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

#88

Post by skybrian »

the_gipsy wrote: post #74
lolinder wrote: post #32

Earlier quoted context omitted.

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

They basically said they were taking a risk (node/npm incompatible) for a big long-term benefit. They gave up on that forever, for some short-term growth. How many more times would they back-pedal on any risk they announced taking?

They did say something like that, but I don’t remember what the big long-term benefit was supposed to be. What specifically did they give up? Maybe it wasn’t that important after all.

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

#89

Post by incrudible »

lolinder wrote: post #83
incrudible wrote: post #77

Earlier quoted context omitted.

There is no such thing as a "colorless" alternative to colored functions[1] in Javascript, at least as far as browser-compatibility is concerned. Promises are a convention for what used to be all the colors in the rainbow (and then some imaginary ones). Async/await is syntactic sugar on top that makes it more readable. The inherent pitfalls of asynchronous code don't disappear if you remove that sugar. If you're gonn…

To be clear, I like async. I just don't think "you don't have to use it if you don't like it" is a good argument in favor of it because it's obviously not true.

...but you don't have to use it. You can keep using raw promises and you can trivially use any async/promise-based API with informal callbacks. I doubt many people want to do that, but they can.

Of course, in (browser-compatible) Javascript, some things can not be done synchronously, but that's not up for debate.

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

#90

Post by stevage »

lolinder wrote: post #83
incrudible wrote: post #77

Earlier quoted context omitted.

There is no such thing as a "colorless" alternative to colored functions[1] in Javascript, at least as far as browser-compatibility is concerned. Promises are a convention for what used to be all the colors in the rainbow (and then some imaginary ones). Async/await is syntactic sugar on top that makes it more readable. The inherent pitfalls of asynchronous code don't disappear if you remove that sugar. If you're gonn…

To be clear, I like async. I just don't think "you don't have to use it if you don't like it" is a good argument in favor of it because it's obviously not true.

Not the person you're replying to, but I don't get how your argument applies here. JS functions could already return promises. Some of them being declared as async doesn't change anything for the consumer does it?

(In general, I do agree that "you don't have to use it" is not a strong argument.)

Post reply on HN