¿Por qué todos usan React, y nosotros no necesitamos usarlo? - La historia de la guerra frontend y el nacimiento de Hotwire
Cuando escuchas historias sobre desarrollo web últimamente, siempre escuchas las mismas cosas.
"El frontend debe hacerse con React."
"Todos usan React en estos días."
"Si no aprendes React, no serás un buen desarrollador."
¿Pero es realmente así?
No, para ser precisos, es solo medio cierto.
Es cierto que React es una buena biblioteca.
Pero el problema es...
La "situación en la que se necesita" React es solo alrededor del 10-20% de todos los servicios web.
Y sorprendentemente,
la mayoría de los servicios creados por desarrolladores de Rails
no entran en ese 10-20%.
1. Muchas bibliotecas cayeron en la batalla antes de que React se estableciera
Hay un hecho que los desarrolladores novatos no conocen bien.
React no fue siempre el "indiscutible" desde el principio.
Muchos frameworks y bibliotecas que existían antes de React
casi han desaparecido ahora.
AngularJS (muerto)
Ember.js (a punto de morir)
Backbone.js (casi desaparecido)
Knockout.js
ExtJS
Capa frontend de Meteor
jQuery + frameworks SPA
Mithril, Riot, Preact...
El ecosistema frontend
fue una guerra en la que más de 100 tecnologías surgieron en 10 años, y el 98% desapareció.
La razón por la que solo React sobrevivió es grande:
Tenía una estructura relativamente buena.
Era relativamente fácil de mantener.
Fue adoptado por empresas.
Pero esto también significa que React eventualmente desaparecerá.
Porque la esencia de la tecnología frontend siempre es la misma.
2. React se está volviendo más grande y complejo (en la realidad)
Al principio, React era realmente simple.
"La interfaz de usuario es una función del estado."
Pero, ¿qué ha pasado con React ahora?
React
ReactDOM
JSX
Babel
Webpack
Vite
Next.js
Zustand
Redux
Suspense
Componentes del servidor
hidratación
límite cliente/servidor
streaming
enrutamiento
empaquetador
renderizado basado en compilador...
Todas estas cosas
se han convertido en "discusiones esenciales" dentro del ecosistema de React.
React ya no es solo una simple biblioteca.
React se ha convertido en un mundo complejo por sí mismo, y cada año se vuelve más difícil.
¿Qué problemas surgen de esto?
Aumento drástico de la barrera de entrada para nuevos desarrolladores.
Si no todo el equipo es experto en React, la dificultad de mantenimiento aumenta drásticamente.
La velocidad inicial del proyecto disminuye drásticamente.
Mientras que el servidor es simple, el frontend se convierte en la causa principal de la complejidad.
Y surge esta pregunta.
"¿Realmente necesito React para mi servicio?"
3. La mayoría de los SaaS y servicios web no necesitan React
Las situaciones en las que se necesita React son principalmente dos:
SPA complejas en las que la interfaz de usuario cambia continuamente en tiempo real
(por ejemplo: Figma, Slack (Web), Notion, Trello, etc.)Proyectos ultragrandes que requieren organizaciones frontend a gran escala y colaboración entre múltiples equipos
Pero, ¿qué pasa con los servicios creados por desarrolladores de Rails?
Servicios CRUD
Tableros de control
Blogs
Comunidades
Servicios centrados en la búsqueda de datos
Servicios centrados en formularios
Gestión de clientes
Herramientas internas
SaaS
Oficinas de comercio electrónico
Estos servicios
no necesitan ni siquiera la mitad de las funciones de React.
Y al usar React,
la velocidad de desarrollo disminuye
y la complejidad aumenta drásticamente.
4. La tecnología que surgió en este contexto es Hotwire
Hotwire es la pila tecnológica propuesta por el equipo de Rails
y se basa en esta filosofía.
"El 80% del frontend no necesita ser tan complejo como React."
La configuración de Hotwire es simple:
Turbo (transmisión de HTML + actualizaciones parciales)
Stimulus (un motor de JavaScript pequeño)
Cable + Streams (en tiempo real)
Pero lo más importante es esto.
Actualizar el HTML en sí mismo es la forma más rápida, fácil y mantenible en la mayoría de los servicios web.
A diferencia de React,
no hay un proceso complejo de estado → diferencias → renderizado → hidratación...
Hotwire sigue la filosofía de Rails:
Simplicidad
Productividad
Velocidad de iteración
Mantenibilidad
Código mínimo
Felicidad del desarrollador
Y la realidad sorprendente es:
Cuando lo pones en práctica, Hotwire es tres veces más rápido que React,
el volumen de código es aproximadamente un quinto,
y los errores disminuyen dramáticamente.
5. Razones para no usar React - Hotwire ya lo ha resuelto
De los 10 problemas que React intentaba resolver,
Hotwire resuelve 7-8 de ellos de manera orientada al servidor.
Por ejemplo:
| Problema | Enfoque de React | Enfoque de Hotwire |
|---|---|---|
| Actualización de la interfaz de usuario | cálculo de diferencias → renderizado | El servidor simplemente envía fragmentos de HTML |
| Gestión de estado | Redux/Zustand | Estado del servidor = Estado de la interfaz de usuario |
| Enrutamiento | Enrutador frontend | Optimización de la navegación de páginas con Turbo |
| Tiempo real | WebSocket + renderizado del cliente | Actualización directa de HTML con Turbo Stream |
| SEO | Configuración separada | Renderizado 100% en el servidor |
| Construcción | Babel/Webpack/Vite | Ninguno (¡Sin construcción!) |
| Complejidad | Altamente complejo | Baja |
Hotwire aumenta drásticamente la productividad de los desarrolladores de Rails.
6. Entonces, ¿qué pasará con React? Eventualmente desaparecerá. Casi con certeza.
Porque la historia del frontend ha sido repetitiva.
- Al principio, una biblioteca de UI simple → Se vuelve cada vez más grande en funcionalidad → Se vuelve más compleja → La organización no puede mantenerla → Otra tecnología emerge → Se produce un cambio generacional
React también está siguiendo este camino.
De hecho, ya se están viendo signos.
Los Componentes del Servidor de React son demasiado complejos y los desarrolladores se están rebelando.
Problemas de rendimiento
Next.js está liderando las reglas de React (el núcleo de React ya no es independiente)
Aparición de competidores (Solid, Qwik, Svelte, HTMX, etc.)
Resurgimiento de la tendencia "Sin construcción + web centrada en el servidor"
De hecho, los desarrolladores ahora están diciendo:
"El web se ha vuelto demasiado complejo. Necesitamos volver a la simplicidad."
Esta tendencia siempre ha sido correcta históricamente.
Mainframe → PC (regreso a la simplicidad)
SOAP → REST (regreso a la simplicidad)
Época de jQuery caótica → React (regreso a la simplicidad)
SPA complejas → Hotwire/HTMX (regreso a la simplicidad)
React eventualmente desaparecerá. Es solo una cuestión de "cuándo".
Conclusión - No elegimos tecnología, elegimos dirección
No se trata de no aprender React.
Cuando sea necesario, definitivamente deberías usar React.
Pero la mayoría de los servicios no necesitan React. Al usar tecnologías complejas, la velocidad disminuye y el mantenimiento se vuelve difícil.
Rails + Hotwire dicen lo siguiente:
"La web debería ser simple desde el principio.
El servidor envía HTML, el navegador lo muestra.
Toda la complejidad se agrega solo cuando es necesario."
Esta filosofía
se ajusta perfectamente al enfoque de desarrollo en la era de la IA.
Especialmente para principiantes, hay una fuerte razón para usar Hotwire.
Rápido
Fácil
Claro
Menos errores
Estado del servidor = Estado de la interfaz de usuario
Sin sistema de construcción
Fácil de mantener
Óptimo para desarrolladores individuales
Y la frase más importante:
Hotwire es una tecnología que durará mucho más que React. La filosofía de Rails ha resistido 20 años y no cambiará en el futuro.