On Tailoring and Web Frameworks

Post from July 13, 2016 (↻ December 5, 2021), filed under Web Development.

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, and I’m an engineering lead—currently manager for Developer Experience at LivePerson—and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.

If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!

Read More

Maybe this is interesting to you, too:

• Next: The Anatomy of a Coding Guideline
• Previous: A Note on meiert.com Feeds
• More under Web Development, or from 2016
• Most popular posts

Looking for a way to comment? Comments have been disabled, unfortunately.