Versus: React vs Angular 2.

Jonathan Barroso

Sabemos que vamos a comparar una librería como React con un framework como Angular, pero Arturo ¿por qué elegir un paquete completo si puedes elegir sus piezas?, ¿cuántos de aquí prefieren montarse su ordenador a comprar uno creado? ¿más cómodo el paquete?, quizás, ¿mejor?, no lo creo.

Al elegir una librería como React y no un framework con todas las soluciones incluidas, tenemos mayor libertad. No es un único equipo, en este caso Google, el que decide qué necesita nuestro proyecto y somos nosotros mismos los que, añadiendo otras librerías, conseguimos la arquitectura correcta o deseada.

¿El tamaño importa? En ocasiones sí, los 139k de React con React Dom y Redux son difíciles para competir, ahí teníamos a AngularJS y sus 143k que podía plantarle cara en este aspecto. Pero ahora nos sueltan Angular2 y ¡sorpresa! 566k y si le metemos Rx se pone en 766k, casi nada, póngame dos de React que me sale más barato, oiga... No Arturo, Angular no es un exclusivo Ferrari, es un tanque consumiendo 230 litros a la hora...

Hablemos de comunidad, en España está muy popularizado Angular, ¿pero qué ocurre en el resto del mundo? El resultado en GitHub es que React dobla a la comunidad de Angular, por algo será… Y algo que también nos interesa, es que React tiene más documentación y nos ofrece ejemplos de problemas que nos podamos encontrar a la hora de programar ya resueltos por otros. Algo de lo que vais a carecer vosotros, sobre todo si cada pequeña versión de Angular sigue cambiando tanto de una a otra.

El código de Angular 2 deja obsoleto el código de Angular.js. Si dices, Arturo, que a mi cliente le va a dar la risa cuando le diga que no puede hacer una red social por temas de licencia, ya verás lo que se ríe cuando le digas que hay que rehacerlo todo de nuevo para seguir abrazando Angular y modernizarse.

Además, si JavaScript es más poderoso que HTML ¿no sería lógico, Arturo, escribir este último dentro de JavaScript y no al revés? Ya ni hablamos de tener la lógica distribuida entre el HTML y el JS, lo complejos y poco prácticos que se hacen los proyectos que son así llevan al punto de que alguien del equipo de mantenimiento piense en suicidarse.

Luego tenemos el vocabulario de Angular 2, todo ese lenguaje propio que tienes que aprender para poder usarlo: ngIf, ngFor, ngClass… ¿en serio? Es como si tuvieras que escribir un libro pero hacerlo en castellano antiguo, vale que eres un poco mayor que yo, pero tampoco te veo queriendo aprender castellano antiguo.

Si sabes JavaScript, sabes React, algo sencillo y sin añadir cosas raras. Además te sirve para crear apps nativas con React Native, algo ya probado y con buena documentación, no como los recién llegados de NativeScript e Ionic2 que aún están por demostrar.

Ahora sube al estrado TypeScript (por si no teníamos suficientes con las directivas de Angular). Aquello que Angular dice que no es obligatorio, pero si no lo usas... suerte a la hora de buscar documentación. Vale sí, el código tipado es útil pero un código tipado no te garantiza la ausencia de bugs, este puede tener gran cantidad de errores en la programación, además de la cantidad de código que te obliga a escribir perdiendo tiempo, inmensamente mayor en comparación a los bugs que soluciona, sólo te crea una falsa sensación de control, control que con un TDD o un code review consigues de manera más eficaz.

Pero si después de esto no estáis convencidos, vamos con el plato fuerte, la hora de mostrar errores, una de las mayores ventajas, y que ahorra muchos quebraderos de cabeza, es la ventaja de React en tiempo de ejecución y con el error bien marcado en la línea que está fallando. Creo que todos sabemos qué pinta tienen los errores en Angular, ¿verdad Arturo? Si antes de leer este post en ambos lados hubiese saltado el mismo error, el resultado sería que Arturo aún seguiría buscándolo y a mí me hubiese dado tiempo a resolverlo y leerme el artículo completo…

Está claro que comparamos dos opciones que han demostrado ser prácticamente igual de rápidas, pero son los pequeños detalles los que marcan la diferencia. Para mí, el poder elegir la arquitectura que realmente necesitas, la facilidad del código a la hora de mantener un único fichero con toda la lógica y la comodidad a la hora de debugear, hacen que me decante por React.

Arturo Batanero

Jonathan, la primera en la frente de React no le va a caer por un tema técnico, sino por uno jurídico: React es un software parcialmente propietario, sujeto a las patentes de Facebook.

Así que, para reactividad chula, chula, la de tu cliente cuando le digas que se ha cancelado su proyecto porque Facebook ha decidido que viola su licencia, simplemente por ir en contra de sus intereses. En cambio, la de Angular 2 es de tipo MIT, sin ese tipo de problemas.

Sobre el nivel adopción de cada uno, y reconociendo que el mundo del desarrollo front-end es tan fashionista o más que el de la moda, el argumento Vicente (“**donde va la gente”), no me impresiona ni lo más mínimo. Más se puso de moda La Macarena y mira cuánto daño le ha hecho al mundo.

No, un Seat no es mejor que un Lamborghini, aunque que lo use mucha más gente. Puestos a comparar, trataría de hacerlo a un nivel estrictamente técnico:

Sobre el tamaño, menos mal que puntualizas un poco, porque no sería justo comparar peras con manzanas: Angular es un framework completo de propósito general, mientras que React es sólo una librería para las vistas. E incluso para eso, ya recibe críticas por estar más orientado a aplicaciones “que leen” que a aplicaciones “que escriben”.

Es mucho más justo comparar el tamaño cuando a React le añades el resto de librerías que le hacen falta para acercarse a la funcionalidad de Angular, el cual, por otra parte, está subdividido en módulos, que no es necesario cargar si no se van a utilizar.

En cualquier caso y siendo exactos los tamaños minificados que dices, realmente estamos de hablando de 143K de Angular contra 43K de React una vez gzipeados, que es como le llegan al navegador, lo que ya no me parece un locurón.

Por último, puestos a que el tamaño importe –que viniendo de un jovenzuelo como tú me suena un tanto viejuno, la verdad–, en todo caso habría que hablar del tamaño del framework sumado al de la aplicación y, aún así, no me parece tan importante: en Angular dispones de carga diferida (“lazy loading”) como prestación nativa.

Es, por tanto, muy sencillo diseñar tu aplicación de forma que el inicio sea ultrarrápido, con un módulo raíz simplificado y muy pocos elementos del framework, y que posteriormente se vaya cargando (o descargando) de forma inteligente el resto de la aplicación.

Lo que me lleva al tema de la velocidad: si bien parece, según benchmarks independientes, que resultan ser similares en este aspecto, en Angular tienes posibilidades adicionales:

Puedes renderizar en el servidor el arranque de la aplicación mientras la estás inicializando localmente, con el mismo resultado final, pero disponible mucho antes.

Y también tienes la posibilidad de correr buena parte del framework en un Worker, separado del hilo principal del UI, implicando una mejora de velocidad importante, sobre todo en aplicaciones híbridas o nativas.

Porque si, en Angular, aparte de aplicaciones Web y móviles híbridas, también puedes crear aplicaciones nativas desktop y móviles nativas.

Finalmente, un par de *recaditos *más: ni es obligatorio usar Typescript en Angular ni está prohibido utilizarlo en React. Typescript es simplemente una “máquina del tiempo” al futuro de JavaScript, al que te permite saltar desde ya.

Lo más interesante para mí de React es su paradigma de programación reactiva y de gestión del cambio de estado. Sin embargo, no tiene por qué ser algo exclusivo de React y no hay nada que nos impida aplicarlo también en Angular.

De hecho, el framework ya hace uso de forma extensiva de las extensiones reactivas (RxJS) y librerías de gestión de estado como Redux realmente son agnósticas al framework, pudiendo utilizarse directamente en Angular.