Death by Clientside Package Management

[DamonOehlman]

When it comes to writing and consuming modules for the browser, we are in crisis. It's definitely far from being a simple process and while I believe the answer lies in tooling, it's definitely not in the quantity of tooling but rather the quality that matter.

Don't get me wrong, some of the tools that have been created have been well engineered, but there really is no tool that I would look to for solving some of the package management woes I have experienced when building JS-centric web applications for the browser.

Additionally, the sheer number of tools that we have been provided with that really "don't solve the problem" is quite astounding. This makes picking a tool for someone exploring options for improved clientside app builds an incredibly daunting task. So now we have two problems:

1. Working out how to better manage dependencies in our JS code; and,
2. Choosing a tool and generally an approach that will assist us to do this.

It feels like another AMD vs CommonJS discussion / fracture, but possibly worse :/

[DamonOehlman]

Oh, and if anyone wants a list of existing solutions with my opinion on those then let me know and I'll open the can of worms...

[liammclennan]

I would like you to open the can.

[DamonOehlman]

Fine. But be aware that there is no going back... I'll outline the options in this comment (and edit it in parts). Additionally, other folks should feel free to contribute comments to talk about other options also. Additionally, I'll cover these tools from a somewhat chronological perspective (i.e. from the point I started looking and discovering to now).

In a subsequent comment I'll outline the killer features from each that I think should be incorporated in the "one tool to rule them all"...

BPM

http://getbpm.org/

• Implemented in Ruby
• Haven't had a lot of experience with BPM, I tend to avoid Ruby tools - yes I'm a bit opinionated that way...

Browserify

Browserify is an interesting beast and while there are parts of the approach I'm not a fan of (shimming out Node specific libraries for the browser) you have to give it credit, it's a tool that works. Browserify is a good choice for anyone who spends more time in Node than anything else, and also tends to think that AMD as a pattern is not for them.

https://github.com/substack/node-browserify

• Implemented in Node
• CommonJS centric
• Uses NPM for package management
• Implements a require shim that correctly resolves those calls back to code within a single combined JS file for use in the browser.
• Contains shim code for Node that means things like require('fs') don't cause errors.

Ender

http://ender.no.de/

• Implemented in Node
• Uses NPM as the package backend
• Produces results similar to Browserify
• To be completed

JamJS

http://jamjs.org/

• Implemented in Node
• Backed by a CouchDB backend (similar to NPM)
• To be completed

Volo

http://volojs.org/

• Implemented in Node
• Uses Github (source repos) as package backend
• Implements some intelligence to attempt to locate an appropriate package for a request
• Uses a pragmatic overrides repo to supplement information in source repos - very clever.
• To be completed.

Component

https://github.com/component/component

• Implemented in Node
• Uses Github (primarily package repos) as package backend
• Designed to go beyond the scope of JS, and consideration made to CSS and other assets.
• To be completed

Bower

http://twitter.github.com/bower/

• Implemented in Node
• Looks to be compatible with Component (see above)
• Uses Github as the package backed, with a heroku based "lookup table"
• To be completed