I've created a few hypothetical scenarios below that will hopefully illustrate the trade-offs that can arise when evaluating frameworks. They are loosely based on real situations I’m familiar with, and I’ll tell you now that there isn’t a “best” framework. It's about which one is best for your project and your team.
There is something called the project management triangle that will help frame our conversation. It’s illustrated in the graphic below:
The general idea is this:
- The quality of work is constrained by the project's budget, schedule and scope.
- There are trade-offs between constraints. For example, a shorter schedule will increase costs, reduce scope or lower quality — or some combination of those. If one thing changes, something else has got to give.
As we go through these scenarios, we’ll see how these trade-offs come into play with our choice of software. In particular, we’ll see how the framework we choose might impact cost, schedule or quality.
Nobody Ever Got Fired for Buying IBM
It’s understandable, too. Imagine you’re the one choosing the technology a large front end project will use. It has a budget of $750,000. Now look at the project management triangle above and note the bottom two corners — cost and schedule. If you're worried about keeping a handle on those two factors, which feels like a safer bet — choosing React or going with Svelte?
With React, you know there will be abundant training resources, lots of experienced developers available if you need to grow your team, and a large ecosystem that can help accelerate development. Those advantages can help you keep both the project on schedule and control costs. That safety explains why a lot of projects stick with React (and Angular), but as we’ll see, many — but certainly not all — would benefit from making other choices.
The Java Team Branching Out
Let’s imagine a hypothetical team of Java developers that are going to build a front end for a large project at their company. Yes, they’re back end devs, but they’re smart and have proven themselves on big projects before. Plus, they want to do the project. When upper management talked about bringing an agency in to help, the team lobbied against it. They could handle it in-house, they said.
This sort of thing actually happens, and when it does, it introduces some additional risks. The choice of framework here is important because choosing one that will slow the team down will likely blow up the schedule, and because they aren’t well-versed in front end, they’ll be slower anyway. Not good. Project schedules are fantastical enough as it is.
The team was aware of these risks, so they wanted to go with a well-established framework — the safety thing — and I don’t blame them. The two choices they narrowed it down to were React and Angular. Which one should they choose?
The Smart Choice
For this team, the choice is clear — Angular. There are a couple of reasons. The first is that React is famously, “just a view library”. There are going to be a lot of decisions that need to be made by this team if they pick React. Which state management solution will they use? What about routing, http, and everything else? Does anyone know how to configure webpack? With Angular, all of these decisions are made for you. One major obstacle averted.
Since this is a large project, this team will probably end up picking Redux as the state management library. Some people argue that paradigms don’t or shouldn’t matter that much. In my experience, however, they do matter. A team of Java developers will be very well-versed in object-oriented programming techniques. Redux, a functional library, will probably slow them down.
Paradigms like object-oriented or functional programming, help developers form mental models and shortcuts that they use to solve common problems more quickly and with fewer bugs. When you adopt a new paradigm, many of your shortcuts are gone and you may find yourself struggling with the new patterns and unfamiliar syntax.
The scenario outlined above is based on an article I read about a team of C# developers who took on a React/Redux project and struggled. Their big problems were understanding the patterns and best practices they should be using. If that team had chosen Angular, which generally encourages an object-oriented approach, I doubt they would have had as many difficulties. They would have been working in a familiar paradigm, with well-defined patterns, and with much of the required functionality provided for them.
The point here is that when picking a framework, the skills of your team matter, particularly if the schedule is tight. If your schedule is looser, experimenting can have some big advantages, but beware of the added risks.
The Need for Speed
Our next scenario involves a client services team that is experienced in building React applications. They have a good boilerplate that they can use to get off to a fast start and they are highly confident they can solve any problems that arise both quickly and effectively.
The client, however, has said that their highest priority is performance. The app has to load quickly and it has to perform well on slow mobile networks. Should they use React?
If we think back to our project management triangle, we feel confident that our team will be able to produce a React app on budget and on schedule. But what about the quality? That’s a slippery thing, isn’t it? Because what do we mean when we talk about quality? The app will no doubt be put together well. It will be a fine React application. But will it best meet the most important client criterion, performance?
You can definitely make a pretty fast React app. I do it regularly in my work at a client services agency. But you will be able to deliver more value — a higher quality product — in this case if you choose a different framework or library. Why is this so?
In recent years there have been a lot of case studies that demonstrate that even modest performance gains can give a big boost to important business metrics — conversion rate, revenue, time on site, and other measures. Basically, more money, donations or whatever else is important.
Addy Osmani published a case study a while back about a hotel chain in India that converted their site from React to a progressive web app (PWA) using Preact. Obviously a PWA is going to provide benefits beyond whatever framework you use, but the move to Preact, “…was responsible for a 15% improvement in time-to-interactive alone.”
Who wouldn’t want a 15% improvement in time-to-interactive? And if you’re not familiar with Preact, it’s a 3KB library with the same API as React and improved performance is its main selling point. Having the same API as React makes it very attractive and there is even a companion library called
preact-compat that allows you to use almost all libraries in the React ecosystem.
Some time after reading the case study from Addy, I saw this tweet from James Kyle:
Serious Q: How many of you can confidently give a reason for not replacing React with Preact in your app that doesn't amount to laziness?— Jamie (@jamiebuilds) January 17, 2018
Admittedly, James was drunk at the time of that tweet (his words, not mine), but I still think he had a pretty good point. There were some good answers as to why some folks needed React, but not many. I think James is wrong about it being down to laziness, however. It’s that IBM thing…the safe bet, the long track record.
Considering what we know about the benefits of performance, why not make it the top line consideration for all projects? Start with fast and let other considerations fight for the spot at the front of the line?
And this is not a bash on React! Preact exists because of React. And I’m just using Preact as an example here. You could go with Inferno, Svelte or perhaps a couple others.
The point in this scenario is that the safe bets — React, Angular and even Vue — come with a trade off. They aren’t the fastest frameworks. Are they fast enough? That depends on the project. They may very well be fast enough. There are also a lot of other considerations besides speed that may push their way to the top.
Imagine that our client in this situation wanted a very fast app, but the schedule was extremely tight. Maybe it’s even tied to a hard deadline like a television broadcast or music festival. I’ve worked on a project like that, and that changes things a bit, doesn’t it?
I’m sure you can think of many other complicating factors. The point here is that the safe bet isn’t always the best choice. Not prioritizing performance may leave some money on the table. Maybe a lot of money.
I Love Shiny Pennies
Next scenario. A client has come to me and they want a fast site, but they have a really tight deadline. I’ve seen the client’s analytics and I know they will get huge value if we build them the fastest site possible. I recommend Sapper.
What the hell is Sapper, you ask? Well, scenario aside, Sapper is a real framework built on Svelte. I have a bit of a crush on it. It’s shiny and new — and super fast. You can read more here, but the relevant point for our scenario is that Sapper is not a mature framework at this time.
As the deadline approaches, some problems arise. Perhaps Sapper has a few bugs that are slowing development. Maybe I don’t quite know what I’m doing with it because it’s new. Probably a bit of both. I’ve blown the schedule. I start to question my life choices and break into a cold sweat before every client call. I’ve descended into the fifth hell of software development and it’s entirely my own fault.
It's a very unpleasant scenario. This sort of thing happens, though. It’s part of the reason why people go with the safe bets. The point here is to balance performance with other factors — framework maturity, the experience you and your team have with it, among other factors. It can save you a lot of pain.
Big Fish, Little Fish
I know most of you reading this will choose one of the big three — React, Angular and Vue. That’s cool and I totally understand. They’re all great and I use React everyday at work. There are good reasons for choosing them. However, one point I hope you’ll take away from this discussion is that there are some lesser known frameworks out there that deserve more consideration than they get. And using them could yield some major benefits.
Hopefully the Sapper example didn’t traumatize you, because picking Preact or Inferno is actually pretty low risk for a React team, and they can deliver real gains. 💰 In time, I’m confident Sapper will be a great choice as well. If your deadline allows, using a spike to evaluate your options is time well spent.
Until next time, happy coding…