You have probably read one or more popular articles on front end technology choices with titles like Why SnackWoot switched from Angular to React. These case studies of Big Rewrites might make interesting reading, but they should come with a health warning that goes beyond 'your mileage might vary'.
Articles of this type usually present some explicit criteria that were used to make the decision, such as performance or documentation quality. Some also present the rational decision-making process by which the criteria were evaluated and the final choice made.
In reality, technology choices are made in wildly varying circumstances. They are influenced not just by explicit rational processes but depend on implicit personal and interpersonal factors that play out over a long period of time.
To make good choices, we need an approach that allows us to focus on the needs and constraints of our own users, product, team and organisation. The goal is not necessarily to make rational, correct decisions, but appropriate and sustainable ones.
In the user-facing parts of a modern product, change is the norm. Even in a mature product, user-facing changes happen at a much faster rate than in back end systems. A REST API changes more slowly than the client applications that are built around it. And the database schema is glacial by comparison.
What's more, the rapid development of the web platform creates even more pressure for continuous change - ajax, websocket and capable mobile devices in the past, and now offline support, progressive web apps and CSS grid, to name only a handful.
We know that change is a constant, but often do ourselves no favours by resisting it in our development practices.
The Big Problem that usually triggers a front end re-platform is the difficulty of making changes to the product. This is generally caused by software entropy and mounting tech debt, but the framework that was used often gets a big portion of the blame.
And in many cases a shining new framework is held up as The Solution to The Big Problem, at least in part.
But this is short-term thinking. How will we prevent the slow creep of software entropy and tech debt with our new framework? Does our choice of technology help us prevent it? Or are we just scratching the itch of the development team?
Shouldn't we instead be looking to continuously fix Small Problems using Small Solutions?
Since change is a given, we can apply lean principles to front end technology choices that support continuous improvement instead of trying to fix everything all at once with the latest framework.
Mary and Tom Poppendieck's book Lean Software Development: An Agile Toolkit presents a collection of 'lean principles and thinking tools' for software development. I've found three to be especially useful for guiding changes in UI design, architecture and tooling.
We know from experience that software development is an exercise in discovery. Agile and lean practices embrace this. But we often behave as if we're just delivering something that is already well known.
In the early stages of a product, we may know little about our customers, the problems we are trying to help them with, and how our product will do that. Yet it is common even at this early stage to settle on a set of technologies and stick with them throughout, long beyond their usefulness.
Choosing a framework early based on popularity and sticking with it implies that we know what problems it will help us solve, or that we think it is applicable to most problems that will come our way.
But if we are learning about customers, the product and business domain as we go, it implies a different approach. Why not learn about technology and approach in parallel with these efforts?
Instead of focusing on selection criteria and rational decision-making early on, aim to achieve a shared understanding of the constraints the team is working within and let the solution emerge from multiple experiments.
If product development is a continuous learning exercise, then it also helps to delay big, hard-to-change decisions as long as possible. You're more likely to make decisions informed by the specific facts of your product, rather than speculation, past experiences and personal preferences.
During the search for product-market fit, you won't want to lock yourself in to a single approach. Instead, seek disposability and flexibility so that you learn quickly. Look for good-enough, temporary, off-the-shelf solutions.
For more mature products, spend time to assess the suitability of different options against the constraints that you have learned about. Product development takes place over months and years. You should be able to justify short parallel development experiments in the name of 'technology fit'.
This doesn't mean you should over-analyse every single choice along the way. Where constraints are well understood, intuitive decisions based on expertise and experience are often better than rational, analytical approaches.
If you emphasise expertise over process then develop and empower your team so they can make informed decisions that affect them. Prescribing a supposedly rational collaborative decision-making process with checklists and weighted criteria has the veneer of autonomy but limits the impact of your teams' expertise over time.
It's not enough just to tell your team they have autonomy, either. Poppendieck and Poppendieck also emphasise the importance of enabling 'local signalling': making learning visible, holding daily meetings, integrating code frequently and testing comprehensively. The best scrum master I ever worked with spent most of his time creating an environment strong in local signalling.
High team autonomy means you have a chance of responding rapidly to change and building it into your working practices. It's the foundation for avoiding Big Rewrites.
Once, front end choices were limited. A default position existed: just use jQuery and get cracking. Most of the work of complex web applications was in the back end anyway.
But now, there is more choice in the JavaScript ecosystem than for any other programming language or platform.
With more of the product ending up on the browser-side, making these choices is no longer a trivial matter of little importance.
You need to give the front end as much care and attention as your back end systems, and ensure that your team is doing the same. So before you agree to 'just use React', resist the urge to choose now and encourage your team to take a more incremental, learning-based approach.