In software design, there’s a powerful paradigm called “Convention over Configuration”. The concept is about taking unnecessary, time-consuming decisions out of your developer-hands, by more or less forcing you to follow a set of rules, when you develop with a specific tool or framework.
When you make decisions during your day, you’re constantly spending your mental budget, to a greater or less extent, depending on how complicated your work is.
You only have so much energy reserved per day, depending on factors like your sleep quality, stress levels, and more. This means that you should spend the energy that you do have, wisely.
The upside of Convention over Configuration
The advantage of following a Convention over Configuration approach is that by letting e.g. a software framework like Ruby On Rails, Django, Vue, or Angular make several big decisions for you you’ll end up spending less of your energy reserves on common problems that have already been solved for you.
This freed up energy means that now you can direct your focus and time on more important and project-specific tasks.
When I say that frameworks like Rails make decisions for you, I mean:
- Providing out-of-the-box functionality and components like routing, image transformations, SEO, CRUD — so you don’t have to write every new feature from scratch. I cannot stress enough how valuable this is.
- Laying out a set of rules (conventions) on how to organize your codebase, “The Rails way” or the “Angular way”, e.g. so you don’t have to think about how to name variables or functions, you simply do it like the framework tells you to.
- A framework can massively boost your productivity.
Sounds like there’s a lot of upsides when you following this convention over configuration paradigm, huh? There is! But there are also downsides, which I’ll cover next.
The downside of Convention over Configuration
The disadvantage of following the convention over configuration approach is that you have less freedom do build your applications your way. There’s a reason that frameworks like Angular, Django and Rails are called opinionated frameworks. It’s because the lead framework developers have strong opinions about how to do X, Y, and Z. You may or may not agree with all of their opinions.
The trick is to assess the pros vs. cons of complying with a framework’s opinion on how you should build your apps. There will always be upsides and downsides.
When you decide to use a framework, especially a full-stack framework (frontend + backend) like Sails, Meteor, VulcanJS or MEAN stack, your app becomes the framework to a greater or lesser extent.
If you coded your entire app in Meteor you can’t just turn on a dime a few months later and decide you don’t want to use Meteor anymore. I mean, of course, you can migrate your data to a different tech stack, but it’s usually a big and time-consuming decision — and who is paying for that?
Sometimes framework updates change the very nature of the framework, big-time. Like when Angular 2 came out. The changes from Angular version 1 to 2 were so dramatic, that you couldn’t just update your old Angular app to the new Angular, you basically had to rewrite your app following the “New Angular Way” or accept that your old app will be running on a legacy codebase, that eventually won’t get supported by the Angular team/Google anymore.
Good to know:
- The original Angular (1) is officially called AngularJS.
- The newest Angular (2) is officially called Angular.
- The AngularJS team has announced that they will officially stop supporting AngularJS (Angular 1) in Juli 2021. More info here.
Btw I’m not telling you about the Angular sob story (which pissed off a lot of developers) to discourage you from using Angular or other frameworks. In some situations using an opinionated framework to build your app is the only thing that makes sense. But context matters.
I just want to make it clear that there are consequences when you apply the convention over configuration paradigm. There are also levels to this stuff. Not every framework has equally strong opinions or rules about how you build your app.
The Next.js React framework, for example, is sort of a hybrid between convention over configuration and configuration over convention. There are certain things that Next does for you “The Next.js way”, e.g. code-splitting, but unlike with Angular, you don’t have to use Next.js’s routing system, but it’s there if you need it. With Angular, you have to use TypeScript, in Next.js you can use TypeScript if you want to.
So that makes Next.js the superior choice over Angular, right?
No, because the price of Next.js’s flexibility, by allowing you to configure your app almost 100% your way, is that you end up with a community that has many different opinions about how to solve X problem in a Next.js app. With free configuration, you get more variety, but less consistency. There’s a trade-off.
It’s much easier to find an Algolia Real-Time Search component on GitHub for Angular, that “just works” in any (modern) Angular project by more or less dragging & dropping it into your project than it is with Next.js or other React frameworks.
Context is everything
Using a strict framework could end up giving you a massive headache some time down the road. It could also be the one decision you make, that paves the way for your team to launch your startup’s MVP app on time.
Are you in a hurry, and on a tight budget?
Then use an opinionated framework that provides most if not all of the features you need out-of-the-box so you can launch your MVP asap, and then take it from there. Yes, that MVP could even be a WordPress website with a bunch of plugins (come at me, bro). Different projects have different technical requirements.
If the above is not your situation you might still want to use a framework, but a different type (perhaps less opinionated).
Perhaps for your specific project, it makes sense to keep your stack as lean as possible early on, and focus on building specific in-house features, e.g. with React, or plain JavaScript — and then, later on, adapt one of the popular frameworks like Next.js or GatsbyJS.
Perhaps you’ll end up building your own framework that consists of other frameworks and libraries — a common scenario.
Let context guide your decisions.
