CS Chris Smith
CodePen Mastodon X (formerly Twitter) Feed

When to Reach for a Framework (and When Not To)

by Chris Smith
,

First off, when I say "framework" in this post's title I just mean any big chunk of stuff that you load up and it does stuff for you. So, could be React, jQuery, Bootstrap, etc.

Let's say that a "framework" is made up of 10 bits of functionality. If we use all 10 of them then we're getting great value from it. Conversely, if we're only using one or two we're probably loading up a lot of stuff that is never used - bloat.

DIY?

If you're only using one or two bits then you'd probably be better off writing these parts yourself, if you can, or finding smaller libraries which do just the parts you need.

If you go too far with trying to roll your own system you end up with a kind of framework but one that's made up of lots of disparate parts which may have other dependencies. It's a Frankenstein's Monster of a framework. Hard to maintain and extend.

Tipping Point?

So, the real question is at what point do you move from assembling your own parts to adopting a full framework which organises these parts in a coherent and systemic way? Where's the tipping point?

Going back to our example of a framework that offers 10 bits of functionality, how many would you want to be using to make adopting the framework worthwhile? I think it's important not to look at the now but at the future. Where is your project headed? Will it keep growing? What other functionality might you use further down the line? Does the framework given you other things for free that you can do now?

Framework Benefits

The other major benefit that a framework brings is the knowledge and familiarity. You can recruit someone who has worked with a framework before and they will be up to speed quite quickly compared with someone coming in and having to pick their way through a large custom system.

If a framework offers 10 bits of functionality I'd be inclined to adopt it as soon as you're using 3 of them. I feel the benefits of a framework outweigh the saving.

You also have to consider the quality. Is a framework that has been worked on by top engineers and tested by thousands of developers going to be better than something you roll yourself? And will it integrate better with other third party tools?

Modules FTW

The real answer is for frameworks to become modular with a very small core and lots of optional modules. Not NPM which is going back to the "Franken-framework" but a properly connected set of features which can be included or dropped as needed. A bit of an old-school example now but jQuery UI does this very well - you can build a custom version of the library to suit your needs.