Touchy-Feely Version
I’ve been using this word a lot at work lately. Framework. I’m sure they thought it at school what a framework is, but I was never really able to put it in words. Well, I was never good with words anyways (almost got F on multiple English University courses). But after in the game for a while, you start dealing with frameworks and libraries. For me:
| Framework | Library |
| Microsoft Foundational Classes (I know…) | C++ Standard Libraries |
| Angular | Bootstrap UI Library |
| React | Material UI Library |
Just like a neural network, you start to develop these “feels” of what belongs in one training set, Framework. And what belongs to the other training set, Library.
Framework feels like it is bossing you around. “Write it this way”. “Wrap it with this registry module”. And some bosses are very opinionated. “You can only use these modules!”. Cough. AngularJS v1.x. Cough.
Library on the other hand. I get the feeling of laziness. “Thank you programming gods for providing me with crypto algorithms”.
Sciency Version
After reading the latest ACM Queue Issue (November-December 2020) Issue, this touchy-feely understanding is finally put in words by the section Best Practice: Application Frameworks.
The feeling I got from framework is due to its main characteristic, inversion of control. It means that execution of your program, or the control flow, is from framework to user code. This easily contrast with the more “natural” control flow of using library where it is from user code calling the library code.
Makes sense. MFC, Angular, React. All of these call the user code. You write your UI code, and the framework’s life cycle code calls the UI code at some point.
C++ standard library, bootstrap UI library, or Material UI library all have the same thing. You call them. You import them, and execute them in your code. You need a module to represent time. You import C++’s chrono’s library. You need a dropdown box? You import a dropdown box from bootstrap or material.
That’s it. Really. I’m not gonna get hung up on definition. I feel myself becoming a lawyer while writing this paragraph. No offense. Well, some offense. Let us move to more practical things. What attributes does a good framework have?
Good Framework
It never ceases to amaze me how this stupid sounding mantra applies to so many things in software engineering, or engineering in general.
Keep it simple stupid
Someone, Somewhere
From writing classes, functions, libraries, and now frameworks.
The authors of the article above are engineers at Google. And they noticed that their best frameworks are the ones that abides by this mantra. By keeping it small, it doesn’t prescribe technologies so it is easier to use it.
For a better understanding, let us look at a more concrete example.
AngularJS vs React
AngularJS was one of the early UI frameworks for the web. Just for the record, I’m not talking about recent AngularJS. I’m talking about the old AngularJS v1. When I first started in the software development workforce and playing around with technologies, a co-worker/mentor introduced me to it. He mentioned one warning about this frontend framework.
Warning. It is an opinionated framework.
Some guy named Gregg.
If you have played with the first version of angular, or if you are managing a project with legacy code using this framework, you will often encounter problems like: “it is hard to decouple this module from this UI”. That is because the dependency injection in angular makes module tightly coupled to angular, making them very hard to decouple, thus encouraging people to only use angular library. Yes, that opinionated.
I have to deal with this mess these days. Not complaining. We’ve developed a couple of workarounds and procedures to migrate things. Migrate to a less opinionated framework. React.
Working with React is even better. If you know modern javascript, you basically know react (other than small learning curve of writing JSX). You develop the main application entry point, and from there you just import UI components and libraries. Any libraries.
Due to its significantly less opinionated nature, learning curve is smaller. You can use Promise and and whatever libraries you are using as before.
From my recent discussion with a colleague. Using functional component will even abstract away the need to know the application lifecycle from you. Amazing stuff.
Conclusion
Nice to formalize things now and then. Formalizing touchy-feely will make us more decisive in our future actions when making technical decisions. Less going with your guts and but going with your noggen. Or trusting these smart Google engineers accrued knowledge. KISS all the way!