How do you choose a framework?
The useful question is not which framework is best but who will maintain it in three years. A technology nobody in the area knows ties you to the supplier who chose it. Test the two or three candidates on the hardest part of the real project: two days decide more than two weeks of comparison tables.
“Which framework is best” has no answer, and anybody who gives you one is describing their own habits. The question that does have an answer is different: which framework makes this project maintainable, in this company, in three years.
Why the choice weighs more than it looks
A framework is not a library you swap out: it decides how the code is organised, how tests are written, who you can hire, and what every change costs for the life of the system.
It is a choice made once and paid for over years. So it is made by looking at what comes after, not at the comfort of the first month.
The criteria that matter
Who will maintain it. The first criterion, and almost always the last one discussed. A technology nobody in the area knows ties you to the supplier who chose it. If one day you want to bring the software in house or change supplier, the question becomes: how many hireable people can work with it?
How many years it has ahead. An industrial project stays in service for ten years. A framework born last year, however elegant, is a bet on something that may not be there.
Documentation and community. Not for fashion: because when a release breaks at two in the morning, the difference between a problem a thousand people have already discussed and one nobody has ever seen is measured in hours.
What the software has to do. A dashboard refreshing live data, an ERP with modules and permissions, and a shop-floor app used with gloves are three different problems. The criterion is which framework makes the thing you will do most often simple.
How it integrates. If the software has to talk to a fifteen-year-old ERP, the right question is how easy that connection is to write and maintain, not how modern the framework is.
Performance, but measured. On the computers you actually have, not on developers’ laptops. A shop-floor display and a rugged terminal are not a MacBook.
Three choices, not one
“The framework”, singular, does not exist: a project involves at least three, chosen on different criteria.
The one for what people see. React is the most widespread, so the easiest to hire for; Angular brings more structure and suits large systems with several teams; Vue sits in between and is the quickest to learn; Svelte produces the lightest code, with a smaller community. On a shop-floor dashboard the real question is not which is more elegant: it is which weighs least on the screen you have in the plant.
The one for what people do not see. Node with Express if the team already writes JavaScript and one language is worth having; Django when you need an admin panel and a well modelled database early; Laravel and Symfony in the PHP world; Spring and .NET when the company already runs on Java or Microsoft, and in that case fighting it is a battle not worth having.
The one for the phone, if needed. Here the real choice comes first: native, web app, or installable. The framework comes after.
The criterion that decides most often
What the company already uses.
If you have an IT department that knows .NET, a project in Django will be more elegant and harder to keep alive. Consistency with what is already there is worth more than the technical superiority of an isolated choice, and that holds even when the “right choice on paper” is a different one.
How to test a framework in two days
Comparison on paper decides nothing: every framework looks adequate until it meets your problem. The test has to be done, and it is cheap if done well.
Take the hardest part of the real project (not an example, not a to-do list) and build it with each of the two or three remaining candidates. If the hard part is reading from the AS/400, test that. If it is a dashboard refreshing five hundred rows a second on a plant display, test that.
Then look at four things: how much code it took, how readable it is to somebody else, how long the team took to find their feet, and what happened when something broke (how easy it was to understand why).
Two days of testing are worth more than two weeks of comparison tables, and it is the only form of comparison that accounts for the people you have.
What should not be part of the decision
- Fashion. A framework popular this year can be abandoned in three. Popularity matters only as availability of people and documentation.
- The curiosity of whoever writes the code. Legitimate, and worth feeding, but a system that stays in service for ten years is chosen on other grounds.
- Published benchmarks. They measure artificial cases. Your bottleneck will almost always be the database or the integration, not the framework.
- “A big company uses it.” With problems, teams and budgets that are not yours.
The criterion usually missing
Ask whoever proposes a framework what its drawbacks are. Somebody who cannot answer has not chosen it: they are just using it.
Every technical choice has a price. A supplier who tells you the price up front is the same one who will tell you when something is going wrong during the project.
How we choose
Widely adopted, well documented tools, chosen with an eye on whoever maintains the system after us. We keep the unusual choices for the places they earn: data acquisition, performance under load, working without a network.
And in any case the source code is yours from day one: the choice of framework must never become a way of keeping you.
Get in touch, or read our method.