How to Choose a Front-End Framework
You might be new to front-end development, confused about the front-end ecosystem and all of its complexities.
You might be an experienced front-end developer, confused about the front-end ecosystem and all the new complexities created in the past six months.
Regardless, your company has tasked you with building a web application to solve business problems. You will need to meet business needs through front-end code.
The front-end ecosystem is one of the fastest communities I have ever been a part of. If you happened to be working on a stable project at work for more than 6 months without doing exploratory learning, you are already behind the meta.
In a world of countless best practices and hottest frameworks renewed annually, what are you to do?
Close your "hottest front-end frameworks of 2021" article and take a survey of your knowledge, your project, and your team. Only by deep diving into these three areas can you choose the best direction to set off in.
What do you have now?
In order to choose which framework to use, you must understand your project. Will this application be nested inside another? Will you deploy it to AWS? Azure? Will you need to hack in some custom code to load React in Angular? If you are building new, how will you make it work with the current system architecture?
The best solution will almost always involve integrating with or migrating from pre-existing architecture. Not only can you recycle old functionality, but unless someone meticulously documented the previous project requirements, if you do not use what your team already has, it is likely your new implementation will miss an uncommon use case or neglect an undocumented section of the user base.
As time goes on, a legacy codebase becomes more intractable. At the same time, as time goes on, a widely-used legacy codebase becomes more difficult to reproduce.
You don't want to force a framework onto an application with clear, solid architecture decisions. If the login portal is written in Angular 2, and you are tasked with creating a new user flow to be used within the portal, strongly consider using Angular 2.
On the other hand, if you have free rein to write a new application from scratch, feel free to go ham and make opinionated decisions that will work in the long run.
What do you know?
When choosing a front-end framework for your web application, it's important to take into account what types of projects you have have written before. If you have a relaxed deadline for the project, write the code in a way that maximizes your fun while being reasonably maintainable. If you don't have that freedom, it is important to think about the level of your own knowledge when choosing a technology stack.
Vue might be the hot new thing at the time, but if you have only ever built Java Server Pages, you could delay the timeline of the project due to needing to learn many new things simultaneously. In this same situation, even if you are able to code out the implementation quickly, the framework itself might have some quirks or bugs that you haven't experienced before and will require you to fix after deployment.
Each new thing you need to learn costs time. Choosing a completely new implementation strategy on a project with a rough deadline could prove to be a disaster for your team.
Each time you work on a project you have two people's expectations to fulfill: your boss's (client) and your own.
If you neglect one for too long you will be out of a job. If you neglect the other, you may lose your passion. A programmer without passion has started down the long journey of becoming management (or leaving the industry).
Balance your own curiosity with the project requirements at hand. If you look for opportunities to learn, you can often complete a project while bolstering your stills in the process.
What does your team know?
When choosing a framework, we often do not consider what our team is familiar with.
We know our teammates are smart. Because of this, it is easy to fall into the trap of thinking that our teammates will be able to handle any new technologies we throw at that.
It is import to clarify our definition of smart when it comes to our team mates. Smart does not mean that they know (or should know) everything we do. Our teammates will have a different experience than us. This experience will allow them to learn some technologies faster. It will also limit the speed they learn others, since there will be more for them to learn.
The biggest problem with assuming that our teammates know what we do is the compounding of learning time that can arise when we expect them to know something they don't.
When each technical member of the team needs to learn something new, we may encounter a compounding of learning requirements that delay or influence the quality of the project.
If your team is full of people who are willing to learn on their own, we can estimate the learning time by multiplying the amount of team members by at least the time it took you to learn. This also does not include time it will take future team members to understand how you used certain features of the new technology.
Although we may be called upon to start a software project on our own, there will come a point where we will no longer work on it. If the project gained traction, someone else will be asked to bear the weight of our decisions.
As you choose your technology stack, think of the engineers who will use what you are building in the future.
What are you interested in?
When choosing which framework to use, your personal interest should play a factor in the decision.
The fundamentals of front-end applications remain the same across frameworks. Even if frameworks use different programming paradigms, they all abstract over apis that are relatively consistent (the browser).
Choose one, invest time to learn it well and run with it.
If your requirements allow it, choose the most interesting way of solving your problem and start to prototype. Learn the basic principles of the framework. Focus on using the new technology to deliver features to your stakeholders. As long as you take effort to remember concepts and important details of what you learn (maybe through incremental learning, you will continue to grow into a more valuable developer.
Maintaining interest in your work is your job. No one will do this for you! If you find a way to continue, you will avoid burnout and continue passionate work for the rest of your life.
