Bower and component are more like package managers. GP is talking about a library of re-usable user interface components.

Unfortunately, my best attempt at an analogy is Visual Basic controls, which might not be a great precedent, but the idea itself is a good one.

Well they just edited their initial post to specifically use a `bower` command rather the theoretical `react` command, so I'm not sure. What would the different be between your VB-style controls and something like this confirmation popup:

https://github.com/component/confirmation-popover

React has a much richer notion of what a 'component' is. To date, most JavaScript libraries lack shared assumptions about how you will build your UI. jQuery plugins make only the extremely minimal assumption that you will apply the plugin to some DOM element - beyond that, how the plugins behave, how they manage their state, properties etc. is not defined by any standards or even assumptions.

The confirmation popover you link to is a good example. It's a black-box component which exposes a fairly minimal interface. The constructor for this component works like this:

  new ConfirmationPopover(msg, [title])

To attach the popover to an element you need to do:

  popover.show(el, [fn])

However, if we take another component from the same library, the swipe component[1], we see different conventions. Its constructor:

  Swipe(el)

It also has a show method which takes totally different parameters:

  .show(i, [ms], [options])

This is why I describe such systems as package managers or library managers - they're just a way of importing and exporting code and don't do anything to aid reuse. They're not particularly likely to play well together, lack standard interfaces and are almost certainly not composable in any meaningful way.

React components are different because React defines some standard details of how components behave, how to extend them, how to inspect them and pass data back and forth. Components can contain other components, and all components have a relative place in the render tree. This makes possible standard developer tools that can be used to observe and inspect components in a DOM-like tree structure[2].

So, you could certainly use bower to distribute React components. What's different about React isn't how the code is distributed but the fact that you can have expectations about how, say, a React photo gallery component would behave that you would not get from some other JS library.

[1] https://github.com/component/swipe [2] http://facebook.github.io/react/blog/2014/01/02/react-chrome...

Heh... was just in the process of updating my comment with Bower when you replied. I agree that this could work with Bower as the package manager.

However, it would be more convenient if there was a distinction between packages that are designed to be UI components, and packages like AJAX libraries, async, and other logic libraries, which are a better fit for bower.

Distributing the UI components via bower is doable, but it wouldn't be nearly as nice as a dedicated component ecosystem where it is easy to search and discover relevant React components.

Not even if bower let you search by component type or some kind of category or tag?

The best interface for a react UI component repository would be something that had information like:

    * A picture of what the component looks like
    * How large the component is in KB
    * Which CSS frameworks it requires or supports
    * Cross browser support information

Bower is a very simple package manager right now with little information about the package beyond its name, a line of descriptive text, and a link to the Github.

Overall the experience would be better for React devs to develop a customized package manager interface well suited to the type of packages being delivered.

Of course there is nothing stopping UI component creators from distributing their components on both Bower and a React specific package manager, but I think for purposes of discoverability a React specific one would be better suited.