4 ms·

Bower for package management. JS needs a better package manager for browser packages. (NPM is great for Node-style packages, but bower is becoming the defacto s

by randall 13y ago

Bower for package management. JS needs a better package manager for browser packages. (NPM is great for Node-style packages, but bower is becoming the defacto standard for distribution of browser packages.)

andreypopp 13y ago
Why do you think npm can't be used for browser apps? I publish all my browser code on npm and then use it via browserify. That way I started to write a lot more code which works both in browser and in node.
- randall 13y ago
  Simple: Not all node packages work in the browser. It'd be great if I could just say "ok this package will work for the browser, period." Also, with a module format that the browser can use (ie ECMAscript 6)
Kiro 13y ago
I haven't understood the need for Bower either. If I want say jQuery or Angular I just go to their websites and copy the CDN url. I don't see the problem to be honest.
- biscarch 13y ago
  Well, I can see it being useful if you're already on the command line or if you have to set up a lot of different projects with different configurations.
  - chhuang 13y ago
    From what I understood is: For normal approach: 1. Google CDN jquery 2. Get the CDN link of jQuery 3. Add it to your template For Yeoman/Bower: 1. bower install jquery 2. Get the link/path where bower installed jQuery 3. Add it to your template
- lobster_johnson 13y ago
  The need for something like Bower or Browserify comes when you have complicated projects with lots of dependencies, some more than one level deep. For example, app A depends on library B which depends on library C. If C is jQuery and those are all the dependencies you have, it's fine; but when a project grows a little larger, you do want a proper system. This is not an uncommon thing; modularizing an app or library into many small, independent parts is simply good practice. Concrete example: Our company has a library which is currently monolithic and too big for its own repo, so it needs to be broken up into many different modules. For this we have to have a dependency system because every module in the library needs to be able to say that it needs another module to run. Plus, if you are developing an app that uses (a bunch of modules from) the library, you want to be able to work on the module code concurrently. Having to minify/package library code and copy it into the app every time you make a change is very inconvenient. Plus, eventually you need to bundle a single file, eg. mylib.min.js, that combine all the modules. Also a chore without a dependency system. Might be fine for just isolated one case, gets stupidly annoying for the next project, and the next, and so on. What I like about Browserify is that you just require libraries in your code where you need them, and that way all dependencies are expressed in code; whereas Bower has explicit metadata, separate from the code, which may get out of sync over time.
v13inc 13y ago
I'm personally a big fan of component [1]. It acts a lot like NPM, but uses an actual Makefile behind the scenes (I always though Grunt was a tad ugly...). [1] https://github.com/component/component https://github.com/component/component

by randall 13y ago

andreypopp 13y ago

Why do you think npm can't be used for browser apps? I publish all my browser code on npm and then use it via browserify. That way I started to write a lot more code which works both in browser and in node.

randall 13y ago
Simple: Not all node packages work in the browser. It'd be great if I could just say "ok this package will work for the browser, period." Also, with a module format that the browser can use (ie ECMAscript 6)

Kiro 13y ago

I haven't understood the need for Bower either. If I want say jQuery or Angular I just go to their websites and copy the CDN url. I don't see the problem to be honest.

biscarch 13y ago
Well, I can see it being useful if you're already on the command line or if you have to set up a lot of different projects with different configurations.
- chhuang 13y ago
  From what I understood is: For normal approach: 1. Google CDN jquery 2. Get the CDN link of jQuery 3. Add it to your template For Yeoman/Bower: 1. bower install jquery 2. Get the link/path where bower installed jQuery 3. Add it to your template
lobster_johnson 13y ago
The need for something like Bower or Browserify comes when you have complicated projects with lots of dependencies, some more than one level deep. For example, app A depends on library B which depends on library C. If C is jQuery and those are all the dependencies you have, it's fine; but when a project grows a little larger, you do want a proper system. This is not an uncommon thing; modularizing an app or library into many small, independent parts is simply good practice. Concrete example: Our company has a library which is currently monolithic and too big for its own repo, so it needs to be broken up into many different modules. For this we have to have a dependency system because every module in the library needs to be able to say that it needs another module to run. Plus, if you are developing an app that uses (a bunch of modules from) the library, you want to be able to work on the module code concurrently. Having to minify/package library code and copy it into the app every time you make a change is very inconvenient. Plus, eventually you need to bundle a single file, eg. mylib.min.js, that combine all the modules. Also a chore without a dependency system. Might be fine for just isolated one case, gets stupidly annoying for the next project, and the next, and so on. What I like about Browserify is that you just require libraries in your code where you need them, and that way all dependencies are expressed in code; whereas Bower has explicit metadata, separate from the code, which may get out of sync over time.

v13inc 13y ago

I'm personally a big fan of component [1]. It acts a lot like NPM, but uses an actual Makefile behind the scenes (I always though Grunt was a tad ugly...). [1] https://github.com/component/component https://github.com/component/component