6 HN users recommended this talk4 months2018–2025score 4.5
Years with an HN recommendation, 2007–2026
HN treats it as the classic talk on why Deno exists and on lessons from design mistakes in a widely used platform.
Node.js creator Ryan Dahl discusses ten design mistakes he made in Node, including package.json, npm, and module resolution. The talk sets out the motivations behind his later project, Deno.
“Ryan Dahl's great talk on design mistakes he made with node.js is something I think about all the time” (HN, 2023)
Ryan Dahl's great talk on design mistakes he made with node.js is something I think about all the time: [this video] Even though he considers things like `require('./something')` defaulting to either `./something.js` or `./something/index.js` a mistake, he also admits these are not possible to change at this point. I think Python made a mistake trying to correct design problems in 2. The cost of change simply wasn't worth the price of migration. Is `print("text")` really that much of an improvement over `print "text"`?
Deno [1] is a new JS runtime by one of the creators of NodeJS, Ryan Dahl. He had a great talk [2] about the lessons he learned when creating/maintaining NodeJS. Many of these lessons are being applied to Deno. [1] [link] [2] [this video]
Lessons from creating Node that are applied in Deno.
I just hope in 5 years we're not seeing a talk saying that in retrospective, dropping static types was a huge error... and DoNe is a new project to fix issues like that! (I'm just referring to this nice talk about the regretful mistakes done in Node: [this video] )
Well, in all the initial presentations Ryan Dahl gave about Deno, he phrased it as solving the things he'd come to realise he hated about Node. So that's what I take as the raison d'être of Deno - taking the lessons he'd learned from some years mainly coding Go and thinking about what he'd learnt from Node, and fixing what he could. Here's the classic video on the topic: [this video]
Deno is a JavaScript runtime much like Node. For the reasons on why creating Deno I recommend "10 Things I Regret About Node" by Deno's author [1] Deno is different than Node in several aspects; most notably: - Deno supports only ES modules, there's no built-in support for CommonJS modules - Deno's APIs are all promised based - Deno does not use NPM, instead it can pull code from any URL, much like browsers do - Deno has built-in permission system that by default runs your code in full sandbox allowing to opt-in into breaking out of sandbox (eg. to read a file from disk) - As you've mention Deno can run .ts files without explicit build step - Deno comes with a full toolchain in a single binary (formatter, linter, test runner, bundler, doc generator) [1] [this video]
In a recent video, Ryan Dahl mentioned that he regrets incorporating package.json and NPM into Node: [this video] He has a very early attempt at breaking from compatibility with Node called "Deno". Here's the part in the video about his current thoughts on importing external modules under Deno: [this video] He has some other security proposals as well.
Meanwhile, Deno (alternative server-side JS built from scratch by the creator of Node) keeps chugging along: [link] It will be interesting to see which happens first: developers migrate to Deno or Node finalizes its ES module implementation. I think both groups are doing excellent work, but the Node team seems to be at a disadvantage having to continue support for some decisions made early on in Node: [this video]
Cited for early Node decisions that now burden it.
> ..The node_modules package resolution algorithm is how JS does namespaces.. I wonder whether they got that right through sheer genius, or by accident. I recall hearing Ryan Dahl's regrets about design decisions in Node.js, a few of which had to do with the module/package resolution algorithm. 10 Things I Regret about Node.js - [this video] There are some good aspects of it though. I like how modules/packages are just imported objects (the path resolution is a bit weird and seemingly inefficient, i.e., checking every parent folder's node_modules folder). It goes together well, that modules are also self-contained function scopes by default (I suppose a kind of anonymous namespace), that exports a plain object with assigned properties. --- Wow, I just learned about C++20 Modules, looks like a game-changing feature. [link]
Powershell has a security model. Also, Ryan Dahl (creator of node.js) is working on Deno as a replacement because he thinks he made a mistake with node. 10 Things I Regret About Node.js - Ryan Dahl [this video]
Ryan Dahl (author of the announcement post) is the creator of Node.js, so I think he's got a right to say these things! Also see "10 things I regret about Node" [0] [0] [this video]
If you want a couple other examples here's what I've got offhand.. Perhaps the original example, Hoare helped popularize null pointers, and then gave the "Null Pointers: The Billion Dollar Mistake" talk [link] The creator of nodejs talking about some of its mistakes: [this video] Nada Amin was part of the Scala team, and also wrote a wonderful paper about how Scala's type-system is fundamentally unsound: [link] bradfitz was a core go team member, and wrote a post about what their net.IP type got wrong [link] I have no doubt there's many more examples too, but those are the ones I can think of offhand.
Example of a creator discussing mistakes in their design.
This explanation resonates with me. I first saw Ryan Dahl's talk about his Node.js regrets[0] during the early days of the pandemic. I thought I'd be eager to try Deno when it became more mature, but I still haven't tried it. I guess I'm not convinced that it's 10x better than Node.js. [0] [this video]
Talk about Node regrets that motivated interest in Deno.
> …I already have taken care of a lot of those Node issues in my own projects, there is not a ton that I see compelling in Deno. I felt this way too before using Deno for a while. So far I enjoy: - Breaking from npm/node modules support on purpose turns out to be a real plus for me. It's refreshing to have dependencies referenced by URL, and it's good to have them cached centrally by default (in $HOME/Library/Caches/deno on macOS and $XDG_CACHE_HOME/deno or $HOME/.cache/deno on Linux, for example). - Use of web platform APIs ( [link] ) and the work to standardise those across platforms ( [link] ) is encouraging. - `deno lint` and `deno fmt` make adopting and using JS/TS feel more like Rust/Go/other languages with good built-in ceremony-free tooling. - Fresh is turning into a very nice Next.js/Astro alternative ( [link] ) that I found very easy to learn and deploy, with great performance and developer experience out of the box. Bun is interesting, but I wish it didn't embrace node modules: perpetuating its use instead of attempting to move the community on by recognising it for the mistake it was feels sad to me. (See Ryan Dahl's “Design Mistakes in Node” PDF or talk for more: [link] and [this video] )
Cited for Dahl's views that node modules were a mistake.
Are we talking about the same talk? 10 Things I Regret about Node.js [0]? Goal #2 (after security) was to simplify the module system, and the very first thing he said about that was no node compatibility. [0] [this video]
Cites the talk's goals to rebut a claim about Node compatibility.
I believe the Deno permission system[0] does what you're asking, and more. (Deno is a JavaScript runtime co-created by Ryan Dahl, who created Node.js - see his talk "10 Things I Regret About Node.js"[1] for more of his motivations in designing it.) [0] [link] [1] [this video]
Their original announcement post covers it pretty well: [link] IMO their logic still holds up. Dahl had a whole talk about the mistakes made with Node: [this video]
> Just because they are attempting to address it does not mean they will succeed. Strongly agree this statement , hence I don't see how switching from "npm" to "raw urls" will solve anything... The problem with Node dependency is bigger than just "npm is not a good package manager"... Honestly in this case just fork node and replace npm with something else... Here the problem relies on a mixture between poor built-in apis which are buggy a lack of vision with the language , which have been core to the language since it's origin.;. Deno doesn't seems to address those at all... Again it's just seems to be "npm is bad , and i want to use typescript natively with web apis"... I just know very well that Ryan is redoing exactly the same mistakes as Node with the same obsession he had on "EPOLL"[0] back then that will end up in a new fiasco. [0] [this video] Can't find the specific part where he mentioned "EPOLL"
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
20 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Read more
Citations, criticism and jokes
Read more
Read more
Read more
Read more