5 ms·

Is there a reason to build a command line application in Node.js? It doesn't really seem like Node is the right tool for the job...

• rgbrgb 13y ago
  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.
  • retr0h 13y ago
    This is what happens when you let front-end developers loose in your infrastructure.
    • gcr 13y ago
      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.
      • retr0h 13y ago
        I have written plenty of JS, and absolutely hate it.
    • deleted 13y ago
      [deleted]
    • axaxs 13y ago
      Well, there's my daily laugh :)
    • akbar501 13y ago
      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.
• aegiso 13y ago
  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.
  • 10098 13y ago
    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.
    • bcoates 13y ago
      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.
      • mhd 13y ago
        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...
        • zeckalpha 13y ago
          concurrency != async
• akbar501 13y ago
  Yes. 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.
  • stock_toaster 13y ago
    > 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.
    • daleharvey 13y ago
      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/ 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 http://pouchdb.com
    • akbar501 13y ago
      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.
• chrsstrm 13y ago
  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.
  • FooBarWidget 13y ago
    Isn't Ruby just 'gem install mysql'?
    • chrsstrm 13y ago
      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.
      • jrumbut 13y ago
        Sorry if this is off topic, but I remember having this exact issue when I was learning Ruby, maybe I can provide some clarity. For raw access to your MySQL database, the gem 'mysql2' is preferred (github with a simple tutorial: https://github.com/brianmario/mysql2 https://github.com/brianmario/mysql2). 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-and-activerecord 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.
        • chrsstrm 13y ago
          Thanks. Appreciate the info.
• DrJokepu 13y ago
  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.
• kephra 13y ago
  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.
  • jdlshore 13y ago
    > 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: #!/usr/local/bin/node console.log(process.memoryUsage()); And here's the output (memory usage is in bytes): jshore$ time ./deleteme.js { rss: 12660736, heapTotal: 4083456, heapUsed: 2131864 } real 0m0.055s user 0m0.043s sys 0m0.011s
• derengel 13y ago
  I was thinking the same, does nodejs even has a complete linux api interface like python or ruby? EDIT: Ok, just went through the nodejs api, they have cover a lot of ground now :)