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

61–70 of 210 posts

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

#61

Post by msie »

koakuma-chan wrote: post #20
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…

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.

Wow…

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

#62

Post by bredren »

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…

Yes. And m this is also why Poetry remains good enough in the face of PDM.

That said, next.js achieved widespread adoption and displaced create react app. And however you feel about the framework, react itself, are possibly reasons to believe.

What others are out there?

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

#63

Post by liveoneggs »

koakuma-chan wrote: post #20
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…

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.

nextjs or bust? This is a wild take

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

#64

Post by jppope »

Personally I love what Ryan and the Deno team have done, if there is anything to really say its that incumbency in languages and software ecosystems is really strong- and its stronger the further down the stack you get.

I will say that I was disappointed when they added NPM into the project, I understand why they did it but I would have preferred they not do it.

With that said all of my blogs and client sites are all being happily built in lume with deno right now (hosted on cloudflare) and they have been great for years now. I am still very happy for having made that change.

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

#65

Post by koakuma-chan »

liveoneggs wrote: post #63
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.

nextjs or bust? This is a wild take

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

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

#66

Post by bredren »

yahoozoo wrote: post #23

The problem with Deno is that it has lost the plot. When it was first announced years ago, it was simply a safer, faster JS/TS runtime “written in Rust” which I assume it still is but now you go to the website and you click a “Products” drop down containing a bunch of other shit. It’s like they looked at what Vercel did with introducing a deployment platform after their initial NextJS work and wanted to follow suit.

Was it this or did the JavaScript / node communities get their acts together?

I had thought a lot of what Deno was setting out to do was cool beans for a time but parity was faster to come from js/node than expected.

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

#67

Post by lolinder »

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…

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 growing list of libraries that they cannot use if they want to avoid async, so the effort involved in picking a library goes up and the odds get increasingly high that they're locked out of some of the key tools in the ecosystem because new libraries without async become harder and harder to find.

For those who really hate colored functions, the addition of async is the removal of a feature: colorless functions are replaced with colored functions.

The same can be said of NPM compatibility. Sure, I can try to avoid it and stick to Deno imports and inspect each library that I use for NPM dependencies. But it gets harder and harder as time goes on, because a key feature of Deno has been removed: it's no longer an ecosystem reset.

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

#68

Post by LoganDark »

skydhash wrote: post #48
LoganDark wrote: post #39

Earlier quoted context omitted.

I haven't seen any true competition with TypeScript, at least for me. Go is unsound (Go slices...), Python is too high-level (even with mypyc), Rust is too low-level (in comparison to TS), and so on. It's not just "a language with types". Also, when I was writing a frontend and backend both in TS, I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`…

I don’t understand the need to share types between frontend and backend. It’s like a strong incentive to take the wrong decisions down the lines instead of using the right data model for the domain.

I mean JSON payload types.

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

#69

Post by bredren »

CuriouslyC wrote: post #53
eknkc wrote: post #3

Whenever I read a blog post assuring me that something is not how it looks, it turns out to be exactly how it looks at the end. BTW, I don't use deno and haven't been following any news whatsoever so this is simply a shitty statement from an outsider. It is interesting that I tested deno a couple of times but kept using node until bun came around and I basically switched to bun. I can't say why exactly.

Bun has high node compatibility with lightning fast testing and a good/fast built in package manger. I'd use bun for local dev even I was deploying with node.

Why not esbuild? It was ~fast enough first and free of capital entanglements.

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

#70

Post by williamdclt »

koakuma-chan wrote: post #20
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…

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 with OpenAPI", OpenAPI is a spec not a technology like graphql.

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

Post reply on HN