6 ms·

The new bower.io

63 points by rayshan 12y ago

lukasm 12y ago
Is this http://stackoverflow.com/questions/20279792/how-to-update-bower-json-with-installed-packages http://stackoverflow.com/questions/20279792/how-to-update-bo... still the case? e.g. I forgot to install a package with --save and I want to update bower.json. With pip I just do pip freeze > requirements.txt
boredprogrammer 12y ago
Possibly a stupid question, but ... Can anybody explain to me the use case for Bower/Yeoman? Whenever I am adding javascript to a website I just use a cdn such as http://cdnjs.com/ http://cdnjs.com/ Why would I use Bower instead of this? Is it more of a node.js thing? Or is it something to do with hosting your own copies of the libraries instead of a CDN (I thought this was frowned upon)
- sehr 12y ago
  Bower has tons of packages that cdnjs doesn't, and includes CSS focused packages and the like. Yeoman is just a scaffolding tool, with application specific generators e.g. angular, backbone etc.. Generators also typically come with a build task, which creates a deployment ready folder all minified & concatted up for your enjoyment.
- rcsorensen 12y ago
  Some of the reasons you'd want to use Bower: * Your external libraries have dependencies, and having dependencies managed for you is a good thing. * The external components you're using include both JS and CSS, and need to be served separately. * Because you love your users, and want to concatenate your javascript and CSS to single files before serving it out to your users. * Because you're including components that expose SASS mixins you want to use inside your existing code. The hosted vs serving your own libraries is a complicated topic, but the basic answer comes down to "the less requests your clients have to make, the faster things will be".
  - city41 12y ago
    concatting JS libraries into your own JS payload is a debatable practice. If it's a popular library, the user likely has it cached already and so the request to get it takes a few milliseconds. Where as your own JS payload will change with every release, forcing them to always re-download the same library code.
- quarterto 12y ago
  Dependencies. For example, Backbone depends on Underscore, and simply writing <script src="underscore.js"/><script src="backbone.js"/> encodes nothing about that fact. There's nothing stopping you updating Backbone to say a 2.0 that requires features in Underscore 2.0, but forgetting to update Underscore. On the other hand, bower update backbone will see dependencies: {"underscore": "^2.0"} in bower.js and update Underscore as well.
  - sphildreth 12y ago
    Is it something like NuGet for .NET packages but for Javascript? Does that mean that an ASP.NET MVC application using NuGet wouldn't really have any "need" for Bower?
    - atonse 12y ago
      It's similar but for you to not "need" bower but get the same from NuGet, you'd have to make sure that every JS library you need is on NuGet.
- lvillani 12y ago
  Off-line applications. We are developing a cross platform mobile application which has to run locally on user's tablets. Reaching out to a CDN to fetch dependencies is out of the question. We are basically using HTML5 in place of Qt5 here. However, we found several horrible, horrible bugs with Bower randomly failing to install dependencies (such as https://github.com/bower/bower/issues/933 https://github.com/bower/bower/issues/933), which is now thankfully fixed. We are also investigating Browserify, so might switch to use NPM also for (some) client side dependencies.
  - Bahamut 12y ago
    I personally reported https://github.com/bower/bower/issues/1019 https://github.com/bower/bower/issues/1019 - that was an awful bug to deal with, and it caused us at work to put everything in bower_components into source control to guard against it in the future. To the Bower team's credit though, once they fixed the issue, I have had smooth sailing since.
- lucideer 12y ago
  They are generally recommended, though are also the occasional arguments against the use of CDNs http://zoompf.com/blog/2010/01/should-you-use-javascript-library-cdns http://zoompf.com/blog/2010/01/should-you-use-javascript-lib...
- hrktb 12y ago
  One of the reason for me to use bower is to have the dependencies only relying on your server and not an external CDN. Depending on what you do, that is something you'll want. Another advantage to this approach is you'll be able to also play with the files, e.g group them, minify with the tools you want, debug with the full source available or only use parts of the libraries. Also for offline development it's a bliss (on a laptop on the go for instance). You can do all of this by checkout each project individually and manage them yourself, but it's so much easier to just use hower.
- csixty4 12y ago
  > Or is it something to do with hosting your own copies of the libraries instead of a CDN (I thought this was frowned upon) I rarely use CDN copies of scripts for work projects. When Google first set up their CDN for jQuery, I used it on a client's custom e-commerce system. Client called us up and SCREAMED at our development manager because he was getting a warning that the admin section of his brand new site was insecure. Google was using an invalid SSL cert for the CDN's domain. It was completely out of our control. But that's the problem -- what gets served up is completely out of your control. It could have a bad/missing SSL cert. The file could go missing. Or it could be replaced with malware. It's not worth the couple milliseconds you're going to save.
- tejas-manohar 12y ago
  Updates, dependencies, offline development, etc. Not really a node.js thing (though bower itself can be installed via npm), it's specifically targeting front-end development. The debate over CDN vs. local is debated on all levels. Usually CDN is faster due to cached files, but what I consider the "best" approach is to use a CDN for most everything with local fallback (yes, you can use bower packages for the fallback if you please). Check the below linked poll out... http://css-tricks.com/poll-results-cdn-or-local/ http://css-tricks.com/poll-results-cdn-or-local/
- rezistik 12y ago
  It depends on which libraries you are using. Sure if you need jQuery and maybe another plug in that's fine, you're at 3 files to be loaded then. 2 from cdn, the jquery and plugin, plus one from your server. For a web application however it's likely to contain many many more resources, backbone, marionette, jquery, handlebars. Those aren't great examples because NPM handles those just fine, and the discussion is concerning bower. NPM billed itself as javascript primarily and never tried to sell itself to front end developers. Not terribly hard, it was definitely for node development. It was almost literally a branding issue. I think another big problem was the continued separation of concerns employed by most node developers. They tend to keep their front end/client side code in one directory bunched up together such as `/assets` or `/client` and then use the the rest of the project structure for their models directory, controllers, etc. A real back end system requires this complex set up while there has been a long trend of front end being as light weight as possible while providing as interactive an experience as possible. With the continued rise of SPA's though the front end is now easily as complex as the back end, and in fact shares a lot of the same logic. With build tools like GulpJS it's possible to fix this structural issue and now keep your code more logically grouped by function, group all of your users files, all of your messages files together and then concatenate and minify your client into a single file for production. Anyways, so for a SPA you'll end up with a ton more dependencies, both css and js files. Bower billed itself for this purpose. Their branding and singular purpose made thing far easier. I also prefer bower because it has a significantly better search and sort method in comparison to npm.
limsup 12y ago
has anything changed other than the site design?
- quarterto 12y ago
  Actually, pretty much everything except the site design has changed: http://web.archive.org/web/20140517000522/http://bower.io/ http://web.archive.org/web/20140517000522/http://bower.io/
  - callum85 12y ago
    Pretty much everything? What exactly? I can't see much different
    - quarterto 12y ago
      They've restructured the entire site. Before, it was a single page; now, there are separate pages for configuration, API, etc..
    - recursive 12y ago
      Off the top of my head, this is new: "Bower requires Node and npm and Git." I remember thinking it was very odd that the old version of the site said that bower had no dependencies.
edwinvdgraaf 12y ago
What are reasons to use bower over NPM? I know that bower mainly focusses on front-end libraries (such as jQuery or Bootstrap). But does it offer functionality NPM doesn't have?
- hcho 12y ago
  bower manages your script tags in the html file. It also supports partial inclusion of libraries.
  - quarterto 12y ago
    > bower manages your script tags in the html file no, it doesn't. bower has nothing to do with module loading.
    - hcho 12y ago
      you are technically right. It's the grunt bowerInstall.
      - abritishguy 12y ago
        FTFY:you are right
- dmak 12y ago
  I have generally only seen bower used for client side web. Its very useful when you are running a frontend framework like Angular or ember.
- Touche 12y ago
  Bower installs dependencies in a flat folder structure, whereas NPM nests them. This makes it much easier to use Bower with a client-side module loader. Bower is also (easily) configurable where bower_components will be, whereas I don't think NPM is as easily.
deleted 12y ago
[deleted]
brian_c 12y ago
In a fair world, the time and energy that went into Bower would have been spent making npm just a little bit better for front-end stuff. `npm dedupe` is halfway there. Now I have to deal with two arbitrary sources of dependencies.
- GlennS 12y ago
  Couldn't you say the same thing about time spent on npm which could have gone into apt or yum?
  - rblatz 12y ago
    Not all node platforms run apt/yum. Having a package manager for your platform makes sense.
  - pstop 12y ago
    The problem I have with apt, yum, etc... is that the packages for development are so old that you're going to be compiling from source and managing your own updates, which is exactly the problem a good package manager should solve.
    - stephendicato 12y ago
      The big difference is that packages that land in the official apt repositories have been heavily tested by the apt repository maintainers. Anyone can push a package to PyPI for example. There is a clear trade off between using packages from apt/yum and your toolchain's package managers. In practice, I do find it much easier to pin dependencies and install from my toolchain's package manager (pip/PyPI).
- recursive 12y ago
  Why do you have to deal with bower? I don't.
  - linhmtran168 12y ago
    A lot of frontend libraries are not on npm.
tbranyen 12y ago
I've always thought of Bower as an easier-to-use Git submodule manager.
- ciniglio 12y ago
  That's an interesting idea. Does it work well with non-js repositories?
  - ceejayoz 12y ago
    Yes. Twitter Bootstrap is a popular Bower repo.
saosebastiao 12y ago
So I use a package manager (apt) to install a package manager (npm) to install a package manager (bower). Am I going to blow my stack soon?
modarts 12y ago
Why would I use bower over npm with browserify? Seems like a large step back.

63 points by rayshan 12y ago

Is this http://stackoverflow.com/questions/20279792/how-to-update-bower-json-with-installed-packages http://stackoverflow.com/questions/20279792/how-to-update-bo... still the case? e.g. I forgot to install a package with --save and I want to update bower.json. With pip I just do pip freeze > requirements.txt

boredprogrammer 12y ago

Possibly a stupid question, but ... Can anybody explain to me the use case for Bower/Yeoman? Whenever I am adding javascript to a website I just use a cdn such as http://cdnjs.com/ http://cdnjs.com/ Why would I use Bower instead of this? Is it more of a node.js thing? Or is it something to do with hosting your own copies of the libraries instead of a CDN (I thought this was frowned upon)

sehr 12y ago
Bower has tons of packages that cdnjs doesn't, and includes CSS focused packages and the like. Yeoman is just a scaffolding tool, with application specific generators e.g. angular, backbone etc.. Generators also typically come with a build task, which creates a deployment ready folder all minified & concatted up for your enjoyment.
rcsorensen 12y ago
Some of the reasons you'd want to use Bower: * Your external libraries have dependencies, and having dependencies managed for you is a good thing. * The external components you're using include both JS and CSS, and need to be served separately. * Because you love your users, and want to concatenate your javascript and CSS to single files before serving it out to your users. * Because you're including components that expose SASS mixins you want to use inside your existing code. The hosted vs serving your own libraries is a complicated topic, but the basic answer comes down to "the less requests your clients have to make, the faster things will be".
- city41 12y ago
  concatting JS libraries into your own JS payload is a debatable practice. If it's a popular library, the user likely has it cached already and so the request to get it takes a few milliseconds. Where as your own JS payload will change with every release, forcing them to always re-download the same library code.
quarterto 12y ago
Dependencies. For example, Backbone depends on Underscore, and simply writing <script src="underscore.js"/><script src="backbone.js"/> encodes nothing about that fact. There's nothing stopping you updating Backbone to say a 2.0 that requires features in Underscore 2.0, but forgetting to update Underscore. On the other hand, bower update backbone will see dependencies: {"underscore": "^2.0"} in bower.js and update Underscore as well.
- sphildreth 12y ago
  Is it something like NuGet for .NET packages but for Javascript? Does that mean that an ASP.NET MVC application using NuGet wouldn't really have any "need" for Bower?
  - atonse 12y ago
    It's similar but for you to not "need" bower but get the same from NuGet, you'd have to make sure that every JS library you need is on NuGet.
lvillani 12y ago
Off-line applications. We are developing a cross platform mobile application which has to run locally on user's tablets. Reaching out to a CDN to fetch dependencies is out of the question. We are basically using HTML5 in place of Qt5 here. However, we found several horrible, horrible bugs with Bower randomly failing to install dependencies (such as https://github.com/bower/bower/issues/933 https://github.com/bower/bower/issues/933), which is now thankfully fixed. We are also investigating Browserify, so might switch to use NPM also for (some) client side dependencies.
- Bahamut 12y ago
  I personally reported https://github.com/bower/bower/issues/1019 https://github.com/bower/bower/issues/1019 - that was an awful bug to deal with, and it caused us at work to put everything in bower_components into source control to guard against it in the future. To the Bower team's credit though, once they fixed the issue, I have had smooth sailing since.
lucideer 12y ago
They are generally recommended, though are also the occasional arguments against the use of CDNs http://zoompf.com/blog/2010/01/should-you-use-javascript-library-cdns http://zoompf.com/blog/2010/01/should-you-use-javascript-lib...
hrktb 12y ago
One of the reason for me to use bower is to have the dependencies only relying on your server and not an external CDN. Depending on what you do, that is something you'll want. Another advantage to this approach is you'll be able to also play with the files, e.g group them, minify with the tools you want, debug with the full source available or only use parts of the libraries. Also for offline development it's a bliss (on a laptop on the go for instance). You can do all of this by checkout each project individually and manage them yourself, but it's so much easier to just use hower.
csixty4 12y ago
> Or is it something to do with hosting your own copies of the libraries instead of a CDN (I thought this was frowned upon) I rarely use CDN copies of scripts for work projects. When Google first set up their CDN for jQuery, I used it on a client's custom e-commerce system. Client called us up and SCREAMED at our development manager because he was getting a warning that the admin section of his brand new site was insecure. Google was using an invalid SSL cert for the CDN's domain. It was completely out of our control. But that's the problem -- what gets served up is completely out of your control. It could have a bad/missing SSL cert. The file could go missing. Or it could be replaced with malware. It's not worth the couple milliseconds you're going to save.
tejas-manohar 12y ago
Updates, dependencies, offline development, etc. Not really a node.js thing (though bower itself can be installed via npm), it's specifically targeting front-end development. The debate over CDN vs. local is debated on all levels. Usually CDN is faster due to cached files, but what I consider the "best" approach is to use a CDN for most everything with local fallback (yes, you can use bower packages for the fallback if you please). Check the below linked poll out... http://css-tricks.com/poll-results-cdn-or-local/ http://css-tricks.com/poll-results-cdn-or-local/
rezistik 12y ago
It depends on which libraries you are using. Sure if you need jQuery and maybe another plug in that's fine, you're at 3 files to be loaded then. 2 from cdn, the jquery and plugin, plus one from your server. For a web application however it's likely to contain many many more resources, backbone, marionette, jquery, handlebars. Those aren't great examples because NPM handles those just fine, and the discussion is concerning bower. NPM billed itself as javascript primarily and never tried to sell itself to front end developers. Not terribly hard, it was definitely for node development. It was almost literally a branding issue. I think another big problem was the continued separation of concerns employed by most node developers. They tend to keep their front end/client side code in one directory bunched up together such as `/assets` or `/client` and then use the the rest of the project structure for their models directory, controllers, etc. A real back end system requires this complex set up while there has been a long trend of front end being as light weight as possible while providing as interactive an experience as possible. With the continued rise of SPA's though the front end is now easily as complex as the back end, and in fact shares a lot of the same logic. With build tools like GulpJS it's possible to fix this structural issue and now keep your code more logically grouped by function, group all of your users files, all of your messages files together and then concatenate and minify your client into a single file for production. Anyways, so for a SPA you'll end up with a ton more dependencies, both css and js files. Bower billed itself for this purpose. Their branding and singular purpose made thing far easier. I also prefer bower because it has a significantly better search and sort method in comparison to npm.

limsup 12y ago

has anything changed other than the site design?

quarterto 12y ago
Actually, pretty much everything except the site design has changed: http://web.archive.org/web/20140517000522/http://bower.io/ http://web.archive.org/web/20140517000522/http://bower.io/
- callum85 12y ago
  Pretty much everything? What exactly? I can't see much different
  - quarterto 12y ago
    They've restructured the entire site. Before, it was a single page; now, there are separate pages for configuration, API, etc..
  - recursive 12y ago
    Off the top of my head, this is new: "Bower requires Node and npm and Git." I remember thinking it was very odd that the old version of the site said that bower had no dependencies.

edwinvdgraaf 12y ago

What are reasons to use bower over NPM? I know that bower mainly focusses on front-end libraries (such as jQuery or Bootstrap). But does it offer functionality NPM doesn't have?

hcho 12y ago
bower manages your script tags in the html file. It also supports partial inclusion of libraries.
- quarterto 12y ago
  > bower manages your script tags in the html file no, it doesn't. bower has nothing to do with module loading.
  - hcho 12y ago
    you are technically right. It's the grunt bowerInstall.
    - abritishguy 12y ago
      FTFY:you are right
dmak 12y ago
I have generally only seen bower used for client side web. Its very useful when you are running a frontend framework like Angular or ember.
Touche 12y ago
Bower installs dependencies in a flat folder structure, whereas NPM nests them. This makes it much easier to use Bower with a client-side module loader. Bower is also (easily) configurable where bower_components will be, whereas I don't think NPM is as easily.

deleted 12y ago

[deleted]

brian_c 12y ago

In a fair world, the time and energy that went into Bower would have been spent making npm just a little bit better for front-end stuff. `npm dedupe` is halfway there. Now I have to deal with two arbitrary sources of dependencies.

GlennS 12y ago
Couldn't you say the same thing about time spent on npm which could have gone into apt or yum?
- rblatz 12y ago
  Not all node platforms run apt/yum. Having a package manager for your platform makes sense.
- pstop 12y ago
  The problem I have with apt, yum, etc... is that the packages for development are so old that you're going to be compiling from source and managing your own updates, which is exactly the problem a good package manager should solve.
  - stephendicato 12y ago
    The big difference is that packages that land in the official apt repositories have been heavily tested by the apt repository maintainers. Anyone can push a package to PyPI for example. There is a clear trade off between using packages from apt/yum and your toolchain's package managers. In practice, I do find it much easier to pin dependencies and install from my toolchain's package manager (pip/PyPI).
recursive 12y ago
Why do you have to deal with bower? I don't.
- linhmtran168 12y ago
  A lot of frontend libraries are not on npm.

tbranyen 12y ago

I've always thought of Bower as an easier-to-use Git submodule manager.

ciniglio 12y ago
That's an interesting idea. Does it work well with non-js repositories?
- ceejayoz 12y ago
  Yes. Twitter Bootstrap is a popular Bower repo.

saosebastiao 12y ago

So I use a package manager (apt) to install a package manager (npm) to install a package manager (bower). Am I going to blow my stack soon?

modarts 12y ago

Why would I use bower over npm with browserify? Seems like a large step back.