3 ms·

Yeah, no kidding.. shots fired... As someone who uses Node but doesn't closely follow the steering/proposals side of things, I can't say I had this impression

by sbarre 6y ago

Yeah, no kidding.. shots fired... As someone who uses Node but doesn't closely follow the steering/proposals side of things, I can't say I had this impression of that process.. Is Node really that bad compared to how JS/ES is innovated on in the browser?

beaconstudios 6y ago
Node is only just now getting around to adding promise based APIs to the core. Any time you interact with the Node core APIs you have to drop back to using callbacks - that's at least one area where Node is behind the times.
- pharmakom 6y ago
  Or use the ubiquitous NPM to install a promise orientated package... I don’t see this as a big problem honestly.
  - beaconstudios 6y ago
    I'm not sure what you think could qualify Node as not keeping with the times, if not implementing the modern standard for async interfaces isn't it.
    - ianwalter 6y ago
      I agree with you that it would be nice if more of core supported promises, but I think there are probably plenty of examples of them keeping up with the times or charging ahead as well. Top-level await and optional chaining are a couple features that come to mind.
      - beaconstudios 6y ago
        true, the language-evaluation side is keeping up. But isn't that just a case of integrating newer versions of v8? NodeJS doesn't implement its own JS engine.
- prussian 6y ago
  util.promisify() seems to work for many of the node stuff I use a lot, like pipeline(), readFile(), etc. Perhaps require('xyz/promises') is a newer development.
  - spion 6y ago
    do you really want to keep util.promisifying everything? I know I don't. Streams (and event emitters, and the ecosystem bits that rely on them) still haven't fully caught up with promises either, e.g. async iterators and generators are still quite awkward
    - prussian 6y ago
      late reply. I've sort of experimented with async iterators and using pipeline() to pipe them together and it seems to work out for the most part; not sure what is awkward about them, I mean consume with an async iter on the source passed as an arg and you can throw at any time to kill it with an error. In fact I find the new async generator transforms easier and more ergonomic. in terms of event emitters. I can just use `await once(emiter, 'event');` now. Not sure how .on would be expected to work outside of it being some kind of async iterator. I mean, I don't mind using util.promisify or just importing the "to be" xyz/promises paths. The code exists clearly, either behind a symbol or otherwise.
      - spion 6y ago
        Compare with the Dart stream API: https://api.dart.dev/stable/2.12.2/dart-async/Stream-class.html https://api.dart.dev/stable/2.12.2/dart-async/Stream-class.h...
  - ianwalter 6y ago
    Why util.promisify `readFile` when `fs` exports promises?
    - tdy_err 6y ago
      Of course. It’s just new to users, relatively; only since 2019. To boot, one of the current LTS versions -the oldest- does not include it
jokethrowaway 6y ago
That's very subjective As an outsider who likes to lurk, I have the impression both ECMA and Node committees are stuck in the "we're nice and therefore right" field. They made technological choices that broke the platform (eg. require vs import). It took ages of pain to innovate on things that matter (eg. promises, async) I wish Deno the best, but I'll just try to stay away from JS from now on (same as I've been avoiding Python after the 2to3 migration).
- sbarre 6y ago
  Interesting... thanks for sharing some insight.. :)
- bliteben 6y ago
  yeah the dream of being able to share at the very least data types client and server side is pretty elusive. Most projects you could probably build twice before you could get client and server side sharing much code. Also just shocking me to me how averse the whole nodejs community is to shell commands like https://guides.rubyonrails.org/v4.2/command_line.html#custom-rake-tasks https://guides.rubyonrails.org/v4.2/command_line.html#custom... https://docs.djangoproject.com/en/3.1/howto/custom-management-commands/ https://docs.djangoproject.com/en/3.1/howto/custom-managemen... I guess though, the people in the Ruby / Django community are actually building projects and the node community are padding their resume with new npm packages. I hope deno or dart can make the JS world better, but I suspect they will both end up just making it more fragmented. One thing I really like on flutter / dart is they do try to rate / otherwise rank / categorize support of their packages aside from stars https://pub.dev/packages?sort=popularity https://pub.dev/packages?sort=popularity / downloads which are easy to manipulate. IMO deno should do this as well or let someone willing to takeover as the primary package manager https://deno.land/x/lodash@4.17.19 https://deno.land/x/lodash@4.17.19
  - jorisd 6y ago
    The NodeJS community isn't averse to shell commands as you described; far from it I'd say. But a main differentiating factor between the Node and Python community is that Node folks like to compose things from lower level functionality a bit more, and are much more into functional paradigms and patterns. It helps that in Node, everything has essentially consolidated to using Express and Connect-style middleware, so interop between frameworks and libraries is high, and it's easy to go from a lower level basic framework to one that has batteries included (to put it in Python analogies: going from NodeJS "Flask" to NodeJS "Django" is easy because in Node "Django" runs on top of "Flask" and has support for the same middleware pattern, so all "Flask" middleware works fine if you switch to "Django"). The higher level batteries included frameworks almost always ship with their own CLI and tooling that closely matches what you'd find in something like Django; take a look at Nest.js for an example of such a framework.

by sbarre 6y ago

beaconstudios 6y ago

Node is only just now getting around to adding promise based APIs to the core. Any time you interact with the Node core APIs you have to drop back to using callbacks - that's at least one area where Node is behind the times.

pharmakom 6y ago
Or use the ubiquitous NPM to install a promise orientated package... I don’t see this as a big problem honestly.
- beaconstudios 6y ago
  I'm not sure what you think could qualify Node as not keeping with the times, if not implementing the modern standard for async interfaces isn't it.
  - ianwalter 6y ago
    I agree with you that it would be nice if more of core supported promises, but I think there are probably plenty of examples of them keeping up with the times or charging ahead as well. Top-level await and optional chaining are a couple features that come to mind.
    - beaconstudios 6y ago
      true, the language-evaluation side is keeping up. But isn't that just a case of integrating newer versions of v8? NodeJS doesn't implement its own JS engine.
prussian 6y ago
util.promisify() seems to work for many of the node stuff I use a lot, like pipeline(), readFile(), etc. Perhaps require('xyz/promises') is a newer development.
- spion 6y ago
  do you really want to keep util.promisifying everything? I know I don't. Streams (and event emitters, and the ecosystem bits that rely on them) still haven't fully caught up with promises either, e.g. async iterators and generators are still quite awkward
  - prussian 6y ago
    late reply. I've sort of experimented with async iterators and using pipeline() to pipe them together and it seems to work out for the most part; not sure what is awkward about them, I mean consume with an async iter on the source passed as an arg and you can throw at any time to kill it with an error. In fact I find the new async generator transforms easier and more ergonomic. in terms of event emitters. I can just use `await once(emiter, 'event');` now. Not sure how .on would be expected to work outside of it being some kind of async iterator. I mean, I don't mind using util.promisify or just importing the "to be" xyz/promises paths. The code exists clearly, either behind a symbol or otherwise.
    - spion 6y ago
      Compare with the Dart stream API: https://api.dart.dev/stable/2.12.2/dart-async/Stream-class.html https://api.dart.dev/stable/2.12.2/dart-async/Stream-class.h...
- ianwalter 6y ago
  Why util.promisify `readFile` when `fs` exports promises?
  - tdy_err 6y ago
    Of course. It’s just new to users, relatively; only since 2019. To boot, one of the current LTS versions -the oldest- does not include it

jokethrowaway 6y ago

That's very subjective As an outsider who likes to lurk, I have the impression both ECMA and Node committees are stuck in the "we're nice and therefore right" field. They made technological choices that broke the platform (eg. require vs import). It took ages of pain to innovate on things that matter (eg. promises, async) I wish Deno the best, but I'll just try to stay away from JS from now on (same as I've been avoiding Python after the 2to3 migration).

sbarre 6y ago
Interesting... thanks for sharing some insight.. :)
bliteben 6y ago
yeah the dream of being able to share at the very least data types client and server side is pretty elusive. Most projects you could probably build twice before you could get client and server side sharing much code. Also just shocking me to me how averse the whole nodejs community is to shell commands like https://guides.rubyonrails.org/v4.2/command_line.html#custom-rake-tasks https://guides.rubyonrails.org/v4.2/command_line.html#custom... https://docs.djangoproject.com/en/3.1/howto/custom-management-commands/ https://docs.djangoproject.com/en/3.1/howto/custom-managemen... I guess though, the people in the Ruby / Django community are actually building projects and the node community are padding their resume with new npm packages. I hope deno or dart can make the JS world better, but I suspect they will both end up just making it more fragmented. One thing I really like on flutter / dart is they do try to rate / otherwise rank / categorize support of their packages aside from stars https://pub.dev/packages?sort=popularity https://pub.dev/packages?sort=popularity / downloads which are easy to manipulate. IMO deno should do this as well or let someone willing to takeover as the primary package manager https://deno.land/x/lodash@4.17.19 https://deno.land/x/lodash@4.17.19
- jorisd 6y ago
  The NodeJS community isn't averse to shell commands as you described; far from it I'd say. But a main differentiating factor between the Node and Python community is that Node folks like to compose things from lower level functionality a bit more, and are much more into functional paradigms and patterns. It helps that in Node, everything has essentially consolidated to using Express and Connect-style middleware, so interop between frameworks and libraries is high, and it's easy to go from a lower level basic framework to one that has batteries included (to put it in Python analogies: going from NodeJS "Flask" to NodeJS "Django" is easy because in Node "Django" runs on top of "Flask" and has support for the same middleware pattern, so all "Flask" middleware works fine if you switch to "Django"). The higher level batteries included frameworks almost always ship with their own CLI and tooling that closely matches what you'd find in something like Django; take a look at Nest.js for an example of such a framework.