Why does everyone use Node.js and NPM to compile JavaScript libraries?

Question

I really got confused with everyone in the JS community using Node.js and NPM with my JS libraries. Why should we resort to such extreme measures? What problems is this solution for us?

[Edit] I think that was not my question.

• Frames like Ember.js, Batman.js and, more recently, Yahoo Mojito require me to use Node.js - why is this dependency on Node.js and NPM?
• Why do we make things complicated? "If you have not done so already, you will need to install Node.js ..." You read these messages and you are disconnected.

Why? JS already has a surplus problem - there are too many active JS libraries / frameworks to choose from - as a result of writing JS libraries, most of them will soon become inactive. There are too many things to look for that often lead to the creation of multiple frameworks for managing application dependencies, routers, MVC, patterns, etc. In addition, we use Node.js to use these libs / frameworks. How will these libraries be used for new JS developers? JS was for relief!

Answer 1

"If you have not done so already, you will need to install node.js ..." You read these messages and you are disconnected. Why?

NodeJS is Google V8 "running on it." This is a JS engine with an additional low-level API (network, I / O, etc.). NodeJS provides a “missing platform” for JS developers who were limited to only working in a browser.

why is this dependency on node.js and NPM?

Node.js, in addition to using it as an application (servers, proxies, bots, etc.), it can also be used as a tool and help development. Take, for example, Grunt, which is a scripting automation tool that is similar to Make. Scripts in simple JS, you do not need to learn another tool or language for automation. Another tool is Bower, which is a package management interface. All you have to do is bower install jquery and it installs jquery with this single command. No need to manually download, copy and paste.

NPM, on the other hand, is node.js' package manager. This is a program that manages the modules you use in NodeJS. No need to list your modules manually, and no need to remember them when you are developing somewhere else. As long as you have the list of NPM packages made for you, reinstallation is just a npm install issue.

Why do we make things complicated?

We do not know. In fact, we make them easy for developers. Instead of worrying about your workflow, managing your libraries, or doing things manually, you can turn off these tasks to some modules that exist in NPM. Then you can just focus on what you are actually doing.

In addition to this, we use node.js to use these libs / frameworks ... How will this lead to the use of these libraries for new JS developers? JS was for relief!

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

And this is beneficial, especially to the JS developer, since in JS this is not possible.

JS already has a surplus problem - there are too many active JS libraries / frameworks to choose from - due to writing JS libraries, most of them will soon become inactive. There are too many things to look for that often lead to the creation of multiple frameworks for managing application dependencies, routers, MVC, patterns, etc.

Well, it's nice to have a rich set of frameworks. After studying some of them, your work will be cut in half. A variety of implementations is also good for dealing with different coding styles and different implementation approaches. Some libraries rise from different approaches, others from incompatibility and / or incompleteness of others.

Developers are working hard to make life easier for other developers by normalizing JS quirks (because browser vendors just can't seem like the right standards), and most of them run voluntarily, like free beer — you should be happy for that. In addition, no one forces you to use it in any way.

Answer 2

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

• The do-it-and-do-well Unix stylistic libraries are small and thoroughly tested for errors that can be easily combined (without problems with the namespace) to solve a specific problem.
• A central repository of open source modules (CPAN, NPM, etc.) from which you can easily extract modules (NPM takes it one level higher, preserving all available versions, so you can indicate that your code uses the latest known " good "version, not the hope that nothing broke when redeploying a la CPAN).
• Improved code review (since they are easier to compose, they are used in more diverse situations, so this helps to reduce the number of errors, and also helps to improve the modules so that they are more generalized).
• A wide variety of tasks. Because libraries are short, anyone can write them. This means that there is a lot more crap for filtering (articles about widely used libraries help with this), but it also means that the library solves some very specific problems (such as localizing strings and dates ), probably also exists.

And then the Node module called browserify makes the process of building your client code incredibly simple, and you can use almost any piece of code that you find in NPM.

This breaks away from the mentality of the “kitchen sinks” of libraries such as jQuery (which have developed their own build system so that they too can begin the modular development of their code), who believe that they need to solve all the problems that their user may encounter, and not just producing results that can be used by other libraries.

Answer 3

Very often you need different builds of your javascript. It usually spreads in different files, sometimes in coffeescript. You often need a build to build AMD, as well as CommonJS, plus regular minimized and non-minimized builds.

There is also potential for resolving dependencies.

I even saw a library that had an assembly for jQuery and protoype ...

Answer 4

Edit: noticed that I answered the question as formulated in the body of the question, but missed the compilation question in the title.

What criteria do you have for considering this “last resort”? This has been done for many years, for the sake of writing clean, easy to read / written code, but precompiled to optimize for wired transmission (and possibly other optimizations). Node.js makes a nice solution for this, simply because it also uses JavaScript and, therefore, is familiar with people who use it to compile their JavaScript code. Previously, this was usually done in something like Python, which, although it works, seems to me less sensitive than sticking to a common language.