The Cost of Frameworks, Illustrated
Post from September 14, 2017 (↻ August 22, 2018), filed under Web Development.
There are internal frameworks and external frameworks, and even though I typically talk about HTML/CSS frameworks, this applies to other tech frameworks, too. Internal means developed internally, by ourselves or our organizations, external: developed externally.
Rephrased from the book, internal frameworks are safe to use or develop in every case because they represent the preferred way of developing web sites and apps. Internal beats external every time because external cannot, by definition, know all our needs or those of our organizations and often fails even basic quality standards.
Independent of any books to be quoted, self-developed frameworks are to be preferred when it comes to tailoring to one’s needs and for quality, third party frameworks only shine for speed. As speed is typically regarded as less costly, there’s a tendency for developers and managers to pick external frameworks.
When it comes to quickly building something, for proof of concept, I even second this approach. But for everything built for the long run, external frameworks are a pricey crutch that has to be avoided or be thrown away at the earliest time. The reasons are the ones mentioned: quality—and cost.
Figure: I’m glad when I manage to draw anything.
What this rough diagram wants to show is just the basic misunderstanding we have around internal and external frameworks, and the reason why we seem to keep talking past another. Many developers and managers shun internal frameworks because they fear the cost of developing one. That, by itself, and particularly when we’re talking about an early service or product, is understandable.
What’s so far been rather obscure are the long-term effects of either approach.
For external frameworks, effort and cost rise over time. Framework updates have to be managed. They may disrupt things. They may break things. The frameworks may even die, to be replaced (and to eventually force an expensive redo). Then there are growing dependencies, and at the same time fewer and fewer developers who were involved in the early days of setting up and managing that external framework. There has never been a happy end when external frameworks were involved.
For internal frameworks, however, effort and cost decline. Once set up, an internal framework requires comparatively little care, and maintenance is typically directly correlated with updates to respective site or service. This is a feature: It’s precisely what makes for tailored quality. We develop for the present.
This is simplified, yes. When we build a “fire and forget” site to sit on our own server to use a frozen copy of Bootstrap, fine. Setup cost will be low and maintenance will be low (yet! quality will be, too). And when we have an inexperienced team of developers, developing and maintaining our own framework may turn into a nightmare for years on end.
At the end of the day, the choice of framework depends on our priority for quality, and for our goals as professionals. Who cares not what they ship cares not to read this site anyway. Who wishes not to spend time learning wishes not to be bothered by code-related unpleasantries, either. But here we have different ideas about our profession and our work.
About the Author
Jens Oliver Meiert is a tech lead and author (sum.cumo, W3C, O’Reilly). He loves to try things, particularly in the realms of philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.
If you have any thoughts or questions (or recommendations) about what he writes, leave a comment or a message.
Have a look at the most popular posts, possibly including:
Looking for a way to comment? Comments have been disabled, unfortunately.