On Tailoring and Web Frameworks
Published on JulĀ 13, 2016 (updated DecĀ 5, 2021), filed under development, frameworks (feed). (Share this on Mastodon orĀ Bluesky?)
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 web developer, manager, and author. Iāve been working as a technical lead and engineering manager for companies youāve never heard of and companies you use every day, Iām an occasional contributor to web standards (like HTML, CSS, WCAG), 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. (I value you being critical, interpreting charitably, and giving feedback.)