In his 2018 talk, "10 Things I Regret About Node.js" https://www.youtube.com/watch?v=M3BM9TB-8yA&vl=en https://www.youtube.com/watch?v=M3BM9TB-8yA&vl=en he iden

In his 2018 talk, "10 Things I Regret About Node.js" https://www.youtube.com/watch?v=M3BM9TB-8yA&vl=en https://www.youtube.com/watch?v=M3BM9TB-8yA&vl=en he identifies seven (not ten) regrets. 1. Not sticking with Promises: This is changing, slowly. You can `import {readFile} from 'fs/promises'` in Node and it works as you'd expect, including top-level await. (Backwards compatibility means the callback API can never go away.) 2. Security (your linter shouldn't have complete access to your computer and network): Deno hasn't done a great job with this, either. You can restrict the access that a Deno process has, but you can't restrict the access for individual modules. If any module in your server needs to access something, then every module in your server can access it. I predict that module-level authorizations will be solved some day by browser vendors, and that Node and Deno will adopt the thing. Deno will probably have to throw out their thing what that happens. 3. Build system (GYP). This has no effect on userland Node developers. You build node with make. Another build system could be adopted, but I think nobody's bothered. Deno has a protobuf FFI to communicate with V8. You can do that with Node if you want. Shrug. 4. require("package") relies on package.json. Deno uses import maps. Node will probably honor import maps someday, too. 5. node_modules: He said it "complicates the module resolution algorithm." Meh. He also points out that node_modules is too large, but that's a Node cultural problem. Deno's community is still small, but it will have that problem, too, except it will have a large shared "cache" instead of a large local node_modules folder. 6. require("module") without the extension ".js": Deno does this, too, using import maps. It's fine. 7. index.js: Again, it "complicated the module loading system." Meh?