Comments

sgerovsgerov
last year

The idea that I liked the most is not relying on global state and import modules through ES6 etc, but Bower is also adapting to that (when doing bower init it asks what type of modularization are we going to use - it's still just informative but its a hint for the future).

They also argue about flat dependency analysis, I had to solve a couple manually in the past but it never was a problem. Probably it wouldn't be that hard to make a script. NPM isn't a dependency in my project yet, actually just use it to install bower so I can fetch deps. Going with NPM supposes a couple of additional difficulties such as installing browserify and adapting the modules that aren't ported to npm yet. Browserify generates a bundle so it has to generate it with every change (watchify). For a Meteor app it looks like a good solution because npm is already used for deps, but on Rails it looks like over-engineered solution.

He also argues about depending on github uptime, in general I believe that their infrastructure has less chances of falling than a private repo that we could mantain. Also he doesn't talk about CSS and assets which come with bower, not sure how browserify would bundle that - actually if it even can. Polluting the global namespace makes sense when you rely on the lib u are using.

Reply