What even is a framework?
A few times in my front-end development career, I’ve been asked about the various frameworks I’ve used, heard of, or otherwise come across, and what I think about them.
It’s a fair question, after all, despite my short time in the industry, I’ve been involved in projects using a few of the big guns for a large percentage of my time.
I think that there’s a lot of value to be brought in using a framework, even from the non-technical standpoint (be that hiring, or shared vocabularies, or many other things), but from a technical point of view, I think that a lot of the “Framework Wars” can be condensed down into a single point, that explains the stubbornness of someone who will not be convinced of the benefits of not-theirFrameworkOfChoice.js.
At the end of the day, regardless of the framework you, or loved ones, hold dear, I believe that the reason people gravitate toward a framework, or other library, is based solely on how they perceive things, and how they understand complex behaviour and logic within web applications.
Note that this is not about how well anyone understands these things, be that from the point of view of how a browser handles these things, or anything else that could be “explained” by a lack of knowledge.
This isn’t about knowledge, intelligence, or any preconceived notions.
This is about how easy it is to pick up and learn a new thing.
When I was 20, and needed a job, I found somewhere that was willing to take me on as a “labourer”, and as part of that hiring process, I discovered that I would need to know how to drive a forklift, and that the company would pay for me to do that, with a cross-company license that said that I was safe to get behind the wheel of heavy machinery and carry heavy loads across uneven ground, and be relied upon to do that safely, and efficiently, for at least 5 years. (That’s the limit on UK forklift licenses, after that point you need to be retested to renew the license).
Working with my hands on an industrial saw, which would be fully capable of slicing through any body part you happened to leave under the blade without batting an eyelid, and carrying large steel pipes on a forklift that would very happily tear through most things given a high enough speed, was quite a shock. I’d come from a comparably cosy and privileged life where I’d hoped to make my money and contribute to the global capitalist machine with my brain, perhaps in front of a computer.
However, as it turns out, while the work was physically demanding, and required a lot of “common sense”, (not the phrase I’d use, as many of the things I learned were neither “common” nor made “sense”), the day to day was less mentally stimulating than I would like.
So I made the best of it. Did a bit of maths, scribbling down my calculations in notebooks, and tried to optimise the process of cutting pipes that were somewhere between 12 and 13.5 metres long, down to x length, for a total length of y. (Figuring out whether it made sense to ensure a minimum total length to get the least waste from a single pipe etc).
When doing that, (naturally while the saw was running, and the saw beds were fully stocked), I realised that there was an important in optimising any workflow, and that was to make sure that the time cost of solving the problem in the most efficient way, might offset any savings that you gain from the extra efficiency.
For example, if it took an extra 30 minutes, (where the saw would run for 4–6, and would need to be restarted at that interval), to get new pipe that would save 0.3 metres of waste, but the cost of 0.3 metres of pipe, and the likelihood of selling that pipe, was low enough that it didn’t justify 30 minutes of time every few hours when I needed to restock, then it doesn’t make sense to spend the extra time.
Which brings me back to frameworks, (I swear!).
People will gravitate to whichever framework (or lack thereof) that fits their mental model the best. If someone has been doing MVC in various stacks for a decade, they’ll probably gravitate towards a framework that allows them to keep the same ideas in play, and they’ll be super productive in it. The difficulty comes if you want to onboard someone to that project who lacks that experience. Then the abstractions that either the project’s developer(s), or the framework’s developers, have built up over the lifetime of the app/framework, make little to no sense from the new developer(s) point of view, because their mindset, and how they understand the problems being solved, are different to what the framework, or application, expects.
For me, the costs of onboarding a framework, (or library to be used everywhere), should be measured with two factors:
- How long will onboarding this framework take, vs how much time will we gain by sharing these common abstractions and shared vocabularies.
- How long would it take someone who didn’t know these particular abstractions, but understands the high level processes, to be productive in this framework.
For sure there are more reasons to consider framework choice from a technical point of view, but a lot of people have written about them, (I’m looking at you @aerotwist), so I thought I’d chip in with some ideas that I haven’t seen in long form before.
