4 ms·

Highly, highly, highly recommend Component. We've been using it for everything we do at Segment.io for the past year and it's completely changed the way we thin

Highly, highly, highly recommend Component. We've been using it for everything we do at Segment.io for the past year and it's completely changed the way we think about and write Javascript in the best way possible. (Need to write a few more blog posts about this soon since it's never explained well in these comparison articles.) It treats CSS and HTML as first-class filetypes right alongside Javascript so you aren't stuck inlining CSS or templates as strings which becomes incredibly unmanageable quickly. It's build step is modular too so if you really want to do custom things you can do them very easily. It's got it own's registry so you don't have to wade through junky npm modules figuring out what's supported in the browser and what isn't. It's written by TJ, so you know the API is extremely clean. It's based on GitHub's structure, so forking and tweaking is literally a one-line change instead of having to re-publish and maintain your own fork. There are so many benefits I'm forgetting too. More than that though, I guarantee if you start using Component for a couple months you will emerge a 5x better Javascript programmer. All of the existing components are very high quality, and their source is always very small, making them trivial to read through. It actually blows my mind now to think about the kind of code we were writing pre-component and how much it has changed. We probably open-source like 5-10 new components a week nowadays, I think we have something like over 200 components between the org account and all of us combined [1][2]. Disclaimer: I seriously love component, and really just want more people to discover how awesome it is. [1]: https://github.com/segmentio https://github.com/segmentio [2]: https://github.com/ianstormtaylor?tab=repositories https://github.com/ianstormtaylor?tab=repositories

ericgj 13y ago
I completely agree and recommend component for all the reasons Ian mentions. It is shocking how little-known it is in javascript land. Don't be put off by lack of documentation and examples, it is seriously awesome. In fact I can't imagine doing client-side dev without it.
paultannenbaum 13y ago
Just curious, have you guys given bower a chance, and if so why did you guys end up going with component. Component seems to be slightly more opinionated, less adopted, but really nice.
- ericgj 13y ago
  I haven't tried bower, but I always get a little confused when it gets compared to component. Bower seems like a downloader with some 'dependency management'. But its 'dependencies' are disconnected from a module/build system. Great if you have a separate tool to do your build, but frankly most of them out there are awful, and it would be a nightmare even with the best to wire them up to all the conventions of all the libraries you pull in. As Ian said, component's opinions encourage more modular, better code, and allow you to do what Web Components only now are promising within the DOM itself: bundle together templates, css, code, data, etc. And it does this without imposing a framework. For instance, if you have a pure javascript library, it is extremely easy to package for both component and NPM. Most of the UI components are framework-independent and that is encouraged. The component ecosystem and community is fantastic. And it's not sponsored by a corporation on the NYSE :) These were the main reasons I was attracted to component. The learning curve is a bit steep, but getting better all the time.
- jongleberry 13y ago
  1. bower doesn't do much. it downloads all your deps and its deps, but then you have to figure out how to consume the package. component handles all of that for you. if all i wanted to do is download and resolve dependencies, i would just use npm. 2. component doesn't just manage 3rd party packages - it helps manage your internal code/styles/templates as well. see https://github.com/jonathanong/bigpipe-example/tree/master/client https://github.com/jonathanong/bigpipe-example/tree/master/c.... keeping CSS/JS/HTML for a component of your site in completely separate folders is a thing of the past. 3. it's less adopted because it doesn't have Twitter's marketing and man power. TJ also hasn't had the time to document or market it well. it's also much more difficult to teach (well). 4. i hate requirejs due to its unnecessary callback and defining modules through function arguments. if i weren't using component, i'd use browserify. i have not seen any non-requirejs implementations of a build step, and i'd rather have a single step than two. 5. it's easier to share code between node and the browser. with requirejs, it's a little harder, but it's easiest with browserify. 6. most bower packages are bloated and require other large dependencies like jQuery, and I can't filter through that. component modules, on the other hand, tend to be very small, lightweight, focused, and overall better quality. for example, https://github.com/yields/select https://github.com/yields/select is becoming pretty excellent, much better and less bloated than select2. 7. bower packages tend to come with excessive amounts of options (because people request them, ex. select2) and excessive boilerplate code (because people want it to look good right way, ex Font Awesome). component packages tend to be the opposite - minimal, structural styling and very few options.
EGreg 13y ago
Um I took a look at some of the repositories. What is the point of this? onEscape? onLoad? Really? An entire "component" just to add a handler for the ESC key? WHY
- ianstormtaylor 13y ago
  Yup exactly. Your use of the word "entire" is what is wrong with your thinking, and what every other package manager gets wrong too. There is so much duplicated code out there as a result of people thinking to themselves "this is too small to be its own component". Instead, they just copy-paste it into the bottom of the file. Yes the "on-escape" component just attaches an escape handler to the document. One of the reasons for it is just to not have to write that code yet another time, since doing that is boring and, more importantly, prone to bugs. But the other reason is that it turns this: document.attachEventListener('escape', fn, false); into this: onEscape(fn); without losing any clarity whatsoever. It's also more performant than attaching tons of different escape handlers, because across all components everyone will share the same event listener. Even for components that somebody else wrote and you're just using. So yes, there's a component just for onEscape.
  - EGreg 13y ago
    Don't get me wrong, I think there's a lot of value in components. If you look at my company's logo, you will see that it is three building blocks. Our framework and platform are all about reusable code blocks. Having said that, though, I think this is taking it way too far. Most of these things are trivial one liners in JavaScript. Yes, it is true that you can have many places in the code hooking into the same event listener, but guess what, having many event listeners hooked into the same event dispatcher is rather as edficient. And what if later I want to press the letter K? Do I need a component for every letter? For that matter why don't you have a component for addition and subtraction and another component for pressing the ? I mean, look at node modules. They do more than handle a single key press. Socket.io for example has an overall theme, so does express, and so do other modules. What is the theme here? Make every line into a component so I can introduce setup and teardown code for it?

ericgj 13y ago

I completely agree and recommend component for all the reasons Ian mentions. It is shocking how little-known it is in javascript land. Don't be put off by lack of documentation and examples, it is seriously awesome. In fact I can't imagine doing client-side dev without it.

paultannenbaum 13y ago

Just curious, have you guys given bower a chance, and if so why did you guys end up going with component. Component seems to be slightly more opinionated, less adopted, but really nice.

ericgj 13y ago
I haven't tried bower, but I always get a little confused when it gets compared to component. Bower seems like a downloader with some 'dependency management'. But its 'dependencies' are disconnected from a module/build system. Great if you have a separate tool to do your build, but frankly most of them out there are awful, and it would be a nightmare even with the best to wire them up to all the conventions of all the libraries you pull in. As Ian said, component's opinions encourage more modular, better code, and allow you to do what Web Components only now are promising within the DOM itself: bundle together templates, css, code, data, etc. And it does this without imposing a framework. For instance, if you have a pure javascript library, it is extremely easy to package for both component and NPM. Most of the UI components are framework-independent and that is encouraged. The component ecosystem and community is fantastic. And it's not sponsored by a corporation on the NYSE :) These were the main reasons I was attracted to component. The learning curve is a bit steep, but getting better all the time.
jongleberry 13y ago
1. bower doesn't do much. it downloads all your deps and its deps, but then you have to figure out how to consume the package. component handles all of that for you. if all i wanted to do is download and resolve dependencies, i would just use npm. 2. component doesn't just manage 3rd party packages - it helps manage your internal code/styles/templates as well. see https://github.com/jonathanong/bigpipe-example/tree/master/client https://github.com/jonathanong/bigpipe-example/tree/master/c.... keeping CSS/JS/HTML for a component of your site in completely separate folders is a thing of the past. 3. it's less adopted because it doesn't have Twitter's marketing and man power. TJ also hasn't had the time to document or market it well. it's also much more difficult to teach (well). 4. i hate requirejs due to its unnecessary callback and defining modules through function arguments. if i weren't using component, i'd use browserify. i have not seen any non-requirejs implementations of a build step, and i'd rather have a single step than two. 5. it's easier to share code between node and the browser. with requirejs, it's a little harder, but it's easiest with browserify. 6. most bower packages are bloated and require other large dependencies like jQuery, and I can't filter through that. component modules, on the other hand, tend to be very small, lightweight, focused, and overall better quality. for example, https://github.com/yields/select https://github.com/yields/select is becoming pretty excellent, much better and less bloated than select2. 7. bower packages tend to come with excessive amounts of options (because people request them, ex. select2) and excessive boilerplate code (because people want it to look good right way, ex Font Awesome). component packages tend to be the opposite - minimal, structural styling and very few options.

EGreg 13y ago

Um I took a look at some of the repositories. What is the point of this? onEscape? onLoad? Really? An entire "component" just to add a handler for the ESC key? WHY

ianstormtaylor 13y ago
Yup exactly. Your use of the word "entire" is what is wrong with your thinking, and what every other package manager gets wrong too. There is so much duplicated code out there as a result of people thinking to themselves "this is too small to be its own component". Instead, they just copy-paste it into the bottom of the file. Yes the "on-escape" component just attaches an escape handler to the document. One of the reasons for it is just to not have to write that code yet another time, since doing that is boring and, more importantly, prone to bugs. But the other reason is that it turns this: document.attachEventListener('escape', fn, false); into this: onEscape(fn); without losing any clarity whatsoever. It's also more performant than attaching tons of different escape handlers, because across all components everyone will share the same event listener. Even for components that somebody else wrote and you're just using. So yes, there's a component just for onEscape.
- EGreg 13y ago
  Don't get me wrong, I think there's a lot of value in components. If you look at my company's logo, you will see that it is three building blocks. Our framework and platform are all about reusable code blocks. Having said that, though, I think this is taking it way too far. Most of these things are trivial one liners in JavaScript. Yes, it is true that you can have many places in the code hooking into the same event listener, but guess what, having many event listeners hooked into the same event dispatcher is rather as edficient. And what if later I want to press the letter K? Do I need a component for every letter? For that matter why don't you have a component for addition and subtraction and another component for pressing the ? I mean, look at node modules. They do more than handle a single key press. Socket.io for example has an overall theme, so does express, and so do other modules. What is the theme here? Make every line into a component so I can introduce setup and teardown code for it?