On Tailoring and Web Frameworks

Published on July 13, 2016 (↻ December 5, 2021), filed under Development (RSS feed for all categories).

After building early HTML/CSS frameworks for GMX (though we never named our solution a framework) and Google (Go, preceding the programming language, and Maia) I had rushed to squeeze my experience with frameworks into a (literally) little book. In it there’s emphasis on a priority I’ve always deemed critical for us developers: the idea of tailoring. Here’s how both fit together.

We defined tailoring as “producing and adjusting to precise dimensions and needs.” Producing refers to developing a framework—whether internal or external—while adjusting commonly means fitting an external framework. The key here is “precise dimensions and needs.” We need to know our needs—otherwise we can neither produce nor adjust something to fit.

One view of tailored code, by the way, is to compare needed code with overall code. That can be hard to measure, because the number of characters or lines in our code doesn’t do the trick. But conceptually, tailoring means using as little and yet as effective code as possible, and not more.

What can we do to tailor? The approach depends on the origin of the framework, and that origin makes for a big difference.

An internal framework is relatively simple to tailor: We develop to the needs of our project from the beginning. These needs may be defined by comps (comprehensive layouts) and mocks (mock-ups) or, better, a style guide. Once all needed page types and elements have been specified, they’re coded up. If they’re all used by the later site or app, the code cannot be anything but tailored (although it can possibly still be optimized and compressed).

An external framework, however, is much more difficult to tailor (by the receiving side, because it’s impossible for the originator). In a basic sense, we need to deduct all needed functionality from all offered functionality, and then remove the code that remains. That leads us to the key issues with external frameworks: removing code may not even be possible, and tailoring then depends on the quality of the framework code and its documentation (e.g., tailoring will require testing, might break the framework, and could make the same work necessary for later updates, if not outright thwarting the ability to move to newer frameworks).

These are big issues that make for good reasons why few people actually go to the length of customizing or tailoring external frameworks (or any external code, for that matter). Yet the outcome—non-tailored and lower-quality code—is not very expert-like, and inferior. And so we see with more clarity why in a professional context, external frameworks shouldn’t be preferred. They promise to save cost, only to come with a stiff hidden tax or else bring down the quality of our work.

Now, some frameworks like Bootstrap or Gumby have begun to address these problems by offering sophisticated customization wizards. This is smart, because it significantly alleviates the issues of non-tailored solutions. Framework developers should offer and users use such functionality.

By the way, there’s another problem we need to consider: while we’re benefiting from either our decision to save cost or to improve quality, our end users benefit mostly from quality. Technically speaking, they are rarely on the list of beneficiaries if we decide to deploy a framework that’s bloated but easy to churn out.

To tailor internal frameworks:

• Be clear about needs.
• Build the framework to these needs.

To tailor external frameworks:

• Be clear about needs.
• Customize or modify the framework to these needs (or abstain from the framework).

As you can tell, this I just quoted–simply because what The Little Book of HTML/CSS Frameworks shares here is sound. The book’s still free by the way: I’m not sure whether the little books, in e-book format, will ever be charged for. Good news everybody.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)