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

101–110 of 210 posts

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

#101

Post by wink »

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…

yes of course, more people probably wanted node compat than people explicitly didn't want it (like the person who you replied to, and me too).

You have to decide where to go and apparently not being a niche product was one the reasons, that's fine - but now they have to live with at least 2+ unhappy (ex?) users.

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

#102

Post by ramesh31 »

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…

>And it’s boring.

This is a feature. Once upon a time, Node was the new hotness that all the cutting edge hackers were excited to play around with, and needed a hard sell to management. It has since graduated to IBM status - i.e. "no one ever got fired for...". And thank god for that. It's the most mature possible ecosystem choice at this point for the niche it fills, and we are able to build rock solid maintainable systems with it (and hire people who know it deeply). That didn't come cheaply or easily (IO.js drama anyone?), and anything that wants to take its place will need to make it through the same process.

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

#103

Post by wink »

skybrian wrote: post #98
lolinder wrote: post #80

Earlier quoted context omitted.

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

I'm not saying it's a realistic view, but I had hoped without any inclusions from NPM there would exist a couple more clean-room (or at least decoupled) implementations of things in TS, leaving everything JS behind.

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

#104

Post by skybrian »

afavour wrote: post #96
skybrian wrote: post #88

Earlier quoted context omitted.

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

I haven’t done all that much network programming in Deno, but I think it’s still fairly easy to get “promises all the way down” by sticking with Deno API’s? What’s your experience with this?

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

#105

Post by afavour »

skybrian wrote: post #104
afavour wrote: post #96

Earlier quoted context omitted.

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

I haven’t done all that much network programming in Deno, but I think it’s still fairly easy to get “promises all the way down” by sticking with Deno API’s? What’s your experience with this?

My complaint is not with Deno APIs. From what I’ve seen they’re great. My problem arrives the moment you install a dependency, because it isn’t using Deno APIs. And digging into exactly what any dependency is doing is often an odyssey through transpiled-to-ES3 JavaScript, outdated APIs and so on.

The original promise of Deno was a consistent ecosystem. Absent that it doesn’t matter to me all that much how great Deno is within itself, the case for using it simply isn’t compelling enough. These days the newer, standards-compliant Node APIs are pretty good too!

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

#106

Post by LoganDark »

diggan wrote: post #50
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 could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`) to validate on the server that payloads match the appropriate type. It was amazing and worked quite well, and I can't really see that being nearly as easy and seamless with anything else. But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript…

> But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript? Remove that compatibility, and you wouldn't get that benefit anymore, right?

JavaScript does make it easier to target both the web browser and Node.js, sure. But TypeScript also has a fairly mature type system and ecosystem (flaws in `tsc` itself notwithstanding). Not to say that no novel approaches are worth exploring, though; I just haven't seen one that rivals my TS experience yet.

> And if you still can get that benefit, why wouldn't you be able to get that benefit with other languages too?

That depends. In many other programming languages (such as ones that compile to WASM) it's also possible to have common code shared between server and client, but it's usually pretty inconvenient to actually get the code running in both environments. It's also possible to have a common interface definition and generate types for server and client from that definition, but that's still more complicated.

Anyway I don't fault anyone for being disappointed that Deno fell into the Node.js compatibility trap. Pure TypeScript without that particular cruft is also something I was excited about. I also was excited to see what looked like some fair innovation (like their import mechanism and their sandboxing) but I don't know how that'll continue if Node.js compatibility ends up being too much of a time sink.

I don't have very strong opinions because I've never really used Deno and I probably won't even bother at this point, but I definitely would not agree that this is just a problem of needing to use another programming language instead.

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

#107

Post by skybrian »

eqvinox wrote: post #73

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…

I’m guessing the use of Promises rather than Node-style network programming, which gets pretty hairy.

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

#108

Post by Lerc »

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…

>it’s mostly about the paid-for services Deno Inc offers.

In a way I think that's a good thing. Their plan for making money is to provide those services. That goal is enhanced by Deno being healthy. I would be more concerned if Deno was the product they were wanting to sell.

As long as Deno itself is FOSS, then I think I'm ok with it.

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

#109

Post by coffeebeqn »

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…

> amazing tooling

Oh I get it, you’re joking

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

#110

Post by o_m »

mosura wrote: post #26
wyuenho wrote: 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.

Most people and even most companies don't need horizontal scaling. Hardware has been much faster and cheaper since Heroku's heyday. Scaling vertically with 80+ cores on a single CPU and 256gb+ of ram only costs a few hundred dollars a month these days. With caching on a server like that, it can handle a million requests a second, or tens of thousands a second for dynamic data from the database on the same server.
Post reply on HN