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

91–100 of 210 posts

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

#91

Post by nicce »

skybrian wrote: post #71
nicce wrote: post #55

Earlier quoted context omitted.

It is less about purity and more about why continue improving Deno APIs since now we can handle the stuff with Node or Node-powered library? Especially, if you are driven by profits. That means that all possible hours will be removed from the future Deno API development. Also, it does not force older libraries to adapt and make versions that use Deno API.

What Deno API’s do you miss, compared to Node? It seems like they’re pretty built out? I’m looking forward to whatever they’re going to do instead of KV, which I tried and is too limited, even for a KV store. (64k values are too small.) Something like Cloudflare’s Durable Objects might be nice. You can’t “force” maintainers of old libraries to do anything. Deno never had that power. For people who are interested in s…

You should think Deno as standard library for JavaScript/TypeScript. Node was that. How well Node compares to Go/Python for example? We would like to see most used small Node libraries to merged at some level into Deno's standard library so that the amount of dependencies and deprecations would go downwards.

> You can’t “force” maintainers of old libraries to do anything. Deno never had that power. For people who are interested in supporting multiple alternate platforms, jsr.io seems pretty nice?

If enough people find Deno useful enough to skip some old libraries, maintainers are "forced", even thought Deno is not forcing anyone. If they do not adapt, then someone will just create a new library with better practices. In both cases there is pressure for better JS/TS evolution.

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

#92

Post by skybrian »

skydhash wrote: post #40
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…

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

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

#93

Post by lolinder »

stevage wrote: post #90
lolinder wrote: post #83

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

I'm not talking about JS. I had Rust in mind.

Also, promises already color functions just like callbacks do. Async/await just changes the syntax by which that coloring is expressed. The real problem people have with async is that they prefer green threads as a solution to concurrency, not that they don't like the syntax.

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

#94

Post by afavour »

nchmy wrote: post #15
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…

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 compromises the original technical promise of Deno. A rebooted, sensible JS ecosystem was the reason I was interested in Deno originally. I use Node every day and I’m mostly happy with it but whenever I need to dive into a dependency to see what’s going on it’s a five layer deep rats nest of transpiled and sometimes even minifed code using different module formats and platform specific APIs. I’d love to be done with all that.

Sometimes it pays to be bold when you’re challenging an entrenched incumbent. Any non-Node JS platform has to pitch "don't use the status quo, take a risk, use me" and absent the original benefit I don’t see a good argument to use Deno, especially when factoring in the risk of VC-driven priorities. I’m not saying everyone has to agree with me on that but it’s my personal perspective.

[1] https://deno.com/blog/v1

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

#95

Post by koakuma-chan »

floydnoel wrote: post #78
koakuma-chan wrote: post #58

Earlier quoted context omitted.

> What exactly is the problem you're encountering when trying to interact with HTTP APIs? The problem is that, unlike when using server actions, when using HTTP APIs, there is nothing that automatically generates bindings. > If you really want to use OpenAPI for whatever reason No, I don't. But people use OpenAPI to avoid having to handwrite an HTTP client. This is especially relevant if you are developing a public A…

"handwriting" an HTTP client is too much work for a developer? you need to import a library that does it for you? wow. abstraction at any cost, eh?

Yes, you have to waste time handwriting it and making sure that you actually wrote a proper binding. Then you also probably need to deal with API versioning. All of this goes away with server actions.

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

#96

Post by afavour »

skybrian wrote: post #88
the_gipsy wrote: post #74

Earlier quoted context omitted.

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.

Their original announcement post covers it pretty well:

https://deno.com/blog/v1

IMO their logic still holds up. Dahl had a whole talk about the mistakes made with Node:

https://www.youtube.com/watch?v=M3BM9TB-8yA

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

#97

Post by diggan »

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

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…

> 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 languages depending on what problem we're solving, as they all have different strengths and drawbacks. If you cannot see any drawbacks with TypeScript, it's probably not because there aren't any, but you're currently blind to them.

> Why would anyone want to use anything else for general purpose coding?

Because you've tasted the world of having a REPL connected to your editor where you can edit running code live and execute forms. Just one example. There are so many languages available out there when you control your stack. I understand using JavaScript for frontend web stuff, because you have no other options, and I personally have nothing against JavaScript itself. But for the love of god, realize there is a world out there outside of your bubble, and some of those languages have benefits too.

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

#98

Post by skybrian »

lolinder wrote: post #80
skybrian wrote: post #76

Earlier quoted context omitted.

Node compatibility isn’t a language feature, though, and it doesn’t result in “colored” functions. If a Deno library uses a Node API or an npm library somewhere, it can be entirely encapsulated, so you might not even notice until you see it in a stack trace. That doesn’t seem very intrusive? So it reminds me more of trying to avoid CGO in Go or avoid “unsafe” in Rust. It would be worse if Node-specific types started…

> If a Deno library uses a Node API or an npm library somewhere, it can be entirely encapsulated, so you might not even notice until you see it in a stack trace. That doesn’t seem very intrusive? Node API yes, NPM library no. If you add a dependency on a library that uses NPM you now depend on an entire web of transitive NPM dependencies, with all of the problems that entails. People don't dislike NPM because it's ae…

I think that’s best addressed by avoiding dependencies and looking for libraries with few indirect dependencies. There are lots of npms that advertise few or no dependencies as a feature.

Though, it is nicer if it’s on jsr.io because you’ll see Typescript source code in the debugger.

There’s nothing about starting over that prevents ending up with a whole new rat’s nest of dependencies, if you’re not careful.

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

#99

Post by k__ »

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 enter Go level of performance.

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

#100

Post by afavour »

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…

> Why do you treat adding a feature (npm compatibility) like you’re losing something?

Because you are losing something: a better ecosystem. Standardizing around… standards is a good thing. When I dive into the dependencies of any given Node app it’s a mess of transpiled code, sometimes minified even, there’s no guarantee what API it’ll be using and whether it’ll run outside Node (is it using the W3C streams API or the Node streams API?). But inertia is a powerful force. People will just use what’s there if they can. So the ecosystem never gets made.

> But it turns out that few people care that much about purity, so it’s fortunate that they’re not relying on that.

By that logic we never build anything newer or better. Python 3 is better than Python 2 and sets the language up for a better future. Transitioning between the two was absolutely torturous and if they just prioritised popularity it would never have happened.

Post reply on HN