Hacker News Reader

Comment by sbarre | Hacker News Reader

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?

View on HN

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).

Interesting... thanks for sharing some insight.. :)

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... 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 / 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

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.

> "we're nice and therefore right"

Golden phrase to describe a lot of folks. If I were to translate, it's behaving pleasantly and politely in order to justify poor decisions.

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.

Or use the ubiquitous NPM to install a promise orientated package... I don’t see this as a big problem honestly.

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.

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.

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.

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.

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

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.

Compare with the Dart stream API: https://api.dart.dev/stable/2.12.2/dart-async/Stream-class.h...

Why util.promisify `readFile` when `fs` exports promises?

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

Reply on news.ycombinator.com