When to Use a Programming Framework
Against my own best judgement, I recently read a clickbait article with title like "Why You Shouldn't Use Web Frameworks." While I do hold a general wariness of web application frameworks, I disagree that frameworks are bad in all cases. In fact, in many cases you'd be downright crazy not to use a framework.
And what cases are those, pray tell?
Read on and find out!
In short, it makes sense to use a framework for:
- Prototyping: Getting an idea to a usable piece of software very quickly
- Expediency: You could solve the problem the framework addresses, but someone has already come up with a good solution, and/or
- Extending your reach: The framework helps you do something outside your core skills, which you have no interest in learning how to do
If you're making a website for a business idea, using Rails & Bootstrap can get you up and running with layouts, login/auth, routing, admin screens, callout boxes, modals, etc. in less than a day, provided you're familiar with the tools. This is pretty amazing!
A friend was building a site with Drupal and he wanted to implement search with Solr. There was a Drupal plugin to do it, so he used that plugin. He was a skilled developer and could have written a CMS from scratch and implemented Solr search to boot, but this would have been a waste of time because someone had already done it. He wasn't using a framework out of ignorance or inability to complete the task without one, but out of expediency.
Likewise, writing basic HTTP routing logic and query string parsing is not a herculean task, but if someone has done it already, why reinvent the wheel? A key component to this rationale, however, is that you could do the task by hand if you wanted to. We'll discuss why this is important later...
- you you don't know how to solve a problem from scratch
- you have no interest in learning how to do so, and
- a framework offers a ready made solution
This is a great time to use a framework!
If you're a python developer and you want a nicely layed out website that works well on mobile phones and looks professional, you can get there with Bootstrap without spending time learning a lot of HTML, CSS, and other browser technologies. A framework is a very powerful tool in this case, extending your ability to create things far beyond your realm of expertise.
But you should learn the underlying technologies!!
- Strawman Who Hates Frameworks
If writing HTML based user interfaces is a core skill of yours (or you wish it to be), yes, you should learn the underlying technologies. But if it's not a core skill and you don't wish it to be, then learning how flexbox works is a waste of your time. It is best to focus your time on those things you _do_ wish to be an expert in, and use out-of-the-box solutions for the rest.
There are at least four situations where it's not appropriate to use a framework:
- When you're learning: When you are just starting on your journey to becoming a professional programmer
- Because it's all you know: Not everything is a nail, you should have more tools than just a hammer
- When it's overkill: When the framework has ten features and you only need one
- When it makes absolutely no sense: More common than you'd think!
This is the counterpoint to the "use a framework if you don't care to learn the underlying technologies" argument. If you _do_ want to learn and develop expertise in the underlying technologies, a framework is not a good way to start, in my opinion.
Starting your learning journey with a big framework has many disadvantages:
- It's likely to be overwhelming and confusing
- You're dependant on the framework, and if you need to augment or extend its behavior you won't know how
- You'll need to rely on "experts" to help you when you get stuck, because you'll lack the skills needed to actually understand the framework internals once it becomes necessary to do so
- It doesn't teach you the fundamentals of the language or environment, so you'll be stuck using that framework until you bite the bullet and actually learn the underlying tools
- You won't know why the framework does what it does–this understanding only comes from working without a framework
When certain tasks become tedious, you'll know it's time to pull in a library. Eventually you'll get to a point where you say "gee, I wish there were an easier way to do X", for example, create HTTP requests. At that point you pull in a library to do that task. Whereas a framework gives you a full toolbox and a set of instructions, writing by hand and pulling in libraries as needed will help you understand why it is useful to use that tool., which is a crucial to programming effectively, with or without a framework!
If all you know is React/Webpack, you will struggle to solve problems that React was not designed to solve. Ideally, you should analyze a business problem first, then decide what the best tool is to solve that problem. If all you have is one tool, you are not capable of doing this.
Having only one tool that you know frequently leads to the next two framework-use-antipatterns...
Imagine you have a bunch of IoT thermometers, and they need a server to periodically send data to, which will write that data to a CSV file. This server needs exactly 1 endpoint:
If all you know is Ruby on Rails, you will probably create a new Rails app with a database, a complex & powerful ORM, models, controllers, flexible authentication options, admin routes, json marshalling, HTML templating, and dozens of other features. This is overkill! Furthermore, the tool isn't even built to do what you need it to do (Rails is designed to work on a database, not a single CSV file). If you learned "Ruby" to start, rather than "Ruby on Rails", you would be able to easily build a tiny server, probably with one single file and zero dependencies, and this is guaranteed to be cheaper to run and easier to maintain.
I was reviewing one candidate's submission, and found a half dozen directories, config files for eslint, vscode and webpack, several web-font files, an image optimization pipeline, all of React.js and far more.
The candidate had clearly learned to use
create-react-app to start projects, and had learned no other way. That lead them to submit a solution one hundredfold more complex than was needed, and that didn't meet the requirements–we didn't ask ask for a web app! This is an extreme case but it illustrates the fact that if you only know one tool, you will invariably attempt to use it to solve problems it's not well suited for.
Programming frameworks can be useful tools, but they can only be deployed appropriately if you've learned enough to be able to pick the right tool for the job. To learn this skill, you must first learn to work without frameworks.
Put another way, the best way to ensure you use frameworks properly (as a beginner) is to not use them at all. Does that make sense?
I remember that my first contact with the world of web apps was using Ruby on Rails. It surely felt like magic and it was amazing working with the framework, but years later I started struggling to understand simple HTTP requests and MVC concepts. Therefore, I couldn't have put it better: the better way to start learning how to build professional web apps is to start with just a piece of wood, a hammer and a nail - but not with an IKEA box with a book containing complicated instructions. Thanks Sequoia!
Thank you for the generous feedback, and I'm glad to hear this post reflects your experience well. I like your "Ikea" analogy–I kept struggling for analogy around a gas-powered ditch digger vs. a shovel, but Ikea furniture is much better. Cheers!