7 ms·

Bower: A package manager for the web, from Twitter

123 points by exogen 14y ago

aeosynth 14y ago
$ bower lookup jquery jquery git://github.com/components/jquery.git Web link: https://github.com/component/jquery https://github.com/component/jquery Since there's no authentication, the bower jquery package will always point to this url, which is not officially associated with jquery.
- dylanpyle 14y ago
  Actually, the web URL you're looking for is https://github.com/components/jquery https://github.com/components/jquery (note the "components" vs "component"), which does seem to be officially associated based on the members of the "components" organization.
- alexchamberlain 14y ago
  This will lead to the same signing processes of other package managers, such as `pacman`.
streptomycin 14y ago
Does anyone think this can finally be the tool to bring sane package management to client side JavaScript development? I'm hesitant to use any of the existing tools because none of them support all the libraries I use, so I'd end up doing stuff manually anyway, and I don't have any confidence that any of them will keep working in the long term.
- substack 14y ago
  No. If anything, it will probably just get even more fragmented before the situation gets better. As we understand the features and architectures of package management systems better it becomes even easier to write package managers. This is a good thing long-term because we can more thoroughly explore the solution space before settling on a few "winners". However, at the same time package repositories are fundamentally a network effects problem because packages depend upon other packages, so the repository with the most packages offers the most benefit for each additional package because new packages can build on everything that already exists instead of bundling that functionality themselves. The reason why I am skeptical of new entrants into the javascript package management arena is that there is already a package manager with over 14k packages and a vibrant community that is producing packages at a very high rate: npm. npm might not be the best package manager as-is for browser development, but tools like browserify (disclaimer: I wrote browserify), ender, or many others can let your browser code use much of the value that has already been created for npm, even though npm is primarily about node.js packages. A surprising number of modules written for node will just work in tools like browserify. Any upstart package systems would be wise to have a clear and simple path for unlocking the value created in the node community because there is too much value being created in npm to ignore. Whether that path involves adding fields to the package.json, tools to bridge the gap between package repositories, fancy in-browser trickery or compile steps remains an open question but it would be really pointless to require people to publish their modules that they've already put on npm to buy in to yet another package system, especially since there seems to be a new package manager every month lately.
  - jacobr 14y ago
    I really like browserify, but what do you see as the drawbacks and challenges to get more adoption, especially among non-Node.js developers?
  - vicapow 14y ago
    but dep management in the browser is still so different then the npm workflow. it's not just code you have to worry about, it's css/html/static resources
- jhspaybar 14y ago
  Well, RequireJS is pretty solid for client side package management. With solid config files you can build out large client side applications that grab dependencies asynchronously, and it DOES work with everything.
  - substack 14y ago
    and it DOES work with everything ... so long as you wrap all the files in the particular variant of define() function that works with requirejs (but not with other competing AMD function signatures). And then you might want to use some modules written for commonjs or node with `exports`, so you'll need a tool to transform those files. And then you'll probably want to compile the application into a single javascript bundle in production for performance. I'm not saying bower is any better in any of these respects, just that everything is terrible.
    - Zr40 14y ago
      Nope, RequireJS can load any kind of Javascript dependency, even if it doesn't use the AMD format. You can even specify dependencies for non-AMD scripts in the configuration object.[0] As for define(), there's only one AMD method signature: define([[name,] deps,] fn). Any loader that does not accept this signature cannot legitimately call itself an AMD loader. [0] http://requirejs.org/docs/api.html#config-shim http://requirejs.org/docs/api.html#config-shim
  - Zr40 14y ago
    RequireJS manages load dependencies, not packages. It does not install and update them.
- wilmoore 14y ago
  For the libraries that do not conform to CJS or AMD, most loaders support a "shim" configuration: * http://requirejs.org/docs/api.html#config-shim http://requirejs.org/docs/api.html#config-shim To load a library that uses Node/CJS modules: * https://github.com/requirejs/cajon#why https://github.com/requirejs/cajon#why - or - * https://github.com/linkedin/inject#writing-commonjs-compliant-modules https://github.com/linkedin/inject#writing-commonjs-complian...
kreutz 14y ago
Relevant: http://tjholowaychuk.com/post/27984551477/components http://tjholowaychuk.com/post/27984551477/components
Garbage 14y ago
The site itself doesn't give much of the introduction or what Bower is all about. Github page is much better - https://github.com/twitter/bower https://github.com/twitter/bower
- ricardobeat 14y ago
  The site is an exact copy of the README.
- hinathan 14y ago
  I thought so too but then scrolled down more — the design of the page made me think it was just a splash but there's tons of details underneath the big header. :/
  - mediocregopher 14y ago
    I didn't even realize this until I saw your comment. Definitely could use a "scroll for more" or an arrow or something.
  - hboon 14y ago
    I didn't realise you can scroll down. Whatever happened to simple UI affordance.
ricardobeat 14y ago
Couldn't it extend package.json instead of using a separate file? Something like "clientDependencies": [...] would be nice - most projects I work on these days already have a package.json file. The ./components path could be configurable too.
- wilmoore 14y ago
  Other package managers seem to be pulling this off just fine. I am happy to go either way though: http://git.io/_ZWfVA#configuration-file http://git.io/_ZWfVA#configuration-file
koide 14y ago
Amazing how timing (and luck?) matters on whether a submission gets to the top or not. http://news.ycombinator.com/item?id=4487221 http://news.ycombinator.com/item?id=4487221 Also of note: the algorithm to check URL was already submitted is easily fooled.
- exogen 14y ago
  Indeed. I was disappointed that the two prior submissions by other folks (the other was of the direct repository page) both had 0 comments. Figured I would resubmit it anyway during a more active time, given that it's genuinely worthy of discussion.
stdbrouw 14y ago
An unopinionated approach like Bower is probably what the (client-side) JavaScript ecosystem needs, but all the same, what's lacking here is a philosophy. What I mean: if I'm just using jQuery and two or three other JavaScript libraries, downloading those manually isn't a big ordeal, they're single files, already minified for my convenience, available on a public CDN if I want to use that in production, they usually have no dependencies themselves and I'm only inclined to update them to newer version if something doesn't work, which is hardly ever. All of these things make package management for the server a godsend but package management for the client sort of... meh. Ender, on the other hand (and for all its flaws) does a good job of explaining how you can use it to approach libraries for the client more like you'd approach them on the server: tiny packages that do one thing well and that don't reinvent the wheel but where applicable build on existing libraries. Now that sounds like something I can get behind. Similarly, if you read TJ Holowaychuk's ideas on package management in the browser (linked to by kreutz below, or at http://tjholowaychuk.com/post/27984551477/components http://tjholowaychuk.com/post/27984551477/components) then you start to get an idea of, yeah, maybe it'd be cool to have these packages that are little bundles of HTML, CSS and JavaScript and together they make up a single interface element or something of the sort -- included in your project as-needed. Fascinating. Bower, by comparison, sounds like "a thing that downloads things for me." It might just be the copy (rather than the idea) and maybe it's the tool we need to do what someone like TJ envisions, but it's not clicking for me right now.
dreamdu5t 14y ago
What's different about this than the official component project? https://github.com/component/component https://github.com/component/component https://github.com/component/spec/wiki https://github.com/component/spec/wiki Bower seems like a blatant ripoff. Twitter Engineering doesn't even mention the component project or spec on the Bower page at all...
- najamkhn 14y ago
  Well, one difference I can see is component actually works. Bower doesn't work with npm 1.1.16 atleast.
- kahlil 14y ago
  The difference is that the component project depends on Github. Bower is much more low-level and unopinionated. All you need is a Git path.
  - jacobr 14y ago
    Surely that could have been a pull request to Component instead?
    - kahlil 14y ago
      I don't think so, because it is a different philosophy and as they say in the FAQ > Bower is a lower level component then Jam, Volo, or Ender. These managers could consume Bower as a dependency. I think it is actually an approach that is more useful and makes more sense than Volo, Components etc. because of it's low-levelness.
  - dreamdu5t 14y ago
    That's because without using GitHub, Bower's packages aren't namespaced. This was something discussed at length on the component spec github. It sure feels like Twitter is avoiding giving credit where credit is due. No links to the component.json spec or any mention of TJ Holowaychuk's component feels smarmy to me.
diggan 14y ago
I think I'll stick with wget and git clone for this. Feels kind of unnecessary to use a external tool for something this simple.
- fourstar 14y ago
  or even apt-cache search jquery
oatmealsnap 14y ago
Trying to get back onto the developer world's good side?
- golden_apples 14y ago
  As part of the 99% of developers who work for other people, I resent troll-bait comments like this. Twitter, in addition to being a genuinely interesting social phenomenon, has always posed technical challenges that were sufficiently interesting to attract some top-notch people. Give them the respect of judging them by their technical work, and not their employer's latest unpopular business decision.
  - wilmoore 14y ago
    ✓
pkhamre 14y ago
So first I can install node and npm through my system package managed, then I can install bower through the node package manager, then I can finally install libraries with the bower package manager. Something is wrong here.
- regularfry 14y ago
  Yeah, the system package manager is trying to do too much.
  - wilmoore 14y ago
    ✓
necenzurat 14y ago
at least building failed http://travis-ci.org/#!/twitter/bower http://travis-ci.org/#!/twitter/bower
- wilmoore 14y ago
  The build is failing because there are a lot of moving parts at this early stage regarding the internals; however, the basics from a usage standpoint work just fine right now. In other words, the build failing is not ideal; but don't get too hung up on it right now.
MatthewPhillips 14y ago
NPM already provides this functionality and Isaacs has said that people should use NPM for client-side packages.
- aeosynth 14y ago
  > Isaacs has said that people should use NPM for client-side packages. Link?
- tjholowaychuk 14y ago
  I'd definitely defend bower here, there's no reason to use npm for this, it just makes things confusing and ambiguous, and leads to stupid suffices or prefixes like the several "-component" modules I have

123 points by exogen 14y ago

$ bower lookup jquery jquery git://github.com/components/jquery.git Web link: https://github.com/component/jquery https://github.com/component/jquery Since there's no authentication, the bower jquery package will always point to this url, which is not officially associated with jquery.

dylanpyle 14y ago
Actually, the web URL you're looking for is https://github.com/components/jquery https://github.com/components/jquery (note the "components" vs "component"), which does seem to be officially associated based on the members of the "components" organization.
alexchamberlain 14y ago
This will lead to the same signing processes of other package managers, such as `pacman`.

streptomycin 14y ago

Does anyone think this can finally be the tool to bring sane package management to client side JavaScript development? I'm hesitant to use any of the existing tools because none of them support all the libraries I use, so I'd end up doing stuff manually anyway, and I don't have any confidence that any of them will keep working in the long term.

substack 14y ago
No. If anything, it will probably just get even more fragmented before the situation gets better. As we understand the features and architectures of package management systems better it becomes even easier to write package managers. This is a good thing long-term because we can more thoroughly explore the solution space before settling on a few "winners". However, at the same time package repositories are fundamentally a network effects problem because packages depend upon other packages, so the repository with the most packages offers the most benefit for each additional package because new packages can build on everything that already exists instead of bundling that functionality themselves. The reason why I am skeptical of new entrants into the javascript package management arena is that there is already a package manager with over 14k packages and a vibrant community that is producing packages at a very high rate: npm. npm might not be the best package manager as-is for browser development, but tools like browserify (disclaimer: I wrote browserify), ender, or many others can let your browser code use much of the value that has already been created for npm, even though npm is primarily about node.js packages. A surprising number of modules written for node will just work in tools like browserify. Any upstart package systems would be wise to have a clear and simple path for unlocking the value created in the node community because there is too much value being created in npm to ignore. Whether that path involves adding fields to the package.json, tools to bridge the gap between package repositories, fancy in-browser trickery or compile steps remains an open question but it would be really pointless to require people to publish their modules that they've already put on npm to buy in to yet another package system, especially since there seems to be a new package manager every month lately.
- jacobr 14y ago
  I really like browserify, but what do you see as the drawbacks and challenges to get more adoption, especially among non-Node.js developers?
- vicapow 14y ago
  but dep management in the browser is still so different then the npm workflow. it's not just code you have to worry about, it's css/html/static resources
jhspaybar 14y ago
Well, RequireJS is pretty solid for client side package management. With solid config files you can build out large client side applications that grab dependencies asynchronously, and it DOES work with everything.
- substack 14y ago
  and it DOES work with everything ... so long as you wrap all the files in the particular variant of define() function that works with requirejs (but not with other competing AMD function signatures). And then you might want to use some modules written for commonjs or node with `exports`, so you'll need a tool to transform those files. And then you'll probably want to compile the application into a single javascript bundle in production for performance. I'm not saying bower is any better in any of these respects, just that everything is terrible.
  - Zr40 14y ago
    Nope, RequireJS can load any kind of Javascript dependency, even if it doesn't use the AMD format. You can even specify dependencies for non-AMD scripts in the configuration object.[0] As for define(), there's only one AMD method signature: define([[name,] deps,] fn). Any loader that does not accept this signature cannot legitimately call itself an AMD loader. [0] http://requirejs.org/docs/api.html#config-shim http://requirejs.org/docs/api.html#config-shim
- Zr40 14y ago
  RequireJS manages load dependencies, not packages. It does not install and update them.
wilmoore 14y ago
For the libraries that do not conform to CJS or AMD, most loaders support a "shim" configuration: * http://requirejs.org/docs/api.html#config-shim http://requirejs.org/docs/api.html#config-shim To load a library that uses Node/CJS modules: * https://github.com/requirejs/cajon#why https://github.com/requirejs/cajon#why - or - * https://github.com/linkedin/inject#writing-commonjs-compliant-modules https://github.com/linkedin/inject#writing-commonjs-complian...

kreutz 14y ago

Relevant: http://tjholowaychuk.com/post/27984551477/components http://tjholowaychuk.com/post/27984551477/components

Garbage 14y ago

The site itself doesn't give much of the introduction or what Bower is all about. Github page is much better - https://github.com/twitter/bower https://github.com/twitter/bower

ricardobeat 14y ago
The site is an exact copy of the README.
hinathan 14y ago
I thought so too but then scrolled down more — the design of the page made me think it was just a splash but there's tons of details underneath the big header. :/
- mediocregopher 14y ago
  I didn't even realize this until I saw your comment. Definitely could use a "scroll for more" or an arrow or something.
- hboon 14y ago
  I didn't realise you can scroll down. Whatever happened to simple UI affordance.

ricardobeat 14y ago

Couldn't it extend package.json instead of using a separate file? Something like "clientDependencies": [...] would be nice - most projects I work on these days already have a package.json file. The ./components path could be configurable too.

wilmoore 14y ago
Other package managers seem to be pulling this off just fine. I am happy to go either way though: http://git.io/_ZWfVA#configuration-file http://git.io/_ZWfVA#configuration-file

koide 14y ago

Amazing how timing (and luck?) matters on whether a submission gets to the top or not. http://news.ycombinator.com/item?id=4487221 http://news.ycombinator.com/item?id=4487221 Also of note: the algorithm to check URL was already submitted is easily fooled.

exogen 14y ago
Indeed. I was disappointed that the two prior submissions by other folks (the other was of the direct repository page) both had 0 comments. Figured I would resubmit it anyway during a more active time, given that it's genuinely worthy of discussion.

stdbrouw 14y ago

An unopinionated approach like Bower is probably what the (client-side) JavaScript ecosystem needs, but all the same, what's lacking here is a philosophy. What I mean: if I'm just using jQuery and two or three other JavaScript libraries, downloading those manually isn't a big ordeal, they're single files, already minified for my convenience, available on a public CDN if I want to use that in production, they usually have no dependencies themselves and I'm only inclined to update them to newer version if something doesn't work, which is hardly ever. All of these things make package management for the server a godsend but package management for the client sort of... meh. Ender, on the other hand (and for all its flaws) does a good job of explaining how you can use it to approach libraries for the client more like you'd approach them on the server: tiny packages that do one thing well and that don't reinvent the wheel but where applicable build on existing libraries. Now that sounds like something I can get behind. Similarly, if you read TJ Holowaychuk's ideas on package management in the browser (linked to by kreutz below, or at http://tjholowaychuk.com/post/27984551477/components http://tjholowaychuk.com/post/27984551477/components) then you start to get an idea of, yeah, maybe it'd be cool to have these packages that are little bundles of HTML, CSS and JavaScript and together they make up a single interface element or something of the sort -- included in your project as-needed. Fascinating. Bower, by comparison, sounds like "a thing that downloads things for me." It might just be the copy (rather than the idea) and maybe it's the tool we need to do what someone like TJ envisions, but it's not clicking for me right now.

dreamdu5t 14y ago

What's different about this than the official component project? https://github.com/component/component https://github.com/component/component https://github.com/component/spec/wiki https://github.com/component/spec/wiki Bower seems like a blatant ripoff. Twitter Engineering doesn't even mention the component project or spec on the Bower page at all...

najamkhn 14y ago
Well, one difference I can see is component actually works. Bower doesn't work with npm 1.1.16 atleast.
kahlil 14y ago
The difference is that the component project depends on Github. Bower is much more low-level and unopinionated. All you need is a Git path.
- jacobr 14y ago
  Surely that could have been a pull request to Component instead?
  - kahlil 14y ago
    I don't think so, because it is a different philosophy and as they say in the FAQ > Bower is a lower level component then Jam, Volo, or Ender. These managers could consume Bower as a dependency. I think it is actually an approach that is more useful and makes more sense than Volo, Components etc. because of it's low-levelness.
- dreamdu5t 14y ago
  That's because without using GitHub, Bower's packages aren't namespaced. This was something discussed at length on the component spec github. It sure feels like Twitter is avoiding giving credit where credit is due. No links to the component.json spec or any mention of TJ Holowaychuk's component feels smarmy to me.

diggan 14y ago

I think I'll stick with wget and git clone for this. Feels kind of unnecessary to use a external tool for something this simple.

fourstar 14y ago
or even apt-cache search jquery

oatmealsnap 14y ago

Trying to get back onto the developer world's good side?

golden_apples 14y ago
As part of the 99% of developers who work for other people, I resent troll-bait comments like this. Twitter, in addition to being a genuinely interesting social phenomenon, has always posed technical challenges that were sufficiently interesting to attract some top-notch people. Give them the respect of judging them by their technical work, and not their employer's latest unpopular business decision.
- wilmoore 14y ago
  ✓

pkhamre 14y ago

So first I can install node and npm through my system package managed, then I can install bower through the node package manager, then I can finally install libraries with the bower package manager. Something is wrong here.

regularfry 14y ago
Yeah, the system package manager is trying to do too much.
- wilmoore 14y ago
  ✓

necenzurat 14y ago

at least building failed http://travis-ci.org/#!/twitter/bower http://travis-ci.org/#!/twitter/bower

wilmoore 14y ago
The build is failing because there are a lot of moving parts at this early stage regarding the internals; however, the basics from a usage standpoint work just fine right now. In other words, the build failing is not ideal; but don't get too hung up on it right now.

MatthewPhillips 14y ago

NPM already provides this functionality and Isaacs has said that people should use NPM for client-side packages.

aeosynth 14y ago
> Isaacs has said that people should use NPM for client-side packages. Link?
tjholowaychuk 14y ago
I'd definitely defend bower here, there's no reason to use npm for this, it just makes things confusing and ambiguous, and leads to stupid suffices or prefixes like the several "-component" modules I have