Overview of the talk from a comment[0] of that video:
> The goal of Node was event driven HTTP servers.
>
> 5:04
> 1 Regret: Not sticking with Promises.
> * I added promises to Node in June 2009 but foolishly removed them in February 2010.
> * Promises are the necessary abstraction for async/await.
> * It's possible unified usage of promises in Node would have sped the delivery of the eventual standartization and async/await.
> * Today Node's many async APIs are aging baldly due to this.
>
> 6:02
> 2 Regret: Security
> * V8 by itself is a very good security sandbox
> * Had I put more thought into how that could be maintained for certain applications, Node colud have had some nice security guarantees not available in any other language.
> * Example: Your linter shouldn't get complete access to your computer and network.
>
> 7:01
> 3 Regret: The Build System (GYP)
> * Build systems are very difficult and very important.
> * V8 (via Chrome) started using GYP and I switched Node over in tow.
> * Later Chrome dropped GYP for GN. Leaving Node the sole GYP user.
> * GYP is not an ugly internal interface either - it is exposed to anyone who's trying to bind to V8.
> * It's an awful experience for users. It's this non-JSON, Python adaptation of JSON.
> * The continued usage of GYP is the probably largest failure of Node core.
> * Instead of guiding users to write C++ bindings to V8, I should have provided a core foreign function interface (FFI)
> * Many people, early on, suggested moving to an FFI (namely Cantrill) and regrettably I ignored them.
> * (And I am extremely displeased that libuv adopted autotools.)
>
> 9:52
> 4 Regret: package.json
> * Isaac, in NPM, invented package.json (for the most part)
> * But I sanctioned it by allowing Nod's require() to inspect package.json files for "main"
> * Ultimately I included NPM in the Node distribution, which much made it the defacto standard.
> * It's unfortunate that there is centralized (privately controlled even) repository for modules.
> * Allowing package.json gave rise to the concept of a "module" as a directory of files.
> * This is no a strictly necessary abstraction - and one that doesn't exist on the web.
> * package.json now includes all sorts of unnecessary information. License? Repository? Description? It's boilerplate noise.
> * If only relative files and URLs were used when importing, the path defines the version. There is no need to list dependencies.
>
> 12:35
> 5 Regret: node_modules
> * It massively complicates the module resolution algorithm.
> * vendored-by-default has good intentions, but in practice just using $NODE_PATH wouldn't have precluded that.
> * Deviates greatly from browser semantics
> * It's my fault and I'm very sorry.
> * Unfortunately it's impossible to undo now.
>
> 14:00
> 6 Regret: require("module") without the extension ".js"
> * Needlessly less explicit.
> * Not how browser javascript works. You cannot omit the ".js" in a script tag src attribute.
> * The module loader has to query the file system at multiple locations trying to guess what the user intended.
>
> 14:40
> 7 Regret: index.js
> * I thought it was cute, because there was index.html
> * It needlessly complicated the module loading system.
> * It became especially unnecessary after require supported package.json
>> * Many people, early on, suggested moving to an FFI (namely Cantrill) and regrettably I ignored them.
A bit off-topic but Dahl referenced Cantrill here, who I figured to mean one of the authors of DTrace, Bryan Cantrill, who I then found from his Twitter (https://twitter.com/bcantrill) just last month started a new "computer company" which sounds super interesting, especially with his past experience and the passion he seems to have for attempting to solve a tough, bold problem:
For more context, Cantrill was senior at Joyent, who has Nodejs listed as one of their products on Wikipedia and has been the corporate sponsor of Nodejs for a long time.
Thanks. This largely made me realize most decisions behind node.js were made on-the-fly rather arbitrarily without putting too much thought into it, and help me compare and contrast it with Go. :)
> most decisions behind node.js were made on-the-fly rather arbitrarily without putting too much thought into it
that seemed rather apparent even at the time - what's been more interesting is watching others defend some of these decisions as if there was a lot of thought put in to them, and that they're some example of great architecture.
not specifically ragging on nodejs - I see this a lot in various projects - small/minor decisions compound over time, and even if they were not originally planned/intended to have significance, they have it at some point, and often people who weren't involved in the original decisions think there's a lot more 'there' there behind the original decisions, when, usually, there isn't.
