Live data from Hacker News

Reports of Deno's Demise Have Been Greatly Exaggerated

deno.com

21–30 of 210 posts

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

#21
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.

Because there are other options available that might be better? Personally I'd chose Clojure for anything I have a choice with. Cargo culting a language like that does no one any favors.

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

#22
I get the "earnest, 'authentic', 'responsible' engagement by the CEO", but this post and title is lifted straight out of media-playbook-fails-101. Post a title like this at your peril. The content doesn't "own" the missteps, it writes the epitaph of Deno. All this article does is validate the "reports" of "demise" and unavoidably presents as "doth protest too much". If you insist on engaging with a negative narrative there are more constructive ways to frame it. Don't talk about "committing" to anything, just DO. Ryan, if you do nothing else, think about changing the title. But this entire post should ideally get rewritten. There are some really positive things you're doing. But they're covered in stink.

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

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

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

#24
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 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 to your preference sounds like a sure way of getting disappointed, instead of being pragmatic and flexible to chose the right tool for the problem.

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

#25
post #13

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…

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

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

#26
post #5

Most developers weren’t deploying simple stateless functions. They were building full-stack apps: apps that talk to a database, that almost always is located in a single region. I wonder if this is true in general for most people on serverless these days. If so, whether this is what the original intention of this movement and whether these people just don't want to deal with docker/k8s.

My gut feeling is that people want a modernized heroku. Managed RDBMS and an auto scaling set of servers that use it.

That covers a massive proportion of the companies that don’t need or want massive scale.

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

#27
post #21

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.

Because there are other options available that might be better? Personally I'd chose Clojure for anything I have a choice with. Cargo culting a language like that does no one any favors.

> Personally I'd chose Clojure for anything I have a choice with.

And then you would have to solve the problem of how to communicate with the client.

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

#28
post #21

Earlier quoted context omitted.

Because there are other options available that might be better? Personally I'd chose Clojure for anything I have a choice with. Cargo culting a language like that does no one any favors.

> Personally I'd chose Clojure for anything I have a choice with. And then you would have to solve the problem of how to communicate with the client.

I dunno, HTTP works pretty well for me as a transport layer to communicate with clients. Otherwise Websockets. Not sure why you'd think that be a difficult thing?

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

#29
post #13

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…

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

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. On top of all the things the language itself has going fit it, it allows me to write the same language on frontend and backend, which in my experience actually does make a huge difference in avoiding context switching and which also helps with avoiding code duplication.

People like to sneer at TypeScript, but let's be honest: people like to sneer at anything that's popular enough. The fact is that no language that I enjoy better than TypeScript (which is already not a very long list) stands any chance of adoption in an average workplace.

Post reply on HN