Component-based html makes sense when working on large (multi-site) projects and easily extends to the entire workflow, from architecture and design to css, javascript and back-end. Once you decide to go the html components route, everyone has to go along with it. One thing I didn't predict up front was that the biggest problem I was going to hit had everything to do with its main selling point: the perceived simplicity of (html) components. A component is little more than a small(ish) piece of html code that looks cute and manageable from afar, but in reality even the tiniest block of code can become an unmanageable beast in less than a blink of an eye.

from page to components

Once you decide to go down the component route you can't permit yourself to do a half-arsed job. If you work with components, your delivery is exactly that: components. Pages are pretty much demoted to an afterthought in the process, a reality check to verify whether your components continue to work when put together. So instead of wireframing and designing pages, you wireframe and design components. You css and javascript these components, you cross-check them by building a few standard pages and when everything is in order you deliver the components to the back-end developer.

This is absolutely essential, as working with pages will never allow you to incorporate all the different variations. Give a page wireframe to a designer and he'll design the page. Give it to the csser and he'll css that same page. Send it in for a quality check and the page will be checked. The components may have disappeared from view, but they still exist at html and back-end level. At first you might not be too worried, until the customer starts to play around with his set of components, enabling and disabling all kinds of variables and inserting some bits and pieces of content in the most unexpected places. That's when the trouble starts.

five types of variation

Because I think this subject deserves some in-depth writing I decided to make a little series out of it. Instead of just listing all the possible types of variations and tack on a quick conclusion, I'll run through all the variations individually, working with a real-world example to try and prove my point. At the end of this series I'll dedicate a separate article to the conclusion, hopefully illustrating how a simple component turned into a downright monster.

In total I found five different (yet very common) types of variations. Ways to alter a single component that could result in problems later on (which means they should be checked through all levels of the process, from wireframe to back-end implementation). If you don't keep an eye out, you'll end up with an exponential growth that results in 30-300 variations in no-time. Many of those will look and behave similarly, but when these variations are hidden from view you'll be sure to miss some, resulting in more bug reports and more after-project care than your sanity can handle.

conclusion

So there we go. I'm still deciding on which component to work with (though I suppose I'll take something similar to the story component that I detailed in the Smashing Magazine article, as that is an easy component to understand and one that turns sour real quick if not handled correctly), but expect new entries in this series to pop up at regular intervals.

Next up: html variations.