It's fun, simple, fast, and has a good package manager. JS is a high level scripting language like python or ruby but gives significant speed benefits in a lot of cases (in particular, the startup time of CLI programs written in Ruby always bothers me).
If you want to write in C for performance reasons, go ahead. But if your other alternatives are Python or Ruby and you already know JS, give node a go -- it's pretty fun.
Don't knock it 'till you try it. Most developers would balk at the idea of creating a project in something that isn't their favorite language, especially when they've been burned by poor uses of that language before.
2 plus years ago there may have been merit to your implicit assumption that JavaScript is limited to front-end developers.
However, today there is more diversity in the JavaScript developer community. For example, Yehuda Katz is both a server-side (Rails) team member and client-side (JQuery, Ember) developer. Also, system engineers have begun working in JS. The Meteor team is a good example of system engineers working on JS.
If you're doing crazy heavy processing or something, it's not the right tool. But you wouldn't do that in JS. You'd shell out or call something native.
Node is best used managing parallel streams of stuff. Perhaps surprisingly, a command line application is a great example of that.
I would much rather build a nontrivial command line app in node than in anything else. Try it, you'll see.
There are tons of better options to choose from. If you're not making a web UI, literally any choice is better than Javascript, unless that is the only language you know.
Compared to most languages you'd use for a commandline application, node has a simple, usable async I/O interface, and the libraries you can get for it actually assume async.
If you need that, there are only a handful of choices and node is one of them.
Which scripting language doesn't have an async library available (most of which don't descend into the Chinese Hell of Being Called Back Ad Infinitum)? Granted, most of the other languages have lots of libraries that don't play well with async, but then again, that's mostly because they have lots of libraries. And it's not like there's a guarantee that a random Node package won't screw you up, either.
I'm not really arguing against using JavaScript for command-line interfaces. I'd much rather see that than the same in PHP, and if the programmers don't know Perl, Python or Ruby, then why not? We're talking about an area where there are still way to many hacks that consist of badly written bash scripts with lots of inline sed and awk...
People don't use node for the Javascript. They use it for the modules, and node is the glue that coheres them (and does an admirable job at that).
When you're comparing writing a CLI app in node to writing it in something else, it's a world of difference, and that difference is npm. With good modules, writing a CLI app has little to do with Javascript -- you're more specifying config and flow by passing some options and streams around, and you're done.
How about writing it in Perl and using CPAN instead of npm then? There are tons of modules in CPAN.
But since Perl is not cool any more, there's always Python and pip.
I have yet to see any language repository that constrains quality in the way CPAN does with CPAN testers.
CPAN modules must provide POD documentation, must provide a regression test, and must run on several dozen platforms before PAUSE accepts to publish it on CPAN.
Python or Ruby modules, or my favorite Lua, are a bunch of junk compared to CPAN.
If a person already knows JavaScript well, then it will be easier for them to write a CLI app/utility/script in JS than it would be to write a shell script.
Another reason to write in JS would be to gain code reuse. If the person has a web app that uses node, then they can share code between the web and CLI applications.
> Another reason to write in JS would be to gain code reuse.
> If the person has a web app that uses node, then they can
> share code between the web and CLI applications.
I often see this argument presented for just about any server side js. I often wonder about actual real world reuse though.
I actually reuse the same code a lot, which is a very nice feature once you get used to it.
I share code between the client and server. For example, I have data type checks where I reuse the same library and the same application specific code on both the client and server.
I expose substantial portions of my server-side code via the command line. I also frequently call shell scripts from node as there are certain things I find easier to write in a shell script.
That said, I don't know if this amount of reuse is typical. And, code reuse is clearly not the only consideration.
Look at the top 2 depended on modules modules in the entire of the server side node.js ecosystem and guess what they were written for - https://npmjs.org/
I wrote a database specifically for web browsers and someone case along and write a relatively small pull request and it now works in node / on the server / with a http api - http://pouchdb.com
Depends on the job. I'm writing a command line app in Node right now to automate a couple thousand SQL queries for a db I'm working with. Node wasn't my first choice, but I looked at how to connect both Ruby and Python to MySQL and it seemed like more trouble than it was worth for a one-time use utility. Node was just 'npm install mysql'. Might not be the best way, but I only need to use it once.
I don't recall the instructions I looked at, but I know what I read was much more than a gem install. Correct me if I'm wrong, I actually wanted to use Ruby first.
mysql2 seems to have taken it's interface design from Perl's DBI, which is cool if you're used to that but might feel a little foreign.
If you'd like something that gives you a little more help, or there's substantial business logic in your script, take a look at ActiveRecord. This StackOverflow question (http://stackoverflow.com/questions/16683903/sinatra-mysql-an...) has a nice example of how you might set up your script to use AR.
My email's in my profile if you'd like any future help.
What is the memory footprint of node? What is the startup cost?
imho, node as command line makes even less sense then Smalltalk, Java or Mono. Those are heavy weight languages that have no place in interactive commandline scripting.
Better choices are the classical languages like Perl or Python, and Lua or awk has even less startup costs.
> What is the memory footprint of node? What is the startup cost?
It's fast enough, and low-overhead enough, that I don't notice any overhead when running my Node.js build scripts. And really, that's all that matters.
Out of curiosity, I wrote a little script to test it:
I don't think it has anything to do with the interface. Is your program mainly about handling input and output, tied together with some business logic? If yes, Node.js is probably a good choice. If not, Node.js might not be a very good choice.
