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

51–60 of 210 posts

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

#51

Post by koakuma-chan »

homebrewer wrote: post #46
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.

Better/scalable performance, actual runtime type checking without wrapping everything with third-party libraries and paying the associated overhead, talent pool in my area, better (or even existing) libraries for the task at hand, better observability instrumentation, personal preference... is this really an honest question?

> is this really an honest question?

Yes, there is nothing that works better than server actions. None of what you listed really makes sense to me. I have never had any runtime performance problems with TypeScript and wasn't JavaScript the most popular programming language in the world (the talent pool argument)?.

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

#52

Post by lolinder »

xnorswap wrote: post #49
lolinder wrote: post #29

Earlier quoted context omitted.

Because out of all the languages that stand a chance of being adopted at most workplaces, TypeScript is in my opinion the single most enjoyable to code in. It has an extremely expressive type system that gets out of your way and allows you to model almost anything you can come up with, it has great IDE integrations on both VS Code and JetBrains, it has strong first-class support for functional programming patterns. O…

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 with it and I've often thought to give it another shot, but it's not a viable option right now for me because it's been too hard to get started.

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

#53

Post by CuriouslyC »

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.

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

#54

Post by skybrian »

diggan wrote: post #11

> There’s been some criticism lately about Deno - about Deploy, KV, Fresh, and our momentum in general. It seems like they never replied to the criticism against their momentum (something I haven't seen myself, what would the argument even be), was that intentional or just missed? > Some of that criticism is valid. Would have been great to also outline what criticism is/was valid, and how they're aiming to solve thos…

Here’s how they addressed momentum:

> Since the release of Deno 2 last October - barely over six months ago! - Deno adoption has more than doubled according to our monthly active user metrics.

The obvious question is: doubled, but compared to what? And what are they measuring? They’re not disclosing any real metrics on adoption.

I think what happened is that people were giving them the benefit of the doubt because they were new and you could imagine huge growth. The disappointment is by comparison to vague hopes and dreams.

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

#55

Post by nicce »

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…

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.

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

#56

Post by rtpg »

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…

by adding node compatibility it reduces pressure for libs to be written "the deno way". Libraries that could be cleaner!

At least that's the theory. To be honest I don't see Deno's value add. The runtime is like... I mean node works fine at this point? And the capabilities system is both too pedantic and too simplistic, so it's not actually useful.

I don't understand the value add of Bun much either. "Native" Typescript support but at the end of the day I need a bundler that does more than what these tools tend to offer.

Now if one of these basically had "esbuild but built in"....

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

#57

Post by rafram »

I’m not sure why anyone would want their JS runtime to be their package manager, code formatter, compiler, bundler, web framework, KV store, and cloud provider(!) all at the same time. There’s just no way that they can ship the best product in all of those categories.

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

#58

Post by koakuma-chan »

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

Earlier quoted context omitted.

> Not sure why you'd think that be a difficult thing? You aren't suggesting to handwrite an HTTP API client, right? You would have to set up either OpenAPI which is a mess, or GraphQL which is also a mess. LMK if you have a better solution.

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

> But it's not like using OpenAPI or GraphQL are the only two options

What are other options?

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

#59

Post by rtpg »

diggan wrote: post #24
Octoth0rpe wrote: post #16

Earlier quoted context omitted.

> why limit yourself to TypeScript which is a "Compile-to-JS" language? You control the stack, make another choice. Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. We want an ROI, we just don't want node/npm.

> Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. Right, makes sense. It also makes sense that most of those learnings are transferable, it's not like TypeScript is the only language with types. So your design/architecture skills can be used elsewhere too. Locking yourself into the ecosystem of one language, then asking other runtimes to adhere…

Typescript's type system is uniquely good for preventing types in "bog standard enterprise code". No other language comes close to it. Two words: untagged unions. And of course all the other utilities it provides.

It's extremely good! Shame about it being coupled to Javascript.

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

#60

Post by liveoneggs »

ChocolateGod wrote: post #25
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…

> 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)
Post reply on HN