Live data from Hacker News

Reports of Deno's Demise Have Been Greatly Exaggerated

deno.com

131–140 of 210 posts

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

#131

Earlier quoted context omitted.

Well there's C# / .NET, which ticks off all of those boxes, even the functional syntax is well supported since it added pattern matching and people write a lot of fluent functional style anyway with LINQ. It also interops nicely with F#, so you can write a pure functional library in F# and call it from a C# program in the "functional core, imperative shell" style. It has an incredibly solid runtime, and a good type s…

It misses the frontend/backend symmetry and has too large a coupling to Microsoft and Windows in my head. I know that these days it's supposed to be cross platform, 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. That doesn't mean there's anything wrong w…

>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 come out every year, with the version number increasing by one each year. Even numbered versions are LTS, odd numbered releases are only supported for about a year. This naming scheme for the cross-platform version of .NET has been used since .NET 5, almost 5 years ago, it's really not too complicated.

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

#132
post #118

Mark Twain was born in 1835, made the quote in 97 and died in 10. So the quote was done around 60 yrs old. And he perished roughly 1/4 of the of the time later. Demo was released in 2018, it has now quoted the statement, 7 yrs later. I guess the next 2 years are gonna be interesting?

Is this a pattern seen elsewhere?

Of projects and companies saying "we're not going to close down" and then - shortly after - shutting down?

It's not rare, so kinda.

The reason a project addresses these rumors at all means that they've noticed a trend and are worried about it.

Just like meta isn't publishing articles how react isn't going anywhere - they know it won't, despite the countless articles claiming otherwise.

What this kind of statement actually means it's basically "we're not secure, but we can't admit to it as that would cement it." Which funnily enough applied to Twain too, as he did indeed suffer from the illness people were gossiping about. It was just a lot less eminently dangerous then the rumors claimed

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

#133
post #94
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…

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

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

#134
post #108
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…

> it’s mostly about the paid-for services Deno Inc offers. In a way I think that's a good thing. Their plan for making money is to provide those services. That goal is enhanced by Deno being healthy. I would be more concerned if Deno was the product they were wanting to sell. As long as Deno itself is FOSS, then I think I'm ok with it.

Also, I've been using Deno Deploy for hobby projects and it is a delight to work with so far. In terms of finding a product that is a good complement to the open source Deno, they seem to have good ideas. Though I'm still in the VC-subsidized freeloader category in my hobby usage today, so I haven't experienced it yet as a paid product.

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

#135

Earlier quoted context omitted.

"server actions" seems to be a NextJS thing, not a JS thing? JS does not mean React and NextJS. The communication between frontend and backend is (almost) always HTTP, regardless of the languages and frameworks (server actions are http). Having a wrapper around HTTP isn't really a compelling reason to choose a technology for the very large majority of people: probably the opposite actually. IDK what you mean by "deal…

> server actions" seems to be a NextJS thing, not a JS thing? It's a JS framework thing. Every mainstream JS framework has server actions or equivalent. > Having a wrapper around HTTP isn't really a compelling reason to choose a technology for the very large majority of people: probably the opposite actually. It is way more convenient to write a server action and be able to immediately use it in a client component th…

Raising my hand with the opinion that you're wrong. Making it confusing as to whether code is executing on server or client is imho an antipattern.

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

#136

Earlier quoted context omitted.

> server actions" seems to be a NextJS thing, not a JS thing? It's a JS framework thing. Every mainstream JS framework has server actions or equivalent. > Having a wrapper around HTTP isn't really a compelling reason to choose a technology for the very large majority of people: probably the opposite actually. It is way more convenient to write a server action and be able to immediately use it in a client component th…

Raising my hand with the opinion that you're wrong. Making it confusing as to whether code is executing on server or client is imho an antipattern.

I’m wrong in what? Even if you’re confused whether server actions run on the server or on the client, it doesn’t take away benefits I listed before.

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

#137

Earlier quoted context omitted.

"server actions" seems to be a NextJS thing, not a JS thing? JS does not mean React and NextJS. The communication between frontend and backend is (almost) always HTTP, regardless of the languages and frameworks (server actions are http). Having a wrapper around HTTP isn't really a compelling reason to choose a technology for the very large majority of people: probably the opposite actually. IDK what you mean by "deal…

> server actions" seems to be a NextJS thing, not a JS thing? It's a JS framework thing. Every mainstream JS framework has server actions or equivalent. > Having a wrapper around HTTP isn't really a compelling reason to choose a technology for the very large majority of people: probably the opposite actually. It is way more convenient to write a server action and be able to immediately use it in a client component th…

> Every mainstream JS framework has server actions or equivalent

No. "Server actions" are a React concept, it has little to do with backend technology (the backend still speaks HTTP). This concept is completely irrelevant to most big frameworks like Express, NestJS, Koa, Hapi. Next is barely a "backend" framework: it's rather a React server framework that has a few basic backend functionalities.

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

#138

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…

> My favorite testing framework, AVA, still isn’t supported.

Have you checked recently? The docs (https://docs.deno.com/runtime/fundamentals/testing/) specifically mention AVA as being supported. Then again, I'd assume that most devs using Deno just use the built-in `deno test` instead of a third-party testing framework.

> The one area of Node compatibility that I want the most is support for ESLint configs in the Deno linter.

Again, have you checked recently? According to the docs this is supported: "Deno's built-in linter, `deno lint`, supports recommended set of rules from ESLint to provide comprehensive feedback on your code. (...) You can specify custom rules, plugins, and settings to tailor the linting process to your needs." (https://docs.deno.com/runtime/fundamentals/linting_and_forma...)

I've been using Deno for 6 years now. And I'm actually quite happy that most Deno projects don't have a custom testing and linting setup.

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

#139

Earlier quoted context omitted.

> server actions" seems to be a NextJS thing, not a JS thing? It's a JS framework thing. Every mainstream JS framework has server actions or equivalent. > Having a wrapper around HTTP isn't really a compelling reason to choose a technology for the very large majority of people: probably the opposite actually. It is way more convenient to write a server action and be able to immediately use it in a client component th…

> Every mainstream JS framework has server actions or equivalent No. "Server actions" are a React concept, it has little to do with backend technology (the backend still speaks HTTP). This concept is completely irrelevant to most big frameworks like Express, NestJS, Koa, Hapi. Next is barely a "backend" framework: it's rather a React server framework that has a few basic backend functionalities.

Okay, every full-stack JS framework.

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

#140
post #97

Earlier quoted context omitted.

> anyone why JavaScript and typescript are the Lingua Franca of software engineering. I mean, it obviously isn't, although for web development, I'd probably agree with you. But regardless, zealots who hold opinions like this, where there is "one language to rule them all" is why discussing with TS peeps is so annoying. In your world, there is either C or TypeScript, but for the rest of us, we tend to use different la…

Do you know what lingua franca means? https://survey.stackoverflow.co/2024/technology#most-popular... ... JS is the most popular language in the world, per Stack Overflow.

Do you know what it means? A lingua franca is able to facilitate communication between many parties who do not have a common mother language. JavaScript most certainly does not fit that bill. You could argue C is the lingua franca from the side of the CPU since C runs everywhere, it is literally meant for that. A portable assembly.
Post reply on HN