Choosing a user interface framework for a product that has to last ten years is a different problem from choosing one for a project that ships next spring. The spring project cares about features and developer happiness this quarter. The ten-year product cares about what the framework will be like in year seven, when none of the people who chose it are still on the team and the second rewrite is being argued about. Here is what I weigh.
The ecosystem is what you are actually choosing
The framework itself is a few hundred kilobytes of code. What a team adopts is everything around it: the component libraries, the testing tools, the build integrations, the answers on the internet, and above all the people who already know it. Over ten years the team will turn over more than once. Each new engineer either arrives knowing the framework or has to be taught, and the difference compounds.
So I weigh the ecosystem far above the feature list. A framework with a large, boring, well-staffed ecosystem is a safer ten-year bet than a better framework with a small one, because I am not choosing the code. I am choosing who I can hire in 2033.
The upgrade history predicts the upgrade future
Every framework will have major versions over a decade, and each one is a tax. The question is how large. I look at the framework's history: how it handled its last two or three majors, whether there were codemods, how long old versions were supported, and whether the community came along or split. A framework that has managed its upgrades gracefully before will probably do it again. One that has had a painful rewrite in its past, or that is young enough to have had none, is an unknown, and for a ten-year product unknown is a cost.
The escape hatches
At some point in ten years the framework will be wrong about something the product needs. Rendering in a place it was not designed for, integrating with something it does not know about, a performance case its abstractions fight. What matters then is whether there is a way out: a documented path to plain platform code, a boundary where the framework stops and the team's own code begins.
I weigh escape hatches heavily, and I am suspicious of frameworks that are elegant because they are total. The elegance is real in year one. The totality is the problem in year six.
The platform underneath
Ten years is long enough for the web platform itself to absorb a lot of what frameworks exist to provide. Native nesting, container queries, view transitions, and a dozen other things that were library features are now browser features. The framework that lasts is the one that gets thinner as the platform grows, delegating to the browser rather than competing with it. A framework that reimplements the platform is carrying weight the platform will eventually make pointless.
The team you have
The last factor is the one most often skipped. The framework will be used by the team that exists, with its skills and habits, not by the idealized team in the architecture document. A choice that requires everyone to learn a new paradigm is a choice to spend the first year of a ten-year product on learning, and some of that year's engineers will not stay for the payoff.
I think the honest move is to weigh the team's existing fluency as a first-class input. The best framework a team does not know is usually worse, over a decade, than the second-best one it does.
The decision
Weighed that way, the answer is usually boring, and I have made peace with that. A ten-year product is not the place to be interesting. It is the place to pick the thing that will still have a community, an upgrade path, and a hiring pool when everyone in the room has moved on, and then to spend the saved energy on the product.
Photo source: https://photos.robertstowe.com/new-mexico