Hacker News Reader

Comment by kostarelo | Hacker News Reader

> Extending web programming beyond the browser is not a novel idea. Indeed, we have done that with moderate success in our “Node.js” project. But over a decade later, we find server-side JavaScript hopelessly fragmented, deeply tied to bad infrastructure, and irrevocably ruled by committees without the incentive to innovate. As the browser platform moves forward at a rapid pace, server-side JavaScript has stagnated.

wow lots of bold statements there. And another one for the usual "JavaScript is fragmented, let's create another tool to fix 'em all.".

View on HN

Ryan Dahl (author of the announcement post) is the creator of Node.js, so I think he's got a right to say these things! Also see "10 things I regret about Node" [0]

[0] https://www.youtube.com/watch?v=M3BM9TB-8yA

Ryan Dahl left the leadership of the Node.js pretty early in its development. A lot of people can be considered "the creator" of Node.js to be fair.

While I'm not going to argue the history of if/when he left the project, my understanding is that it's fairly agreed upon that he is the creator of Node.js. If you google "node js creator", he's an embedded answer (not a search result).

The first line on Wikipedia in the nodejs history section is "Node.js was written initially by Ryan Dahl in 2009".

You can make whatever point you want, but maybe try to do it without rewriting history, or changing the agreed-upon definition of "creator".

> If you google "node js creator", he's an embedded answer (not a search result).

Embedded answers are worse than useless.

https://www.google.com/search?hl=en&q=who%20invented%20hands

Finding a exemplar of a bad response does not make the entire category "worse than useless".

The result is relevant and the information is (presumably) correct: "Introducing hand disinfection standards"

>Ryan Dahl left the leadership of the Node.js pretty early in its development. A lot of people can be considered "the creator" of Node.js to be fair.

Don't think so. I have been using Node.js since 2010 and following the ecosystem. Node.js is the child of Ryan Dahl. Other than Ryan, perhaps Isaac Schlueter is the most influential person who developed the NPM as a separate project and later merged into Node. Ryan could have done it himself or embedded it in Node.js, but guessing from Deno he is not keen on a centralised package repository so could have let Isaac build NPM as a separate project.

From what I could observe, the overall API is still pretty much the same from 2010. What's changed is V8 getting updated to newer versions (and thereby supporting new ES features) and other performance optimizations. But no one can't deny or take away the creator credit from Ryan.

No. Ryan Dahl was the initial individual creator of Node.

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?

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

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.

I hear you, but I'll also give them some credit—you can't create anything worthwhile without a clear vision which basically requires an opinionated sense of purpose.

Right behind the giant understatement of calling Node a “modest success.”

A modest understatement if you will

It feels like the old IO.js vs node.js. I hope this time too the two ecosystems get merged, but this time it feels much harder to happen

Wasn't that more of an ideological than technical split?

Deno is more of an ecosystem reboot than a fork, I would think.

Yeah, with the use of "it feels" this time I was literally trying to express the feeling of "oh no, another big divergence in js" like it felt at the time (even if it was indeed ad "ideological split" as you say, I remember clearly at the time a lot of blog posts about how it meant that in the long run we COULD have different ways of doing things / calling apis / build frameworks / etc... )

Fair enough.. I agree that we'll have to see where this goes, and hopefully a technical effort doesn't get overshadowed by an ideological one..

Because you know this blog post and announcement will draw some strong reactions from entrenched interests.

You cannot always cleanly differentiate these two. You could argue that "Node vs io.js" was an "ideological" split because they wanted different governance, but one big reason they wanted different governance is to make different technical choices (for example, track upstream V8 more closely), so you could also claim this was a "technical" split too.

Reply on news.ycombinator.com