Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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?


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!


Surely you can choose to only install "Deno native" dependencies?

It may sometimes be difficult to find such an option, but that was always going to be the case without Node compatibility.

Now, in theory at least, you have the option of sticking with Deno native dependencies, and an escape hatch when none are available.

That seems like the most pragmatic solution to the ideology vs adoption dilemma.


They gave up on a quality Deno ecosystem. And being relevant.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: