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.
There are some components that bundle several components together, e.g. component/dom or component/enumerable. And there are certainly more general components for key handlers. But if you need just one piece of it, you don't have to install the whole bundle. And if you use it just once or a few times or in limited contexts, you're right, you can inline it and skip the dependency altogether. But the point is you have a choice depending on your needs.
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.
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/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 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.
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 [2]: https://github.com/ianstormtaylor?tab=repositories