[travislane]

What is the motivation behind writing tools like these in JavaScript? Not everyone is going to have Node or NPM. I don't want to first install NPM to install a utility.

But Perl/Python/Ruby are very likely to be present on more number of systems (Windows being an exception). Why aren't more of these utility tools written in Perl/Python/Ruby?

[dagw]

Perl and Python perhaps, but what systems ship with Ruby by default.

But anyway even if your OS ships with perl/python/ruby installed by default (and also the right version) it probably doesn't ship with whatever Postgres library they're using so you'll still have to deal with extra dependencies anyway. And talking about Windows, installing node tools on Windows with npm is on the whole much easier than doing the same with Python/Perl/Ruby, so there is that.

If you want to make an argument that it should have been written in some language that easily compiles down to a single binary you can just download and run, then perhaps people would agree with you. But I cannot see how Node is in any way worse, harder or less common than Perl/Python/Ruby.

[inferiorhuman]

Perl and Python perhaps, but what systems ship with Ruby by default.

OSX comes with Ruby and has for ages, although I think that's being phased out.

But I cannot see how Node is in any way worse, harder or less common than Perl/Python/Ruby.

Node has been notoriously difficult to get running on FreeBSD, for instance. Patches were submitted and just sat on by the maintainers. Something like Perl/Python/Ruby let you target a POSIX-ish system easily, Javascript does not (case in point: electron).

[IggleSniggle]

Can you expand on how electron relates to the argument that JavaScript does not easily target POSIX? Isn’t the issue the runtime (Node) not some GUI “library” (electron)?

[nicoburns]

> What is the motivation behind writing tools like these in JavaScript?

I mean it's probably as simple as the person writing it being most familiar with JavaScript. There are a LOT of javascript developers who have never used perl/python/ruby before. They're not going to learn another tool just to write the tool they want.

From a technical perspective, node also has much platform support (notably on windows) than perl/python/ruby.

[quickthrower2]

The nicest thing to do is release binaries for all major platforms (dependency free if possible). Then code it in whatever you want.

[paulcarroty]

Go rewrite it in your right language, nobody cares about haters.

[rswail]

This wasn’t a hate post. It was a legitimate question. My systems have python by default. Why do I want to add another dependency for node plus it’s inherent requirement for internet access to drag all the dependencies?

[dewey]

The answer is: because the author of the tool is comfortable in the language, wrote it for their use case and have NPM and node already set up. They were nice enough to share it so other people can use it too or port it to their favorite language.

[koolba]

Sure they have python, but which version of python do they have? 2? 3? 3.5? 3.7?

Arguably writing command line tools in Node.js has similar problems (8? 10? 12? 12.9?) though it has the advantage that not having a baked in version into your OS distribution means you have to install one yourself (which hopefully will match).

I think Go is a better choice for this type of thing as the end result is a copy-and-run-anywhere staticly linked binary.

[slantyyz]

>> This wasn’t a hate post. It was a legitimate question.

Seen through a different lens, it's actually a compliment.

The poster sees the utility in the tool, even though it's not built on one of the poster's preferred platforms.

But the great thing is that the OP shared the source code on Github, so it can be ported to other platforms... if one is motivated enough to do so.

[gramakri]

> it’s inherent requirement for internet access to drag all the dependencies

Isn't this required by package managers of all languages? pip/compose/gems all require internet access.