[jerf]

But... if you're going to bolt on an "async" library, bolt on threading, and bolt on strict typing, why not use something that starts with that stuff? And ends up doing it better since it was actually created with that stuff in mind, instead of aftermarket bolt-ons?

Saying that those things "fix" Node amounts to an admission that you shouldn't have started with Node in the first place.

[twerquie]

Because bolting reusable libraries together is 90% (meaningless number alert) of what we do when assembling modern applications. And in this respect, Node is perfectly suited to the job, boasting

a) A small core API instead of a sprawling standard class library

b) A highly composable export and require mechanism, better in some interesting ways than what exists in other systems (1)

c) The fastest growing and soon to be largest community repository of packages (2)

d) asynchronous by default stack and ecosystem.

With those things in hand, "bolting on" is a virtue and not a disadvantage. That Node is general-purpose - you can build cross-platform desktop applications, streaming servers, web applications, console utilities, etc - and does not impose its package opinions are major factors in its success.

1) http://blog.izs.me/post/1675072029/10-cool-things-you-probab...

2) http://modulecounts.com/

[awj]

Bolting reusable libraries together is great for some things, not so much for others. How much of that large package repository uses different (or worse, conflicting) solutions for abstracting async programming? Some batteries really are better off being included.

[jerf]

And I'd observe that all three of the things I mentioned ("async", threading, static typing) are firmly in the "not" camp.

If the Node community admits these are desirable characteristics of a programming development environment, then they've lost, because they can not compete on any of those three fronts. The entire value proposition of Node was basically that those three things weren't important. If they are, Node's arrogant swagger turns into a frantic attempt to cobble together enough functionality to pretend to have the features that exist better elsewhere.

Don't think you can sell me on fundamental weaknesses in your language of choice being features, twerquie. I've got too much experience in too many environments to fall for that.

Why, it's almost as if Node is built on fundamentally 1990s scripting technology based on fundamentally 1970s event-based ideas or something, instead of being the radical revolutionary departure we all know it really is.

[twerquie]

It is true though that many js deficiencies have turned out to be factors contributing to node's popularity. A lack of namespaces, standard library and import/require come to mind.

I'm not interested in arguing about technical superiority, I'm sure node is no where close to ideal. But, like javascript itself, it's popular, interesting, useful, and here to stay. From my perspective, for better or worse, javascript is the most important programming language of the decade.

[twerquie]

Different yes, conflicting no.

ES6 standard promises have landed in v8 (https://code.google.com/p/v8/source/browse/trunk/src/promise...) so it's only a short matter of time until the "batteries included" solution is available.

But that doesn't mean people will be forced to use them.

[zo1]

"a) A small core API instead of a sprawling standard class library"

Using adjectives to accentuate, does not an argument make. "small/core" and "sprawling" all have loaded meanings. And if you wish to convert anyone but the already-converted sub-culture inhabitants, you should probably quantify what you mean and why it's a benefit.

[twerquie]

I think my point is clear when you read what I wrote as a whole instead of dissecting parts. I'm allowed to editorialize a bit, am I not? I'm not a robot nor am I writing my thesis on the subject, we're just talking here.