This article is a part of our thoughts on how to choose a frontend framework for our new administration app project.
What to consider?
When starting a new project a good deal of research should go into making sure you are using the best possible tools for your use-case. There are lots of different tools and frameworks out there and all of them excel in their own way, you must therefore look at your project and ask yourself the following questions:
- What is its defining feature?
- What is going to be complicated?
- What does your team already know? And what is their level of expertise?
- Would they benefit of having an opinionated framework like Angular? Or would it be better to go with something less opinionated like Vue?
- Who is behind the framework?
In the following, I will go through our most important considerations.
Importing a huge framework just because you have one tiny feature doesn’t make any sense. Instead you should find a way to do it without a framework. One of the dangers of using a framework is that it forces you to think a certain way, while a specific problem might make more sense, if you look at it from a different perspective.
There will always be a new and faster framework becoming available, so when you go looking for benchmark tests you are going to get a lot of different results depending on the test tool used to perform the benchmark. To get a more accurate overview of how well a framework performs, go to DB Monster Repaint. Most cutting edge frameworks have an implementation here which allows you to check performance against each other. While a stress test like this gives you information, do not forget your use-case. Remember to always ask yourself questions like:
- How many permutations do you do at any one time?
- What is the worst case realistic scenario?
New frameworks mean learning new skills and new skills take time to develop. If the most complex framework based on a completely unknown programming language was outperforming everything else, you probably wouldn't and shouldn't use it. You must look at the skills you have inhouse as you will spend weeks getting to a point where you are able to build anything.
Vue is renowned for having a nice flat learning curve, this means you can have something working within a short time span. Angular and React are both known for having a much steeper learning curve, while neither is too difficult to get started with, it will take a lot more time to develop your skills to be able to use them effectively.
What do you get out of the box? What do you have to build yourself? This point feeds back to the one above. The most valuable resource is your own developing time and this is something you should always keep in mind. Keeping it mainstream and using a framework well supported by the opensource community will enable you to work with some complicated stuff with minimal effort. It also helps that you might not be the first developer to encounter a specific problem and the community is more likely to be able to help. This brings us to the next point.
Any framework is dependent on its contributors. When building software that will run for the next 10 years, going with the newest trendiest framework might be risky. Going with something that is more proven might be preferable, as there usually is a community behind it and it has reached a level of maturity that guaranties it will live up its promise. We looked into who was responsible for developing the frameworks we were considering for our new frontend. Is it a one-man army like Evan You (Vue)? Or is it a big corporation like Google (Angular or Polymor)? Or Facebook (React)? This might seem insignificant for some, but should Evan You one day decide he didn't want to continue developing the Vue framework, we might be stuck with outdated software. The chances Facebook will stop developing React seems far smaller.
As our approach is to develop and change very few components at a time, we need a framework that supports this. We need a framework which we can extend with packages as we need new functionality. For example: if we wanted to add static type checking into our application, we could simply incorporate the "Flow" package to provide this functionality.
As websites have evolved into web applications they have become more and more complex, this means that there is an even greater need for testing. Any respectable framework has some form of automated testing, while this testing suite might be sufficient, using a dedicated library is usually the better choice as it will provide a stricter testing environment.
We are rebuilding an existing project, which contains 10 years’ worth of legacy code. This code will continually be running in production while we “re-develop” the platform, as such we will gradually be replacing parts of the platform as development progresses. This brings in some extra complexity to the development process and means that we won’t be building an SPA (Single Page Application). So, our decision will require us to choose a framework that supports not building a SPA, that means Angular is out of the question. As we are building on Laravel’s backend, the community advocates using Vue, which in our use-case was found to be a great fit as it is small, fast and cutting edge. Even though Vue seems to be the clear choice it didn't suite our needs as well as React did. We reached this decision because React already has a well-established framework, a strong community and our team members were already familiar with React.