The choice of a package manager is on a project by project basis. It's not as if you were required to use Bower or NPM to manage your dependancies.
Those are simply two tools used by the JS community to manage its dependancies. There are a lot[1] of them.
Where I work, everything was pushed by the back-end guys for a long time. This made the front-end developer dependant on them. With tools that use front-end languages (JavaScript), the front-end team is now free to experiment with package management and build systems (Grunt.js, Gulp.js). This made it so that we now have a very complex but quick and useful front-end workflow. We wouldn't have this if we had not freed the front end team dependancy on the back end team for builds, dependancies, etc.
[1]
https://www.npmjs.com/
http://bower.io/
http://duojs.org/
http://webpack.github.io/
http
componentjs
component
JavaScript2012–2016
componentjs / component · Archived
component
frontend package manager and build tool for modular web applications
19Distinct people
29Mentions
1Explicit recommenders
4.5KGitHub stars
What to know before exploring
What it is
frontend package manager and build tool for modular web applications
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
That's why I like the component (http://github.com/component/component) approach; keeping things to such a minimum feature wise that you can understand very easily what each…
hunvreus used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:56:56 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year29 dated mentions
Observed mentions: 2012-09-10 04:14:26 UTC to 2016-03-16 18:23:51 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 7 | 1 | 6 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 16 | 0 | 16 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
THIS PROJECT IS DEPRECATED
Component is not maintained anymore. See here #639 for more information.
You can still use the component registry on component.github.io to search for components.
All the components are not affected, because most of them also provide a package.json file.
The component.json files in these components are still kept to provide backwards compatibility for component and duo.
What now?
Consider to use another tool, which rely on the npm and the package.json standard:
webpack
jspm (supports npm and github endpoint)
browserify
Component is a vertically integrated frontend solution, handling everything from package management to the build process, handling everything including HTML, JS, CSS, images, and fonts. Think of it as an opinionated npm + browserify + rework-npm + grunt/gulp/broccoli all wrapped into component build.
Want to know more about Component? Visit the guide or view the comparison with other solutions.
If you're confused about component, components, componentjs, please read disambiguation
Component 1.0.0: Several
major new features have been added, some have been removed, and the project has been greatly reorganized. You may need to upgrade your
version of node and/or npm to avoid breakage. Please see the detailed changelog. Component 0.x will not be maintained anymore.
Installation
First, you need node v0.10+ installed. If you do not have it installed, visit node's download page.
With node installed, run the following command:
$ npm install -g component
Getting Started
Read this Getting Started guide to get a basic static site running very quickly with Component.
Note: the Component repo (this repo) has only documentation for Component 0.19. All of the documentation related to 1.0.0 will be handled in the guide repo.
Team
The team and organization have undergone massive changes. In summary, jonathanong stopped developing Component and started with normalize.io and the guys from segmentio switched to using duo. Component will still be maintained and updated while it is in use. You can read more about Duo.js and Component here.
The long story of Component and the changes that occurred in component can be found in Jonathan Ong's blog post "the future of component".
Development for component (maintenance and features) will be continued at the latest when latest browsers will support the ES6 modules and Web Components natively.
Contributors
Anton Wilhelm/@timaschew - maintainer
Keith Rosenberg/@netpoetica - maintainer
Trevor Gerhardt/@trevorgerhardt - maintainer
Clinton Wood - maintainer
Jason Kurht/@jasonkuhrt - maintainer
visionmedia/@tjholowaychuk - original author
jonathanong/@jongleberry - second-gen author
segmentio/segment.io - original sponsor
Read the full README on GitHubWhat Hacker News says
29 sourcesIn Grd – A CSS grid framework using Flexbox in 512 bytes gzipped
Backend: Django 1.7, Postgres, ElasticSearch, Redis.
Running on hetzner root servers in germany.
Frontend: component (https://github.com/componentjs/component) with a lot of custom components, no frameworks.
Using https://codeship.io/ for continuos integration/delivery
Stefan (ChatGrape)
In Intelligent chat that makes your team communication twice as fastWe've actually stopped using all pre-processor for everything we do for Segment.io[1] as well, and we're not beginners.
One of the biggest problems with them is that you immediately eliminate a huge portion of the people who are willing to contribute to your code if you select a pre-processor they aren't fond of. It's fine for app internals, but for sharing small[2] open-source[3] components[4] it's not a good idea—whether it's Sass or CoffeeScript or Jade or whatever.
The other problem with CSS pre-processors specifically is that they only work well with the monolithic app mindset. All of your CSS files inside the same `styles` folder, and all of them required by the "top of the monolith" `main.sass` file. Instead, using something like component[5] you get true dependency trees, so you don't have to go monolithic anymore. And trying to g
Read the rest
et Sass to work across a component-ized codebase is a real pain. Instead we use Myth[6] to "post-process" the built CSS.
Pre-processors are a leaky abstraction that comes back to bite you at random points the way all leaky abstractions do, and the ways are usually hard to foresee and thus hard to argue against when the benefits seems so clear.
[1]: https://segment.io
[2]: https://github.com/segmentio/toggle
[3]: https://github.com/segmentio/sheet
[4]: https://github.com/component/tip
[5]: https://github.com/component/component
[6]: http://myth.io
[Component](https://github.com/component/component). That is all.
In You might not need jQueryWow, Pace just blew my mind. You guys are releasing some really awesome stuff :) random other thing is would be sweet if these were component[1] friendly. (Dunno if you've already checked out component, but it is insanely good for front-end work.)
One pattern I picked up from reading TJ's code is the transparent constructor...
odometer(el).value(42);
...which I like using to make things that share a bit of state, but are still one-offs, a bit terser. (Coupled with avoiding options objects in general.) Achieved with the following:
function Odometer (el) {
if (!(this instanceof Odometer)) return new Odometer(el);
...
}
[1] https://github.com/component/component
In CountUp.jsExactly. If this kind of thing seems like your cup of tea check out component[1].
[1]: https://github.com/component/component
In Frameworkless JavaScriptSource code: https://github.com/max99x/guesshub/
Tech summary:
Built with Component[1] on the frontend. Backend is a github crawler and Bayesian Classifier for commit difficulty written in Python.
[1] https://github.com/component/component
In Show HN: GuessHub, our Github Game off entry. Guess a commit's repositoryRandom tangent: no need to make your own pubsub by the way. I figure you might be interested in component[1]. Makes writing libraries like oboe even easier because all of the little stuff is packaged up for you already, like emitter[2]. And then tons of the little helpers in oboe could easily be their own components and useable by others. Check out the full list[3].
[1]: https://github.com/component/component
[2]: https://github.com/component/emitter
[3]: https://github.com/component/component/wiki/Components
In Oboe.js: reacting to Ajax/Rest quicker by not waiting for it to finishTL;DR - Runnable only solves the small-picture problem. The best solution to the bigger-picture problem would make Runnable obsolete, because it's an anti-pattern to begin with.
---
The small version of the problem is that it's hard to find these snippets spread out across the internet, and then figure out if they work, and then copy-paste them into your program. Runnable solves the finding problem.
But the bigger version of the problem is that you shouldn't be copy-pasting these snippets into your codebase all the time, no matter how small they are. If they are useful enough that you find yourself looking them up often, or they are useful enough that they merited being posted on someone's blog, then they are useful enough to make into a package and share them properly. The node.js module system with npm gets extremely close to this goal.
Read the rest
And for client-side Javascript, component[1] does the same thing.
[1]: https://github.com/component/component
This is one place where other client-side Javascript package managers completely fall over. There are multiple different "types" of packages.
1. There are the typical "big libraries"
- jQuery
- superagent
- mocha
- d3
- backbone
- underscore
- angular.js
- etc.
2. Then there are "plugins", which are pretty big in scope themselves. They have to be big enough to be "plugin-worthy", influenced mostly by how annoying it has been to install plugins in the jQuery days, via copy and pasting them into your /libs folder. These are things like:
- backbone marionette
- jQuery waypoints
- underscore string
- any jquery plugin
- any angular plugin
- etc.
Most package managers, with that kind of thinking in mind, stop there, at the "big library" and "plugins" level. Bower has this shortcoming. It's great for quickly grabbing a copy of jQuery and a few jQuery plugins, but it doesn't actively encourage making smaller modules, which is critical to solving the big-picture need Runnable is trying to solve.
3. The third type of package are tiny modules that at first glance you are tempted to just stick right into your /utils folder. These are so small that in old-school package managers it would be more hassle just to make them into packages. (This is why it's crucial for package managers to have as little beaurocracy as possible by the way, to avoid that line of thinking.) These are things like:
- https://github.com/matthewmueller/uid
- https://github.com/yields/has-transitions
- https://github.com/pazguille/shuffle-array
- https://github.com/ianstormtaylor/to-snake-case
- https://github.com/jwerle/to-csv
- https://github.com/segmentio/canonical
Those tiny modules are the kinds of things you find StackOverflow answers for all the time. People keep having the same problems over and over again, and eventually the answers get voted up. Things like, "how do I convert a camel case string into a snake case string?".
As soon as you take those simple tasks and package them up in a way that installing them is as easy as:
$ component install ianstormtaylor/to-snake-case
Then you start to see crazy gains in productivity and quality of your code. When you do that you aren't copy-pasting some shoddy StackOverflow answer into your codebase, so that the onus is now on you to maintain it. Instead, you're just dependning on an open-source component that is packaged along with tests to make sure it continues to work. It's visible by tons of others, can be improved when bugs crop up, and you don't need to maintain yourself if you don't want to.
It's unfortunate that people still think they need monolithic libraries to get anything done on the client side. The node ecosystem showed this doesn't have to be the case. It becomes even more important on the client side to keep dependencies small.
My favourite ecosystem for client side development these days is component (https://github.com/component/component). It's similar in style to npm but faster and made for building apps from small modular pieces. It has a growing community and lots of modules already (https://github.com/component/component/wiki/Components).
In JSDB.io – A Database of JavaScript LibrariesI am pretty happy with this component registry... https://github.com/component/component/wiki/Components.
It also has a build tool written in node.js, http://github.com/component/component and has quite a large community surrounding it now.
In Show HN: UIBox – A Curated HTML, CSS, JS UI Component LibraryI'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
In Yeoman 1.0 ReleasedCan someone who is proficient in Angular explain to me why this many attributes are required on the form element itself:
<form ng-app="LoginApp" ng-controller="LoginController" ng-submit="login()">
This leads to my usual reaction to Angular: I'm sure they've got some things right, and I believe that data binding is the way to go, but holy shit that code is ugly and verbose. I've been using reactive.js [1] lately with Component [2] and its incredibly beautiful by contrast:
<form data-submit="login">
It uses data attributes, functions are handled for you automatically so you don't have to write the parens all the time, it will fallback to the model automatically if the view doesn't have a certain property. And the view is passed in so you don't need to specify what controller or "app" to search for, which seems way less tightly co
Read the rest
upled.
Really it's one of the most beautiful libraries I've ever seen. So why would I ever want to use Angular?
I'm honestly curious since I've heard so many good things about Angular. It seems like they need a few more designers who can code on the team--people who care about the user experience part of API design.
[1]: https://github.com/component/reactive
[2]: https://github.com/component/component
Nice, but I find ember.js with http://github.com/component/component more convenient.
In Announcing Charcoal, the easiest way to create Ember.js projectsThis all makes more sense in the context of TJ Holowaychuck's new Component package management tool (first link in the article). Component gives a sane structure to building small, modular js+css+html+assets components. https://github.com/component/component
In Media Queries are a HackShowing the 15 most recent of 29 sources. Enable JavaScript to search and browse every indexed mention.