Re - Components in practice

Hunter Loftis

  • Reading Time  Min Read
  • Publish Date July 29, 2012

TJ Holowaychuck recently published his thoughts on the direction and future of JavaScript components. The post has begun a discussion with Isaac Schlueter, but strangely no one has mentioned the most intriguing part of TJ’s explanation, “Components in practice:”

At LearnBoost we’ve been using components for a while now, but like I’ve mentioned not only for abstract UI components, but for everything in our application, even the build system and application bootstrap are implemented as components.

That sounds awesome. How exactly does it work? TJ attaches a screenshot that shows a flat list of component directories, which begs several questions:

Big picture

It’s clear how a flat list of components would help with testing and coordinating teamwork. However, let’s say you hire a new developer to jump on this project, and he pulls down the repo. Where does he start? How does he get a feeling for the high-level orchestration of this machine of many components? Is there a “main” component that represents the application’s entry point? Similarly, what does debugging look like in this environment?


I’m going to make up a figure here and say that 99.9% of npm modules depend on at least one other module. One of the arguments TJ makes is that such dependencies cause fragmentation, eg jQuery versus MooTools. However, I’m assuming there must be some composition happening in this app, since LearnBoost is far more complex than a popover implementation. I’m also going to suggest that several of these components likely depend on express, mocha, etc. How is that different from depending on jQuery or MooTools?


Code is worth a thousand blog posts, and I think I would understand TJ’s proposal much better via example. I’d love to see a pure-component demonstration of a 2-page project, with ‘/’ (login) and ‘/dashboard’ (hello, world). With a firmer grasp on the details, I’d be willing to try a component-based approach on my next project.

I’m fascinated by TJ’s proposed alternative to, as he puts it, modules that “splatter themselves all over your system.” I hope this proposition doesn’t get lost in the debate surrounding AMD, CommonJS, build systems, npm, etc.

Send Us a Message

Let's Work Together

By filling in the form, you agree to our Privacy Policy, including our cookie use.