Let's make npm the standard for managing front-end packages

npm-for-frontend.md

Let's make npm the standard for managing front-end packages.

Why?

• The state of front-end package managers is all over the place.
• Bower is still very non-standardized, resulting in bloated downloads and making it difficult to rely on libraries being packaged up in a consistent way.
• None of the other package system (e.g. Component) seem to have enough momentum that they're going to reach critical mass.
• The npm community has a single good, effective way to use npm modules in the browser with Browserify.
• Browserify doesn't try to do too much or too little. It simply traces dependencies and bundles everything into a nice, tidy package.
• The CommonJS module system is reasonably easy to understand, easy to read, and generally pleasant to work with. While AMD has its advantages, it generally loses in the categories of clarity, readability, and consistency (in that you still need to use a separate module system for backend node modules.)
• Non-JS frontend assets, such as CSS libraries, don't need to use Browserify. As long as you're using a CSS pre-processer (and who isn't?) you can just @import libraries from /node_modules to be packaged up into your compiled CSS.
• npm is now an independent organization with financial backing. It will continue to be improved by smart people in the coming months. Bower is wonderful and has great people behind it, but the community is better off standardizing on a single package system and making as many packages as possible available there.
• Many projects are already going to have a package.json, especially with the proliferation of Grunt/Gulp, so why add an additional config file for something like Bower?
• Bower is installed using npm. Oh, the irony.
• The big disadvantage npm currently has is in branding and communication. The Bower team has done a top-notch job publicizing Bower and making it approachable for front-end developers. Having a good, friendly name, and a high-quality logo does a lot for pitching an ecosystem (same goes for Grunt and Yeoman). npm has done poorly in each of these regards. Using an acryonym for a company name is generally a poor naming practice. "npm" isn't memorable, it isn't friendly, and it doesn't explain what it even is. This last point is compounded by the fact that the npm team jokingly says that "npm" stands for "Not a Package Manager". Okay, so your acronym definition is also confusing and meaningless. Got it.

Which of these package system names is the most unfriendly?

• Bower (frontend)
• Gems (Ruby)
• Composer (PHP)
• Pip (Python)
• Homebrew (System)
• Atmosphere (Meteor)
• npm (Node)

The name and presentation of npm (as well as the writings of community members, to some extent) projects the image that npm is "not for you". It is for node developers only, for people in "the know". The npm team has expressed interest in distancing themselves from that perception, but so far nothing seems to have been done.

All of that being said, npm strikes just the right balance of ease-of-use, ecosystem maturity, and flexibility