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

71–80 of 210 posts

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

#71

Post by skybrian »

nicce wrote: post #55
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…

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 supporting multiple alternate platforms, jsr.io seems pretty nice?

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

#72

Post by koakuma-chan »

williamdclt wrote: post #70
koakuma-chan wrote: post #20

Earlier quoted context omitted.

Why would you use something other than a JS framework to build a web app back-end? You don't have to deal with OpenAPI or GraphQL, you can just use server actions.

"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 than having to write an HTTP endpoint in a separate back-end project, and then regenerate your client via OpenAPI, or whatever else you use.

> IDK what you mean by "deal with OpenAPI"

I mean dealing with tooling to generate an HTTP client from OpenAPI schema.

> In all honesty (and sorry for the directness), you don't really seem to understand these concepts and how relevant or not they are to this conversation

Wrong

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

#73

Post by eqvinox »

This is really OT, but if I don't ask now I might never get an answer…

Someone mentioned to me "Deno-style event loops" / "Deno-style main loops". I asked what that is but they were gone. I've tried to look it up, to no avail.

I do quite a bit of work on low level event loops. I'm continually interested in how different projects are doing it and what ideas and tricks they come up with. It bugs me to no end that I can't find anything on what this "Deno style loop" is supposed to be.

Anyone know what's meant / have a pointer or two?

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

#74

Post by the_gipsy »

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…

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?

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

#76

Post by skybrian »

lolinder wrote: post #67
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…

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…

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 appearing as function parameters or return types, but that seems fairly rare even in npm libraries, so it seems easy to avoid.

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

#77

Post by incrudible »

lolinder wrote: post #67
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…

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 gonna argue that fragmentation is a problem in the node ecosystem (which I agree with), you can't convince me that a plethora of approaches to asynchronous code is preferable to async/await and promises.

1) The original essay that coined this term was looking at it from a language design perspective. The argument is a fair one if that design question is up for debate, but that isn't the case for Javascript.

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

#78

Post by floydnoel »

koakuma-chan wrote: post #58
diggan wrote: post #47

Earlier quoted context omitted.

What exactly is the problem you're encountering when trying to interact with HTTP APIs? If you really want to use OpenAPI for whatever reason, there are plenty of ways of doing that even in Clojure/Java, so I'm sure it's possible in other languages as well. But it's not like using OpenAPI or GraphQL are the only two options, if you're of that opinion I'm afraid you've drank way too much of the koolaid.

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

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

#79

Post by diggan »

koakuma-chan wrote: post #58
diggan wrote: post #47

Earlier quoted context omitted.

What exactly is the problem you're encountering when trying to interact with HTTP APIs? If you really want to use OpenAPI for whatever reason, there are plenty of ways of doing that even in Clojure/Java, so I'm sure it's possible in other languages as well. But it's not like using OpenAPI or GraphQL are the only two options, if you're of that opinion I'm afraid you've drank way too much of the koolaid.

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

> when using HTTP APIs, there is nothing that automatically generates bindings.

Is that really the biggest problem you face when programming? How many endpoints do you have? Even with projects with ~30 endpoints, it doesn't seem problematic to me, but maybe people regularly work on projects with 100s of endpoints, then it kind of makes sense. But I'm not sure that's typical enough.

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

People do a lot of stuff for a lot of nonsense reasons, doesn't mean that's the best way to approach things. The JS/TS ecosystem seems extra easy to fall into cargo culting too.

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

#80

Post by lolinder »

skybrian wrote: post #76
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…

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 aesthetically displeasing—you can't just abstract away the problems with NPM. The ecosystem causes real problems with real software, and Deno initially recognized those real problems and set out to reset the ecosystem.

The only way in which NPM-compat is different than colored functions is that there's no static compiler feature telling you when you've added a dependency on a bunch of NPM libraries.

Post reply on HN