- Una comparación entre Backbone a inicios de los 2010 y React en 2025, repasando cuánto ha avanzado realmente el frontend en 15 años
- React parece conciso y moderno en la superficie, pero internamente aparenta simplicidad mediante una compleja capa de abstracción
- Backbone es verboso, pero su flujo de eventos y manipulación del DOM son explícitos, así que incluso un desarrollador principiante puede seguir fácilmente cómo funciona
- En React, por temas como manejo de estado, arreglos de dependencias y problemas de closures, depurar se vuelve difícil si no se entiende su funcionamiento interno
- Al final, se vuelve a la esencia de “eventos + estado = UI” y se plantea la necesidad de un nuevo modelo con una estructura simple y hackeable
15 años de progreso
- Un ejemplo de campo de entrada de contraseña escrito con un framework de los 2010 (Backbone) y otro con React tras más de 10 años de evolución
- Ambas implementaciones tienen una longitud similar y la misma funcionalidad
- React ha contado con el apoyo de enormes ecosistemas y una inmensa inversión de tiempo de desarrollo
- Aun así, el autor señala que más interesante que “cuánto mejoró React” es “qué tan poco ha avanzado”
- React ofrece una ilusión de simplicidad superficial, pero en realidad eleva la dificultad de comprensión por sus abstracciones complejas
- Backbone expresa de forma explícita un flujo simple: ocurre un evento → se ejecuta el handler → se genera HTML → se inserta en el DOM
- En cambio, React oculta el funcionamiento interno y, al pasar de ejemplos simples, aparecen problemas que solo pueden resolverse entendiendo sus mecanismos internos
La ilusión de simplicidad (The Illusion of Simplicity)
- El código de React se ve limpio, pero eso es el resultado de elegir complejidad abstracta en lugar de simplicidad explícita
- Backbone es más verboso, pero muestra con claridad “qué pasa y cuándo pasa”
- Incluso un desarrollador principiante puede seguir con facilidad el flujo del código
- En React, el estado interno y la lógica de renderizado están ocultos, así que aparecen con frecuencia bugs inesperados
- Ejemplo: si la
key de un elemento de una lista se cambia por el índice, React lo interpreta como un componente distinto y reinicia su estado
- Si
value cambia a undefined, ocurre una transición de componente no controlado → controlado y el valor ingresado se reinicia
- También es común el problema de los bucles infinitos al usar
useEffect
- Si el arreglo de dependencias incluye un objeto creado de nuevo en cada render, React lo detecta como un cambio
- Para evitarlo, hace falta estabilizar identidades con
useMemo y useCallback
- Eso agrega la carga de tener que preocuparse por conceptos que antes no era necesario considerar
- También existe el problema de que un handler de click haga referencia a un estado desactualizado (stale state)
- Porque la función captura el estado del momento en que fue creada
- La solución es poner el estado en el arreglo de dependencias o usar actualizaciones funcionales como
setState(x => x + 1)
- Pero ambos métodos se sienten como parches temporales (workarounds)
El precio de la magia (Magic Has a High Price)
- Estos problemas no son casos excepcionales, sino problemas comunes que suelen aparecer en apps de tamaño medio o mayor
- Para depurar, hace falta entender el algoritmo de reconciliación (reconciliation algorithm), la fase de render (render phase) y el scheduler (batch update)
- React es una estructura que “funciona aunque no sepas por qué”, pero cuando algo falla, solo puedes resolverlo si entiendes su interior
- La complejidad es tal que existe la idea de que “para entender React de verdad, hay que construirlo uno mismo”
- Existen tutoriales como “Build your own React”
- Pero que para crear un simple validador de contraseñas haya que entender virtual DOM, prioridades de scheduling y renderizado concurrente deja una implicación crítica
- Backbone y jQuery tienen una estructura honesta y hackeable
- Se puede revisar y modificar directamente el código fuente
- Al estar basados en métodos del DOM, son fáciles de entender y extender
- En cambio, la capa de abstracción de React dificulta acceder y modificar su interior
¿Cuál es el siguiente paso? (So, What's Next?)
- En última instancia, tanto React como Backbone son intentos de resolver el mismo problema: “eventos + estado = UI”
- En apps grandes, la complejidad de React puede estar justificada, pero para la mayoría de las apps pequeñas y medianas es una carga excesiva
- Hace falta un nuevo modelo de UI con simplicidad y transparencia
- Un sistema tan sólido como el DOM, pero intuitivo
- Que apunte a una estructura comprensible y modificable de inmediato, como Backbone o jQuery
2 comentarios
En apps pequeñas o medianas, en vez de Backbone o jQuery, parece que una mejor forma de prepararse para lo que viene es diseñar clases de JavaScript.
Tener que volver a memorizar y avanzar con las plantillas de jQuery o Backbone se siente como una regresión.
Comentarios en Hacker News
He usado Backbone, Angular 1, Ember y React
No hay que pasar por alto por qué React se volvió popular. React resolvió problemas crónicos de los frameworks anteriores en composición de componentes, manejo de eventos, gestión de estado y actualizaciones eficientes del DOM
Backbone tenía una gestión compleja del ciclo de vida del DOM, y como los event handlers debían especificarse como cadenas, era difícil de mantener. React simplificó estos problemas con el flujo de estado unidireccional y el DOM virtual
Si hoy quisiera usar JS puro, creo que una solución de plantillas como lit-html sería mucho mejor que Backbone
El frontend era complejo antes y sigue siéndolo ahora, pero ahora duele mucho menos
La complejidad de una app no viene de la cantidad de componentes, sino de la gestión del estado
Por el flujo de datos bidireccional de Backbone Store, con frecuencia tuve problemas de UI congelada. La innovación de React fue la arquitectura Flux centrada en el flujo de datos unidireccional
Creo que un buen framework es una herramienta que te lleva de forma natural al “Pit of Success”. React ha cumplido bien ese papel
Por ejemplo, problemas como stale closure, bucles infinitos de useEffect y reinicio de inputs por cambios de key no existían en Backbone
Los problemas de Backbone eran visibles y fáciles de depurar, pero los de React están escondidos detrás de la abstracción
Como la mayoría de las apps no son del tamaño de Facebook, un enfoque explícito y simple podría ser mejor
Dar por hecho que una tecnología popular es “mala” parece una especie de arrogancia ingenua
Claro, la popularidad no garantiza calidad, pero asumir que los grandes ingenieros de todo el mundo fueron engañados ya es demasiado
Si las grandes empresas y el marketing la empujan, los CTO la adoptan, y si la carrera de uno está en juego, nadie va a decir “esto no está tan bueno”. Popularidad ≠ idoneidad
React no ganó solo por superioridad técnica, sino también por el marketing de Facebook y el auto-refuerzo de su ecosistema
Incluso después de 15 años, la longitud y la complejidad del código no se han reducido mucho. Solo se volvió complejidad de otra clase
Mirar al pasado no es por nostalgia, sino para revisar si agregamos complejidad desproporcionada
La web sigue pareciendo el lejano oeste de los patrones de diseño. Cuando lo acepté, me quedé más tranquilo
Al final, en cada proyecto hay que reevaluar los trade-offs
La afirmación de que “React no hace falta para cosas simples” es una falacia común sobre React (React fallacy)
Evaluar React con ejemplos simples es como “evaluar un lenguaje por la longitud de Hello World”
La razón para usar React incluso en cosas simples es que también se usa en cosas complejas. Un conjunto de herramientas consistente favorece el mantenimiento
Backbone era “algo que parecía framework, pero en realidad era un montón de código adhesivo”
La verdadera victoria de React fue que ya no hacía falta manipular el DOM directamente y que permitió gestión reactiva del estado. Esas dos cosas elevaron mucho la productividad del desarrollo
Enlace a un tutorial viejo, versión archivada
Hoy me interesa más cómo entiende el código un LLM. Una sintaxis declarativa como JSX es amigable para los LLM
Pero desde useEffect en adelante, React me parece más borroso en términos de expresividad y explicitud
Queda muy claro por qué React se volvió popular
El código de React es en su mayoría JS y HTML puros, y el núcleo es solo
useState. Es intuitivo y se puede entender incluso sin documentaciónBackbone dependía de selectores en cadena como
.space-y-2, así que el mantenimiento era un infierno. Si cambiabas un nombre de clase, se rompía la mitad de la appReact resolvió ese problema de forma estructural
En el código de Backbone está claro “qué pasa y cuándo pasa”, pero con React hay que entender cómo funciona internamente
Yo también leí varias veces la guía de Dan Abramov sobre useEffect y el blog de Mark Erikson para entender en qué momento actúa React
El código de Backbone lo entendí al instante incluso al volver a verlo 10 años después
Hace 6 años movimos al equipo de Backbone a Angular
Backbone era intuitivo y sin magia, así que era bueno para juniors, pero al final TypeScript y Angular eran más sistemáticos
Ahora usamos NG20 y estamos satisfechos. Si algún día el navegador ofrece más funciones de forma nativa, tal vez podamos volver a un enfoque más simple
Siempre estamos programando sobre abstracciones
Lo importante es si esa abstracción da ganancias de productividad frente a la complejidad y si es confiable
Incluso en el peor caso, debe poder depurarse
El campo de entrada de React maneja el comportamiento de Undo de forma más natural que Backbone
Backbone deshace letra por letra, mientras que React deshace por palabras