
Bower: A package manager for the web, from Twitter - exogen
http://twitter.github.com/bower/#
======
stdbrouw
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>) 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.

------
streptomycin
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
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
I really like browserify, but what do you see as the drawbacks and challenges
to get more adoption, especially among non-Node.js developers?

------
ricardobeat
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
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>

------
pkhamre
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
Yeah, the system package manager is trying to do too much.

~~~
wilmoore
✓

------
aeosynth

        $ bower lookup jquery
        jquery git://github.com/components/jquery.git
    

Web link: <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
Actually, the web URL you're looking for is
<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.

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

~~~
tjholowaychuk
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

------
koide
Amazing how timing (and luck?) matters on whether a submission gets to the top
or not.

<http://news.ycombinator.com/item?id=4487221>

Also of note: the algorithm to check URL was already submitted is easily
fooled.

~~~
exogen
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.

------
Garbage
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>

~~~
hinathan
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
I didn't even realize this until I saw your comment. Definitely could use a
"scroll for more" or an arrow or _something_.

------
kreutz
Relevant: <http://tjholowaychuk.com/post/27984551477/components>

------
diggan
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
or even apt-cache search jquery

------
dreamdu5t
What's different about this than the official component project?

<https://github.com/component/component>

<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...

~~~
kahlil
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.

~~~
dreamdu5t
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.

~~~
benatkin
His name is listed in the README. I think the next level of recognition would
have been for him to contribute code, and for whatever reason, that didn't
happen. It could be because TJ is busy doing other things, because development
was closed, or because they disagreed on things, or a combination of reasons.

I looked at the source and found that the initial public commit contains 79
files.

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

~~~
wilmoore
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.

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

~~~
golden_apples
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.

