To framework, or not to framework, that is the decision

Lately I’ve found myself with renewed urge to learn new things through building new. Usually that starts with a good idea “damn, it would be cool to build X!” – you know the feeling.

But being a bit of a perfectionist (it’s something I’m working on), the dreams of features quickly becomes consumed by other ideas, like: “it would be cool to build this with X” or “I wonder if I could do this with Y”, “should I stick with Z that I know?” “I have been meaning to learn A!” and so on and so forth.

I have dabbled in plenty of technologies; NextJS, NestJS, AdonisJS, Remix and that’s just in the Javascript world. There’s plenty more below the surface.

And I bet you have too!

So this post is an insight into my mind and how I use a “clarifying lens” to answer that question, a lens I have recently uncovered myself and that has helped me immensely.

The Allure of Frameworks

Frameworks, offer a structured foundation to build upon. They come with a set of rules, best practices, and tools that aim to streamline the development process, making it faster and more efficient. Often, frameworks will be opinionated in one direction or another, making for a certain ways to “do things” in the way that creators (of the framework) intended.

I have seen some pretty strong opinions for, and against, opinionated frameworks. Personally, I’m all for it. I love when there’s a certain way to do things that you can model your code after. As a small gain, among many others, its often quite simple to jump from project to project using the same framework.

If you find yourself working within tight deadlines or specific architectural requirements, frameworks can be a godsend. They reduce the need to reinvent the wheel, and often allow you to move much quicker than without one.

MVC frameworks (AdonisJS, Ruby on Rails, Laravel etc.) have had their reputation in purgatory for almost a decade, if not longer, but I find they can be quite useful. I have yet to see frameworks that allow developers to move as fast as they can with an MVC framework, wrapping everything into one nice well-thought out bundle.

This realm has been expanded with the addition of the new and popular “meta frameworks” (Remix, NextJS, etc.), which serve to resolve some of the same issues.

Whether its MVC or meta frameworks, these tools have incredible speed and DX at top of mind. These tools are built to make your, the developers, job, much easier. There’s a significant amount of decisions in a framework, aimed at reducing boilerplate and simplifying otherwise complicated concepts to a point where even new developers have a fighting chance.

They do this, among other techniques, by abstracting away a lot of decision making for you. Making choices for you (hence the concept of opinionated frameworks), reducing the decision making you have to do.

In my opinion, frameworks with a focus on DX are simply amazing for small developer teams, because they allow individuals – or small teams – to move incredibly fast. Moving fast means that you’re able to focus more on features and providing real, tangible value, instead of having to deal with technical nonsense.

I have no science to back this up with, but it seems to me that for small teams of up to 5 or 6 people, these frameworks are a great choice, because that’s a size where conflicts aren’t yet a dealbreaker, and everyone can work on separate things in parallel.

The Case for Going Framework-less

Now, on the other hand, choosing not to use a framework—going “framework-less”—presents its own set of advantages. It offers a level of freedom and flexibility unmatched by any pre-defined structure.

This approach can be particularly beneficial if you’re looking to truly understand the fundamentals of a language or technology, as it forces us to tackle problems we wouldn’t encounter using a framework, as we build everything from scratch.

At some point its a semantic discussion; at what point is something a framework and when isn’t it? Just so we’re on the same page, I would consider the examples from the previous section frameworks, and something like building your own NodeJS API using Express, as going with no framework.

I’ve spent a good chunk of time building my own APIs with NodeJS, and baking my own Authentication solution every time, isn’t a great experience.

However, doing so also presented me the side-effect of learning a massive amount about things I otherwise wouldn’t have cared to explore (looking at you, authentication). Learning is incredibly valuable in our industry and having the knowledge and know-how of how various complex things are built is a massive advantage.

That’s the clear upside of going with no framework; you get massive learning. It can be a challenge to build many of the things we consider integral to how a modern web application should work; authentication, message queues, caching, rate limiting just to name a few.

There’s also the less outspoken, but much worthwhile, flexibility that comes with building from ground-up. Often, documentation, packages and libraries are built to fit the language, not one specific framework. Unless it becomes incredibly popular of course. Looking at you, Laravel and Ruby on Rails! 👀

That means you’ll be able to adjust everything within the project as you are not confined to one specific way of doing things, and you can explore many different approaches to solving a particular issue.

Throughout most of my time with programming I have really enjoyed this approach. I’m a lifelong learner, and I love exploring new technology. I still find myself writing NodeJS backends if its for an exploratory project on my own time.

The clarifying lens that helps uncover our approach

You still with me?

That became a bit more long-winded than I anticipated.

But, since we’re here, lets dig into how we can use the lens to uncover which approach we should be going with!

Simply put, I have found that a series of simple questions can help me narrow in which decision to make.

Here they are:

  • Is this project for fun or for work?
  • Is there a particular framework, language or technology, I want to learn?
  • Is this something I intend to run in production?
  • Do I expect to be working with anyone else, anytime soon?
  • Is this time sensitive in any way?

I’ve found that simply answering these four yes/no questions, greatly help me understand what the correct tech decision will be, before I get my project spun up.

The idea is that one single answer to any of the questions above, doesn’t quite paint the full picture. We want to answer each of them, putting points in either bucket, and then tally the scores at the end to see where we land.

1. Is this project for fun or for work?

What I try to answer here, is whether something must have a certain quality to it, or if I can go completely rogue. Going without a framework leads to making more decisions, which could be bad ones, especially if I’m exploring new and unfamiliar tech, that can make the project difficult to maintain down the line.

If its for work, you may want to choose something you’re familiar with and something that’s stable.

If its for fun, choose whatever you’d like 🙂

Which brings me to the next question…

2. Is there a particular framework, language or technology, I want to learn?

As developers, we all have that urge to explore. To learn new things. To dive into new and exciting tech. Well, this might be your opportunity to do so!

If you’re anything like me, you’re probably keeping a backlog of interesting frameworks, technologies or ideas that you want to explore at some point.

Now could be the time!

As before, if this is for a work project, I would put another point in the bucket for ‘go with familiar’, however, that being said, it’s also possible to try your hand at something new, but will depend on answers to some of the later questions.

If its for fun, I certainly think this could be a good time to explore something new!

3. Is this something I intend to run in production?

Here’s where it starts to get a bit tricky. Exploring a new framework or language is fun, but it may not be worth the pain if you expect to run it in production. The thing is that different requirements have different solutions – obviously – and can be more cumbersome than initially thought.

For example, the first time I needed to host a Ruby on Rails app, I spent an ungodly amount of time trying to get the production run setup. It has different requirements than running it in development, and the tooling in that ecosystem is different than what I’m used to for hosting Javascript, so even for something as simple as “let’s deploy!” I needed to do quite a bit of research.

It may be wise to stick with familiar, but not an absolute necessity. Just prepare yourself for some research if you’re exploring a new language or framework, and don’t expect things to just smoothly sail into production.

4. Do I expect to be working with anyone else, anytime soon?

For me, this is one of the questions that really makes it fun. Remember my prior point about using MVC frameworks on teams of less than 5/6 people? This is one of the considerations at this stage.

If I expect to be working with someone else quite soon, I would personally favor a framework, because they always follow a paradigm in which things are done a certain way. In other words, its easier for someone else to jump in and relatively quickly get an understanding of what I’m doing with the project and how they can contribute.

If I’ve completely home-baked my own solutions for everything, that process is going to be a while longer.

So, if I expect to work with someone else, it may be wise to A) go with something I’m familiar with, but more importantly B) use a framework, so things are consistent.

Is this time sensitive in any way?

The final thing I personally consider is whether the project I’m starting on is time sensitive or not. Do I have a deadline for it? Do I have an idea of when I want to launch? Is it for work, perhaps where something is expected within a reasonable amount of time?

If the answer is yes, I would go with a framework, preferably something that’s somewhat comfortable to me.

If the answer is no, thats at least one point in the “learn something new” bucket for me 😄

And just to be clear, even though we’re discussing choosing a framework (or not choosing one), learning a framework can certainly go in that bucket too!

Tallying the score

Now we’re at the end of my little list of questions. Overall my opinion, as I’m sure you understood from each section above, as below:

  • For work, deadlines or working with a team I recommend sticking with familiar technology and frameworks. The predictability, efficiency, and overall DX that comes with frameworks will significantly benefit development timelines and final product quality.
  • For personal projects or “for fun” initiatives, I would prioritize learning something new. Challenging yourself to build something from scratch really is a terrific way of gaining a whole new understanding. I used to struggle with understanding how oAuth works, until I had to build it myself. Now it just clicks, and I can carry that understanding with me into any new project or job I come upon.

Staying curious and learning is one of the ways we can stay adaptable in our industry, and as we all know “survival of the fittest” really means “survival of the most adaptable”.