Around 2010, it became clear that the browser would become the central runtime environment for business applications. At the same time, it became apparent that tools like jQuery were insufficient for complex, maintainable enterprise systems. A new generation of frameworks emerged. AngularJS focused on structure and conventions, React on a strictly functional approach with unidirectional data flow.
The crucial question in large-scale projects, however, was and rarely is just which framework is chosen, but above all who makes the selection – and with what motivation.
The Deceptive Safety of Big Names
In many companies, the choice of framework is not made by the architects who ultimately have to take responsibility for the system. It often lands with IT managers and decision-makers. Their primary driver is rarely technical excellence, but rather risk minimization and resource planning. The old mantra "Nobody gets fired for buying IBM" applies today to names like Google, Microsoft, or Vercel.
Decisions are often made according to the logic: "If we take the market standard, it will be easier to find service providers and developers." Long-term maintainability, functional composition, or the actual fit for one's own domain take a back seat. Familiarity creates a deceptive feeling of safety. The consequences of this approach usually only become apparent years later, when the initial teams have long since moved on.
Angular 2 as a Cautionary Tale
Google announced a complete rewrite of Angular in 2014. The final version was not released until 2016. In the meantime, numerous enterprise projects were already starting on unstable release candidate versions, driven by the promise of the "Google standard." Particularly problematic was the late introduction of NgModule, which forced many teams to fundamentally rebuild their architecture – even though they thought they were already in the stabilization phase budget-wise.
For some huge, extremely well-structured projects, Angular 2 worked. For many others, it became a cost trap: too complex, too many proprietary concepts, and massive onboarding effort. The irony: Part of the scaling problems that Angular was supposed to solve were co-caused by its politically motivated, premature introduction.
The Real Problem Lies Deeper
The most expensive enterprise projects do not fail because of the framework itself. They fail because the wrong metrics dictate the architecture – and because no one has the authority to consistently correct misdevelopments.
Typical patterns in corporate structures are:
Recruiting over Architecture: A framework is chosen because the market currently offers many (average) developers for it, not because it is the best tool for the requirements.
Delayed Refactoring: Technical debt is postponed for deadline or political reasons until it is structurally almost impossible to resolve.
Toothless Responsibility: The responsibility for technical sustainability lies with architects, who, however, have no real budget or decision-making authority over the business.
Agile Theater: Agility is confused with "delivering features fast," while the functional foundation crumbles under sprint pressure.
Once a project is running and the business makes new demands, it becomes politically extremely difficult to fix fundamental architectural flaws. Technical debt grows exponentially. The longer you wait, the higher the bill will be.
The Framework Wars Are Not Over
Anyone who thinks the days of big framework debates are over only needs to look at the current architectural discussion in 2026 between Next.js and TanStack Start. The lines of argument are astonishingly similar to those of ten years ago.
Next.js has established itself as the de facto standard for many React applications. It delivers an extremely strong Developer Experience, but buys this with a lot of "magic," deep conventions, and a clear platform strategy: Those who choose Next.js optimize heavily for the Vercel infrastructure. For the enterprise environment, this often means a creeping vendor lock-in.
On the other side is TanStack Start. Instead of black-box automation, it prioritizes explicit control and a consistent, type-safe architecture. The decisive business factor here, however, is a different one: Investment protection and deployment freedom. By forgoing deep proprietary conventions, the architecture remains agnostic. Applications can be run seamlessly and cost-efficiently on modern edge infrastructures like Cloudflare Workers or R2.
Both approaches have their merit. The problem is that even in 2026, the choice is again often made based on visibility and the deceptive feeling that "this is currently the standard" – instead of strategically evaluating whether the company needs scalability through functional composition (TanStack) or fast time-to-market through platform binding (Next.js).
What Needs to Change
Technical decisions with a long-term impact must not be made primarily based on marketing, short-term resource availability, or internal power dynamics. They require strategic foresight and the willingness to present uncomfortable truths to the business.
Specifically, this means for the enterprise environment:
Make Architecture Costs Transparent: Whoever chooses the convenient "standard path" must also take budgetary responsibility for the long-term costs of lock-in and infrastructure. Technical debt must be quantified in euros.
Real Architectural Authority: Strategic technology decisions must be approved by individuals with actual project experience. Architects need a veto right that is respected by management.
Independent Evaluation: Larger projects require a neutral proof of concept before starting, which validates the specific domain requirements – independent of the colorful landing pages of framework providers.
As long as companies do not establish these structural foundations, they will continue to make expensive, half-knowledge-driven technology decisions – and get the bill for it years later.