Live data from Hacker News

Reports of Deno's Demise Have Been Greatly Exaggerated

deno.com

111–120 of 210 posts

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

#111
post #13

Earlier quoted context omitted.

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

> 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

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

#112

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.

Java has (much) better performance and a bigger ecosystem. It has types and multiple alternative languages which target it (kotlin, scala, clojure, etc)

Hell, last I checked PHP is still king of the server-side Web scripting languages, as far as real-world speed. Like, fast enough that you've gotta be pretty careful in Java or Go or whatever, or you'll end up slower than PHP.

The way you make a scripting language fast is by getting the hell out of it and into C or C++ as fast as possible, and PHP's library ecosystem embraces that harder than just about any other scripting language, is the reason (I think).

[EDIT] My point is mainly that Node's performance isn't really that impressive, in the field of "languages one might use to write server-side Web code". It beats absolute slugs like Python and Ruby handily, but past that... eh. And really, in its speed category you'd probably do just as well using either of those and paying a little more attention to things like network calls and database access patterns.

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

#113
post #90

Earlier quoted context omitted.

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

Using the function color concept was an example of a place where this problem can occur, not the actual problem.

The problem is that if you think statically, you can say "oh, just use the 'clean' subset". But the world is not static. If you think dynamically, you can see the full Node ecosystem as a fairly powerful attractor; why would I write a deno library that only works on deno when I can write a node library that works on both? Well, if I'm writing in the Node ecosystem, why not use the whole thing?

This is a general effect; it is very hard for people to set up long-term ecosystems that are "too close" to existing ecosystems. Generally the new thing will either get pulled in (as in this case) or ignored (as in the many cases of 'hey Typescript seems to have worked pretty well, let me do a Typescript-like gloss of this other language', which generally just get ignored). There are successes, like Typescript (JS is in general a special case because being the only language in the browser for so long it was both a language and a compile target; most other attempts to "Typescriptify" a language flounder on the fact that few if any other languages have that situation), Elixir (managed to avoid just being absorbed by Erlang, IMHO kind of a similar situation where the 'base langauge' for the ecosystem was not really the best), and the occasional Lisp variant that bubbles up (though like Clojure, usually with a story about where it can be run), but in general this is very hard to pull off, harder in some ways than simply starting a brand new language ecosystem, which is itself no picnic.

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

#114

Earlier quoted context omitted.

Yeah. JavaScript is fine if you’re dealing with the DOM and vendor libraries, or if you’re using it in some scripting environment like GNOME. Node were ok too, but failed to develop a standard library like Go or Python. Addressing that failure would go a long way towards a better JS ecosystem.

Deno’s standard libraries [1] seem pretty nice, but to be honest I never used them much, because lots of stuff on MDN works fine in Deno. [1] https://jsr.io/@std

I stumbled upon Deno when I needed to spin up a simple API to add to/update a CSV file, and really the only thing I found was deno-csv library, and it worked great. I was pleased with how easy it was with Deno, had it going in under an hour.

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

#115
Deno ought to become an engine for the innovative development of web browsers. That is what we need, and what it could very well offer. Better permissions, protocol choices, simpler extensions, all around more options and control.

Business wise turn their deploy system into a resource for the browser base, for instance app store, for instance flash compute/rendering, for instance agent hosting services.

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

#116

Earlier quoted context omitted.

nextjs or bust? This is a wild take

Yep, Next.js has the best support for vibe coding.

> vibe coding

"Vibe coding" as a concept is a fun joke, not a workflow you employ for doing serious engineering. It was a tiny experiment that somehow people thought was a suggested way of developing software, which obviously it isn't. Read the code yourself, otherwise it'll be really hard to call yourself any sort of engineer.

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

#117
post #116

Earlier quoted context omitted.

Yep, Next.js has the best support for vibe coding.

> vibe coding "Vibe coding" as a concept is a fun joke, not a workflow you employ for doing serious engineering. It was a tiny experiment that somehow people thought was a suggested way of developing software, which obviously it isn't. Read the code yourself, otherwise it'll be really hard to call yourself any sort of engineer.

> "Vibe coding" as a concept is a fun joke, not a workflow you employ for doing serious engineering.

Well I guess making Next.js apps isn't really "serious engineering"

> Read the code yourself, otherwise it'll be really hard to call yourself any sort of engineer.

I do read the code but I barely write any code by hand.

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

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

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

#119
post #116

Earlier quoted context omitted.

> vibe coding "Vibe coding" as a concept is a fun joke, not a workflow you employ for doing serious engineering. It was a tiny experiment that somehow people thought was a suggested way of developing software, which obviously it isn't. Read the code yourself, otherwise it'll be really hard to call yourself any sort of engineer.

> "Vibe coding" as a concept is a fun joke, not a workflow you employ for doing serious engineering. Well I guess making Next.js apps isn't really "serious engineering" > Read the code yourself, otherwise it'll be really hard to call yourself any sort of engineer. I do read the code but I barely write any code by hand.

> Well I guess making Next.js apps isn't really "serious engineering"

Where did I say that?

> I do read the code but I barely write any code by hand.

Right, so you use the words "vibe coding" yet you don't actually understand the concept? A lot of things make sense now. The description "vibe coding" is explicitly about "programming" with a LLM without reading or writing any code at all, for any purpose. If you read the code, you're not really vibe coding as originally described by Karpathy.

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

#120
post #15
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…

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.

Post reply on HN