6 ms·

Can Node eventually fix the problems that coaxed Ryan Dahl to move on to Deno?

by pupppet 6y ago

pupppet 6y ago
I don't know why this is being downvoted. Ryan Dahl, the original developer of Node, moved on to build Deno.
- jtdev 6y ago
  It’s being downvoted because the Node community seems to have a hard time accepting constructive criticism... which is ironically also at the core of much of what’s wrong with Node in general.
  - jdlshore 6y ago
    Constructive criticism is specific and helpful. OP is just kvetching.
  - jorisd 6y ago
    Can you elaborate on this? I've always felt that the Node community, and the wider JavaScript community alongside it, has always been open to and embracing of constructive criticism, whether or not it's regarding the language itself (TC39, codemods / babel transformers, TypeScript, and any language that targets (Node)JS's ecosystem), established frameworks and libraries (underscore -> lodash, moment.js -> luxon), package management (pnpm, yarn), or even governance (the io.js fork, which was later on merged back into Node) and module systems (es modules, commonjs, et cetera). Ryan's original criticisms regarding Node were totally valid, but most of them weren't really easily addressable without significant breakage or a long migration strategy, which potentially could've caused a _lot_ of issues and unclarity for many years.
    - sieabahlpark 6y ago
      See the issues with azer and leftpad, Jamiebuilds and lerna, and every sjw fork of node because someone said something bad. If you notice none of the forks ever got traction and Jamie got punted for his trash handling of a major project.
- jkrems 6y ago
  Ryan definitely deserves credit for the initial development of node.js. But that phrasing makes it sound like he moved from node to deno - which isn't the case. He moved from node to other projects. Over the total lifetime of node, Ryan was _not_ involved for far longer than he _was_ involved (even when only counting the time before Deno was created). The top-level comment seems to suggest that Ryan was an integral part of node development before deno and that "getting him back" was relevant. Which isn't what happened. There are people who worked on node and moved to deno. But Ryan isn't really one of them.
dfabulich 6y ago
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?
- 52-6F-62 6y ago
  > You can `import {readFile} from 'fs/promises'` in Node and it works as you'd expect, including top-level await I can't believe I missed that. I've still been writing promise wrappers like a fool.
  - city41 6y ago
    util.promisify is also useful: https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_...
turdnagel 6y ago
I'm not sure why this was downvoted, but I think the answer is basically: yes, but only by making a lot of breaking changes. Which sort of leads you to Deno anyway. My take is that we probably won't see a wholesale change to the way things like file/network access works, package manager centralization, etc. anytime soon.

Can Node eventually fix the problems that coaxed Ryan Dahl to move on to Deno?

pupppet 6y ago

I don't know why this is being downvoted. Ryan Dahl, the original developer of Node, moved on to build Deno.

jtdev 6y ago
It’s being downvoted because the Node community seems to have a hard time accepting constructive criticism... which is ironically also at the core of much of what’s wrong with Node in general.
- jdlshore 6y ago
  Constructive criticism is specific and helpful. OP is just kvetching.
- jorisd 6y ago
  Can you elaborate on this? I've always felt that the Node community, and the wider JavaScript community alongside it, has always been open to and embracing of constructive criticism, whether or not it's regarding the language itself (TC39, codemods / babel transformers, TypeScript, and any language that targets (Node)JS's ecosystem), established frameworks and libraries (underscore -> lodash, moment.js -> luxon), package management (pnpm, yarn), or even governance (the io.js fork, which was later on merged back into Node) and module systems (es modules, commonjs, et cetera). Ryan's original criticisms regarding Node were totally valid, but most of them weren't really easily addressable without significant breakage or a long migration strategy, which potentially could've caused a _lot_ of issues and unclarity for many years.
  - sieabahlpark 6y ago
    See the issues with azer and leftpad, Jamiebuilds and lerna, and every sjw fork of node because someone said something bad. If you notice none of the forks ever got traction and Jamie got punted for his trash handling of a major project.
jkrems 6y ago
Ryan definitely deserves credit for the initial development of node.js. But that phrasing makes it sound like he moved from node to deno - which isn't the case. He moved from node to other projects. Over the total lifetime of node, Ryan was _not_ involved for far longer than he _was_ involved (even when only counting the time before Deno was created). The top-level comment seems to suggest that Ryan was an integral part of node development before deno and that "getting him back" was relevant. Which isn't what happened. There are people who worked on node and moved to deno. But Ryan isn't really one of them.

dfabulich 6y ago

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?

52-6F-62 6y ago
> You can `import {readFile} from 'fs/promises'` in Node and it works as you'd expect, including top-level await I can't believe I missed that. I've still been writing promise wrappers like a fool.
- city41 6y ago
  util.promisify is also useful: https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_util_promisify_original https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_...

turdnagel 6y ago

I'm not sure why this was downvoted, but I think the answer is basically: yes, but only by making a lot of breaking changes. Which sort of leads you to Deno anyway. My take is that we probably won't see a wholesale change to the way things like file/network access works, package manager centralization, etc. anytime soon.