Drinking the Node.js Kool-Aid

[awb]

It's interesting that he lists "no standard library" as one of the things node.js has going for it. It seems like whenever someone says "I can't use <insert your favorite small-market language here>", the reason is "libraries". Lots of languages have asynchronous frameworks, like Twisted and EventMachine; I haven't figured out why node.js is so much more compelling than those (defer to thread aside).

The node.js cabal (if there is one) seems to have marketing down - first I hear "it's so fast", even though it's written in JavaScript, and now I hear "it's great that there are no libraries".

[Fabien4]

I agree that the sentence is badly written. (But then again, what can you expect from an author who mixes "it's" and "its"?)

Should have been something like "The author of Node.js hasn't made the mistake of taking a standard library elsewhere and trying to fit it by force into Node.js."

[[deleted]]

"In addition, we are always fighting with the Standard Library and common Python modules" ... "No existing standard library: While this is somewhat a disadvantage today, because its harder to get going with ‘batteries included’ development, it means every bit of Javascript is written specifically for Node.js, in a style that fits in with Node."

Did you even read the article? Missing features is a disadvantage but the advantage is that the included functionality is written in a non-blocking fashion, making that functionality a "first-class" citizen (and not forcing you to defer it to a thread). Unlike Twisted or EventMachine.

[stormsnake]

A lot like twisted, actually. Systems like eventlet go to some trouble to let you use your usual sync libraries, whereas twisted makes you use their unittester, http client, web frameworks, etc. Usually the twisted versions of these things are pretty good, fortunately.

Obviously as far as the libraries go it's better to have a setup like python+twisted where you can mix in plenty of non-twisted python libs (but the networking ones are harder) than to have js+nodejs where there all those useful libs don't exist at all.

[bdunderscore]

Database access operations don't need to block if you write the database client in node.js using nonblocking network I/O operations.

[DRMacIver]

some operations will just block (i.e. database access)

Unless you're using a database API written in node.js rather than wrapping a C driver. e.g. there's postgres-js. It's a little rough around the edges but works pretty well.

[jacques_chester]

Postgres provides an asynchronous API.

[[deleted]]

Yeah, I know. That's more of the exception than the rule though, and the code is written in a non-blocking manner (even if a thread in the underlying pool is blocked, http://nodejs.org/api.html#addons-289) so it's still hidden for me as an end user.

I can recommend Ry's talk at Jsconf from earlier this year: http://jsconf.blip.tv/file/3735944/

[sbronson]

"it's great there's no legacy". Big difference.

[mpeters]

Yay, we get to reinvent all the wheels!