Why is everybody using Node.js and NPM for compiling JavaScript libraries?

"If you haven't already, you'll need to install node.js..." You read messages like this and you're turned off. Why?

NodeJS is Google's V8 "running on it's own". It's a JS engine with additional low-level API (Network,I/O,etc.). NodeJS provides "the missing platform" for JS developers, who were just limited to working on a browser.

why this dependency on Node.js and NPM?

Node.js, aside from using it as an app (servers, proxies, bots etc.), it can also be used as a tool build and aid development. Take for example Grunt which is a scriptable automation tool which is similar to Make. Scripting in just plain JS, you need not learn another tool or language to do automation. Another tool is Bower, which is a front-end package management tool. All you need to do is a bower install jquery and it installs jquery with that single command. No need for manual download, copy and paste.

NPM, on the other hand, is Node.js' package manager. It's a program that manages the modules you use on NodeJS. No need to list down your modules manually, and no need to remember them when you develop somewhere else. As long as you have the package list NPM made for you, reinstalling is just a matter of npm install.

Why are we making things complex?

We're not. In fact, we're making them easy for developers. Instead of worrying on your workflow, managing your libraries, or doing stuff manually, you can off-load these tasks to some of the modules that exist on NPM. Then you can just focus on what you are actually doing.

On top of this we are using Node.js to use these libs/frameworks... How will this push usage of these libraries to new JS developers? JS was meant to easy!

Like mentioned above, NodeJS is a versatile platform. It can be used as a server (Connect, Express), an automation tool (Grunt), a package management system (using NPM, Bower etc.), a testing platform (QUnit, Mocha), a proxy, game server, chat bot.

And it's beneficial, especially to the JS developer, since these weren't possible in JS.

There is already a problem of plenty in JS - far too many active JS libs/frameworks to choose from - going by the record of JS libs most will become inactive soon. There are just too many things to look for that often result in multiple frameworks in an app - dependency management, routers, MVC, templating, etc.

Well, it's good to have an abundant set of frameworks. Your work will be cut in half after learning some of them. Implementation diversity is also good, to address different styles of coding and different approaches of implementation. Some libraries rise from differing approaches, while others rise from the incompatibilities and/or incompleteness of others.

The developers are hard at work to make life easier for other developers by normalizing JS quirks (because browser vendors just can't seem to do the right thing of following standards) and most of them are done voluntarily, like free beer - you should be happy for that. Besides, nobody's forcing you to use one anyway.

The CommonJS standard (best implemented, in my opinion, by Node.js and NPM) introduces the concept of modules to Javascript. For years, the Perl and Python communities have demonstrated why modules are awesome:

• Unix-style "do one thing and do it well" libraries that are small and heavily tested against bugs, that can be combined easily (with no namespace issues) to solve your particular task.
• Central repository of open source modules (CPAN, NPM, etc) that you can easily pull the modules from (NPM takes it one level higher by keeping all of the versions available, so you can specify that your code uses the last known "good" version rather than hope that nothing broke when you redeploy a la CPAN).
• Greater peer review of the code (since they are more easily composable, they're used in more varied situations, so this is what helps reduce the bugs, but also what helps improve the modules to be more generalized).
• Greater variety of tasks solved. Since the libraries are short, pretty much anyone can write one. That does mean there's a lot more crap to filter through (articles about widely-used libraries help with this), but it also means a library that solves some very specific problem (such as localizing strings and dates ) probably also exists.

And then a Node module called browserify makes the actual build process for your client-side code incredibly simple, and you can use just about any piece of code you find on NPM.

This breaks away from the "kitchen sink" mentality of libraries like jQuery (who have developed their own custom build system so they can start modularizing their code, too) that believe they need to solve every problem their user might have, rather than just produce results that can be used by other libraries.

Edit: noticed I was answering the question as worded in the question body, but missed the compilation question in the title.

What criteria do you have for considering this an "extreme measure"? This has been done for years, for the sake of writing clean, easy to read/write code, but precompiled to be optimized for on-the-wire transfer (and perhaps other optimizations as well). Node.js makes a nice solution for this, simply because it's also using JavaScript and therefore familiar to people using it to compile their JavaScript code. Previously this was typically done in something like Python, which, though working, seems less sensical to me than sticking with a common language.

Very often you needs different builds of your javascript. Usually it is spread out in different files, sometimes its in coffeescript. You often want a build AMD compatible build, as well as CommonJS one, plus regular minimized and unminimized builds.

There's also the potential for dependency resolution.

I've even seen a library that had a build for jQuery and protoype...