How To Choose Framework For Web Development

In today's article we're going to look at one of the most challenging parts of a software developer's career: picking the right framework to build your project(s) on top of.

The more familiar your team is with a particular technology, the more productive you will be and the more likely you'll be able to ship features. When you reach a point with a framework where the patterns are ingrained into your memory and the friction to building features is low, it can be an incredibly productive environment.

Picking a new framework can therefore be very daunting - what if we don't like it as much, or if the ramp-up time is much longer than anticipated? However, just because your team is familiar with the framework, that doesn't mean by default it's the right choice. You should still ensure that the framework fits the problem you're trying to solve and is going to be a good fit for the project. Otherwise you'll build this project very quickly, but in a framework that is ill suited to the task at hand, and in the long run that will come back to haunt you.

When choosing a framework you are often not just choosing a framework, but investing in the ecosystem that surrounds it. You will need to consider the size and activity of this ecosystem - are people publishing additional tools that you could depend on, for example? If you want to build complex UI elements such as a datepicker, will you have to build that yourselves or can you install a popular, reliable third party option someone else has made?

You may prefer to build the majority of your features in house and minimise your reliance on third party dependencies, which is a perfectly reasonable choice. Just ensure that you, the team and stakeholders are aligned on this and aware that consequently some features may take a longer development time.

If you do decide to embrace third party components for your framework of choice, understand that by doing so you are increasing your reliance on others and giving up some aspect of control. It may be that you can ship a feature quicker by installing that third party datepicker, but when the time comes that you're asked to redesign it or change elements of it, are you going to be able to? Or will you end up having to push back because the component you chose doesn't flex in the way you require it?

In the age of complex web applications there are a myriad of tools that teams rely on to help them build, test and deploy software. The framework you choose may have an impact on which of these tools you may (or may not) be able to use in conjunction on your project. Does your favourite testing framework have an adapter to allow you to use it with your framework? Can ESLint, or other similar code quality linters parse and understand your framework's code?

One that's often overlooked but vitally important is if your framework is supported across popular code editors such as VSCode. Many frameworks these days have their own bespoke syntax for templating - we have JSX in React, for example, and Angular also has a unique syntax. Those frameworks have been around for long enough that there is solid editor support, but if you're picking a new framework that's in its infancy, that may not be true.

If your team are going to have to learn a selection of new tools in order to enable working with a given framework, you should strongly consider if that additional, considerable overhead is going to pay off in the long run, or if you should avoid disrupting their workflows and sticking with a more mature framework that's had time to integrate in with popular tools.

Continuing with the theme of mature frameworks, the amount of time a framework has been around for is a strong consideration. That's not to say that you should always pick the old incumbents, but there is something to be said for picking an established option. We'll talk more about this in the "Popularity in the community" section, but ultimately frameworks that have been around for years not months will usually have some strong benefits associated:

1. They are likely to be more robust because they have been used more for longer, leading to discovery of bugs and edge cases that can be resolved.

2. The team maintaining the framework are likely to be more committed to the project long term.

3. A framework that is used by more people is less likely (but not guaranteed!) to become unmaintained and slowly fade out of significance.

This is an easy one to consider - what do other teams/projects in your company use every day? If they are all using the same framework - let's say React, for example - then you deciding to try something new introduces inconsistency across projects. This may be a price you want to pay: without ever taking this approach software development teams never evolve, but the trade-off is that any developers moving projects may have to learn an entirely new framework before they can become productive.

I once spoke to someone who worked at a company that let each team choose their own framework independently of other teams, and as a result each codebase that company had felt like an entirely different company's codebase! Whilst I'm sure this was a pleasant experience for the individual developers on those teams who got to pick their preferred choice, the long term impact was a reluctance to move teams, and a difficulty to maintain each codebase to a good level. When you pick one framework and use it consistently you build up knowledge and muscle memory of how to work with it and fix problems as they occur. If there's a bug in the framework, you can fix it in all of your projects easily, because once you've fixed it in one you simply have to re-apply that same fix to each codebase. When each codebase is using an entirely different framework, you don't build that knowledge and memory which can be shared across codebases.

We've talked about the ecosystem around a framework and about a framework's longevity, but tangentially related is its popularity within the community. Are people excited about it? Are there blog posts written, conference talks given and coding streamed on Youtube or Twitch? It sounds a bit silly to consider, but this is important because:

1. The more people feel compelled to create resources, the more help there will be when you find a bug, or aren't sure how to do something.

2. If the community is excited, they will create resources and increase the appeal of the framework, increasing its growth and popularity.

3. A team that sees excitement in their framework is more likely to be motivated to invest time in working on and maintaining it.

There are many frameworks to choose from out there and each will have a distinctive approach or syntax that you have to learn. However, normally we can group frameworks into buckets based on the fundamental principles that they are built on top of.

For example, frameworks like React focus on components, and in the case of React it focuses purely on the view layer, without having an opinion on how the rest of your application is structured. This makes React a good choice if you are happy to make those decisions yourself.

On the other hand, Angular takes a similar approach to the view layer, focusing on building components, but additionally provides an opinionated approach to structuring large applications. If you align with the decisions Angular makes, you’ll find that out of the box you have fewer choices to make and more functionality provided for you.

There are two tricky things about choosing a framework for your project:

1. It's a big decision that you won't know is right or not until sometime into the project.

2. There is no definitive right answer.

So whilst you can never know for sure upfront if you're making the right decision, I hope that the set of considerations we've talked about today will help guide you. We are fortunate to have such a multitude of frameworks and options available to us, but with that comes the challenge of choosing the right one. Stay objective, thorough and considered, and I'm sure you'll make the right decision.