Alrededor de 2010, quedó claro que el navegador se convertiría en el entorno de ejecución central para las aplicaciones empresariales. Al mismo tiempo, se hizo evidente que herramientas como jQuery eran insuficientes para sistemas empresariales complejos y mantenibles. Surgió una nueva generación de frameworks. AngularJS se centró en la estructura y las convenciones, React en un enfoque estrictamente funcional con flujo de datos unidireccional.
La pregunta crucial en proyectos a gran escala, sin embargo, era y rara vez es solo qué framework se elige, sino sobre todo quién hace la selección, y con qué motivación.
La engañosa seguridad de los grandes nombres
En muchas empresas, la elección del framework no la toman los arquitectos que en última instancia tienen que asumir la responsabilidad del sistema. A menudo recae en los gerentes de TI y los tomadores de decisiones. Su principal motivación rara vez es la excelencia técnica, sino la minimización de riesgos y la planificación de recursos. El viejo mantra "Nadie es despedido por comprar IBM" se aplica hoy a nombres como Google, Microsoft o Vercel.
Las decisiones a menudo se toman de acuerdo con la lógica: "Si tomamos el estándar del mercado, será más fácil encontrar proveedores de servicios y desarrolladores". La mantenibilidad a largo plazo, la composición funcional o el ajuste real para el propio dominio pasan a un segundo plano. La familiaridad crea una engañosa sensación de seguridad. Las consecuencias de este enfoque generalmente solo se hacen evidentes años después, cuando los equipos iniciales ya se han ido.
Angular 2 como cuento con moraleja
Google anunció una reescritura completa de Angular en 2014. La versión final no se lanzó hasta 2016. Mientras tanto, numerosos proyectos empresariales ya estaban comenzando con versiones candidatas inestables, impulsados por la promesa del "estándar de Google". Particularmente problemática fue la introducción tardía de NgModule, que obligó a muchos equipos a reconstruir fundamentalmente su arquitectura, a pesar de que creían que ya estaban en la fase de estabilización en términos de presupuesto.
Para algunos proyectos enormes y extremadamente bien estructurados, Angular 2 funcionó. Para muchos otros, se convirtió en una trampa de costos: demasiado complejo, demasiados conceptos propietarios y un esfuerzo masivo de incorporación. La ironía: parte de los problemas de escala que Angular suponía resolver fueron causados, en parte, por su introducción prematura y políticamente motivada.
El problema real es más profundo
Los proyectos empresariales más caros no fracasan por el framework en sí. Fracasan porque las métricas equivocadas dictan la arquitectura, y porque nadie tiene la autoridad para corregir consistentemente los malos desarrollos.
Los patrones típicos en las estructuras corporativas son:
Contratación (Recruiting) sobre Arquitectura: Se elige un framework porque el mercado actualmente ofrece muchos desarrolladores (promedio) para él, no porque sea la mejor herramienta para los requisitos.
Refactorización retrasada: La deuda técnica se pospone por razones de plazos o políticas hasta que es estructuralmente casi imposible de resolver.
Responsabilidad sin dientes: La responsabilidad de la sostenibilidad técnica recae en arquitectos que, sin embargo, no tienen un presupuesto real ni autoridad para tomar decisiones frente al negocio (Business).
Teatro Ágil: La agilidad se confunde con "entregar características rápidamente", mientras que la base funcional se desmorona bajo la presión de los sprints.
Una vez que un proyecto está en marcha y el negocio hace nuevas demandas, se vuelve políticamente muy difícil arreglar fallas arquitectónicas fundamentales. La deuda técnica crece exponencialmente. Cuanto más espere, mayor será la factura.
Las guerras de frameworks no han terminado
Cualquiera que piense que los días de los grandes debates sobre frameworks han terminado, solo necesita mirar la discusión arquitectónica actual en 2026 entre Next.js y TanStack Start. Las líneas de argumentación son asombrosamente similares a las de hace diez años.
Next.js se ha establecido como el estándar de facto para muchas aplicaciones de React. Ofrece una Experiencia de Desarrollador extremadamente fuerte, pero compra esto con mucha "magia", convenciones profundas y una estrategia de plataforma clara: quienes eligen Next.js optimizan fuertemente para la infraestructura de Vercel. Para el entorno empresarial, esto a menudo significa una dependencia del proveedor (vendor lock-in) progresiva.
En el otro lado está TanStack Start. En lugar de automatización de caja negra, prioriza el control explícito y una arquitectura consistente y de tipado seguro. El factor de negocio decisivo aquí, sin embargo, es otro: protección de la inversión y libertad de despliegue. Al renunciar a convenciones propietarias profundas, la arquitectura permanece agnóstica. Las aplicaciones se pueden ejecutar sin problemas y de manera rentable en infraestructuras edge modernas como Cloudflare Workers o R2.
Ambos enfoques tienen su mérito. El problema es que, incluso en 2026, la elección se hace a menudo nuevamente sobre la base de la visibilidad y el sentimiento engañoso de que "este es actualmente el estándar", en lugar de evaluar estratégicamente si la empresa necesita escalabilidad a través de la composición funcional (TanStack) o un tiempo de comercialización rápido a través de la vinculación a la plataforma (Next.js).
Lo que tiene que cambiar
Las decisiones técnicas con un impacto a largo plazo no deben tomarse principalmente sobre la base del marketing, la disponibilidad de recursos a corto plazo o la dinámica de poder interna. Requieren visión estratégica y la voluntad de presentar verdades incómodas al negocio.
Específicamente, esto significa para el entorno empresarial:
Hacer transparentes los costos de arquitectura: Quien elija el "camino estándar" conveniente también debe asumir la responsabilidad presupuestaria de los costos a largo plazo del lock-in y la infraestructura. La deuda técnica debe cuantificarse en euros.
Verdadera autoridad arquitectónica: Las decisiones tecnológicas estratégicas deben ser aprobadas por personas con experiencia real en proyectos. Los arquitectos necesitan un derecho de veto que sea respetado por la gerencia.
Evaluación independiente: Los proyectos más grandes requieren una prueba de concepto (Proof of Concept) neutral antes de comenzar, que valide los requisitos específicos del dominio, independientemente de las coloridas páginas de aterrizaje de los proveedores de frameworks.
Mientras las empresas no establezcan estas bases estructurales, seguirán tomando decisiones tecnológicas costosas e impulsadas por el conocimiento a medias, y recibirán la factura por ello años después.