La evolución del desarrollo de React: por qué otras herramientas están ganando terreno frente a create-react-app

¡Hola! Nuestra vida en el desarrollo de front-end está en constante cambio y lo último de moda es React. Además de la nueva documentación, que por cierto es muy bonita, hay puntos que han cambiado y requieren mucha atención. La nueva guía de React recomienda no utilizar create-react-app para crear aplicaciones. En su lugar, sugieren utilizar:

• Next.JS
• Remix
• Gatsby

Si aún deseas seguir con el enfoque "clásico" (es decir, aplicaciones construidas con la arquitectura de una sola página - SPA), mencionan en una nota al pie que puedes usar:

• Vite
• Parcel

Aunque mencionan estas alternativas, dejan claro que actualmente no son las recomendadas. Siguiendo la guía de la documentación, las nuevas aplicaciones deberían utilizar los frameworks mencionados anteriormente, ya que están listos para producción.

Pero eso no es todo. Para entender estos cambios, necesitamos sumergirnos más en el contexto de React, las SPAs (aplicaciones de página única), el lado del cliente y el lado del servidor.

SPA - single-page application

A veces, en la programación, los nombres que elegimos para las cosas pueden ser confusos, pero eso no ocurre con el término SPA: ¡una aplicación de página única es literalmente una aplicación que tiene solo una página!

Si comienzas a navegar por la aplicación, notarás que la página no se recarga por completo. Solo se envían los nuevos datos mientras el usuario navega por la aplicación, y eso es un ejemplo de una aplicación de página única.

Ventajas

Muchas empresas han estado desarrollando aplicaciones de esta manera, pero ¿cuál es la gran ventaja de hacerlo? Debe haber algo que ha funcionado muy bien, ¿verdad?

Comencemos con una característica que no se menciona con frecuencia: la implementación en el entorno de producción.

Entender las ventajas del uso de SPAs en producción también responderá a la pregunta clave:

¡Hola, persona! Nuestra vida en el desarrollo de front-end está en constante cambio y lo último de moda es React. Además de la nueva documentación, que por cierto es muy bonita, hay puntos que han cambiado y requieren mucha atención. La nueva guía de React recomienda no utilizar create-react-app para crear aplicaciones. En su lugar, sugieren utilizar:

Next.JS Remix Gatsby Si aún deseas seguir con el enfoque "clásico" (es decir, aplicaciones construidas con la arquitectura de una sola página - SPA), mencionan en una nota al pie que puedes usar:

Consulta este artículo: SPA: aplicación de página única Nuevas recomendaciones Quiero aprender Next Referencias para profundizar más Vite Parcel Aunque mencionan estas alternativas, dejan claro que actualmente no son las recomendadas. Siguiendo la guía de la documentación, las nuevas aplicaciones deberían utilizar los frameworks mencionados anteriormente, ya que están listos para producción.

Pero eso no es todo. Para entender estos cambios, necesitamos sumergirnos más en el contexto de React, las SPAs (aplicaciones de página única), el lado del cliente y el lado del servidor.

Imagen: "siéntate, que viene la historia". Arte de la exhibición "Entra que lá vem história" de TV Cultura, en homenaje al programa homónimo y al 50 aniversario del canal.

SPA: aplicación de página única A veces, en la programación, los nombres que elegimos para las cosas pueden ser confusos, pero eso no ocurre con el término SPA: ¡una aplicación de página única es literalmente una aplicación que tiene solo una página!

Si comienzas a navegar por la aplicación, notarás que la página no se recarga por completo. Solo se envían los nuevos datos mientras el usuario navega por la aplicación, y eso es un ejemplo de una aplicación de página única.

Ventajas Muchas empresas han estado desarrollando aplicaciones de esta manera, pero ¿cuál es la gran ventaja de hacerlo? Debe haber algo que ha funcionado muy bien, ¿verdad?

Comencemos con una característica que no se menciona con frecuencia: la implementación en el entorno de producción.

Entender las ventajas del uso de SPAs en producción también responderá a la pregunta clave:

Implementación (o deploy)

Una SPA es muy fácil de implementar en comparación con aplicaciones más tradicionales que se renderizan en el lado del servidor. Básicamente, solo necesitamos un archivo index.html, junto con un paquete de CSS y un paquete de JavaScript (una vez compilados, por supuesto).

Estos tres archivos estáticos se pueden cargar en cualquier servidor de contenido estático, como Apache, Nginx, Amazon S3 o Firebase Hosting.

No todo es perfecto, y la aplicación necesitará realizar llamadas al backend para obtener los datos, pero ese es un servidor separado que se puede construir, si es necesario, con una tecnología completamente diferente, como Node, Java, .NET o PHP.

Versionamiento y reversion

Otra ventaja de implementar nuestro front-end como una SPA es la posibilidad de versionar y volver atrás en una implementación (revertir una publicación a la versión anterior). Todo lo que necesitamos hacer es versionar la salida de nuestra compilación.

Podemos configurar el servidor que está sirviendo nuestra SPA con un parámetro que especifique qué versión de la aplicación frontend se debe utilizar: ¡es así de simple!

Este tipo de implementación escala bien: los servidores de contenido estático como Nginx (aquí, para personas que desarrollan frontend, estamos más en el lado de la infraestructura) pueden escalar para un gran número de usuarios.

Obviamente, este tipo de implementación y versionado solo es válido para la parte frontend de nuestra aplicación, no se aplica al servidor backend. Aun así, es una ventaja importante a considerar.

Experiencia de usuario

Cuando surgieron las primeras SPA, la experiencia del usuario era pobre debido a lo siguiente:

La página se recargaba frecuentemente. Había múltiples idas y venidas de solicitudes de red al servidor para obtener todo este HTML, incluso las partes que permanecían sin cambios. En una SPA, resolvemos este problema utilizando un enfoque fundamentalmente diferente:

Después de la carga inicial de la página, no se envía HTML adicional a través de la red. En su lugar, solo se solicitan (o envían) datos al servidor.

Mientras una SPA está en ejecución, solo se envían datos a través de la red, lo que requiere menos tiempo y ancho de banda que el envío constante de todo el HTML.

Desventajas

Pero, como suelo decir, no hay comida gratis. El uso de SPAs también tiene sus desventajas:

• Complejidad: el desarrollo de SPAs puede ser más complejo en comparación con el desarrollo de sitios web estáticos tradicionales, ya que implica crear una arquitectura de aplicación completa con enrutamiento, gestión de estado, obtención de datos y otros recursos.
• Rendimiento: las SPAs pueden ser más lentas en dispositivos con conexiones a Internet más lentas, ya que requieren descargar toda la aplicación al principio de la carga para luego comenzar a obtener los datos necesarios.
• Problemas de SEO: el contenido de las SPAs a menudo es dinámico y se genera con JavaScript en el lado del cliente, lo que puede afectar la indexación de los motores de búsqueda como Google.
• Curva de aprendizaje: aprender a trabajar con React puede llevar tiempo y esfuerzo, especialmente para los desarrolladores acostumbrados a otros enfoques de desarrollo web.
• Dependencias: React depende de muchas otras bibliotecas y paquetes, lo que puede hacer que el mantenimiento y la actualización de una aplicación sean más complejos y demorados.

Es muy probable que no necesites esto al comienzo del proyecto, pero a medida que el proyecto evolucione, debes tener algunas precauciones y terminar confiando en bibliotecas conocidas.

A medida que el paquete de tu aplicación crezca, eventualmente buscarás una forma de dividir el código, probablemente por ruta, para optimizar la carga.

A medida que tus necesidades de búsqueda de datos se vuelvan más complejas, probablemente encontrarás desafíos en la comunicación entre el servidor y el cliente que harán que tu aplicación se sienta muy lenta.

A medida que tu audiencia incluya a más usuarios con conexiones a Internet lentas y dispositivos de bajo rendimiento, es posible que necesites generar HTML a partir de tus componentes para mostrar el contenido más rápido, ya sea en el servidor o durante el tiempo de construcción.

Cambiar su configuración para ejecutar parte de su código en el servidor o durante la construcción puede ser muy complicado.

Además, es común tener varios caminos y enfoques diferentes para resolver estos problemas conocidos. El problema es que mantener todo esto en una base de código de calidad se vuelve difícil porque las cosas van sucediendo e impactando el proyecto:

esa persona que inició el proyecto se fue de la empresa... la necesidad de agregar nuevas funcionalidades no nos permite tener tiempo para trabajar en tareas más técnicas... la falta de mantenimiento deja los paquetes principales de la aplicación desactualizados y se vuelve cada vez más complejo actualizar a las últimas versiones... En fin, el punto es que los proyectos que crecen tienden a volverse complicados con el tiempo. Principalmente porque cada empresa termina resolviendo problemas recurrentes de una manera personalizada y esto incluso influye en la dificultad de traer nuevas personas y enseñar todo lo que se ha hecho y explicar las motivaciones.

Y el movimiento que terminó sucediendo fue: vamos a intentar equilibrar las cosas... no tanto del lado del cliente, no tanto del lado del servidor. Vamos a encontrar un equilibrio entre todo eso.

Nuevas recomendaciones

Ahora que ya tenemos el contexto de por qué las cosas se han trasladado, de manera pesada, al lado del cliente y por qué ahora las cosas están regresando, en parte, al lado del servidor, podemos hablar más detalladamente sobre cada opción que nos ofrece React. ¡Vamos allá?

Next

Es un framework de JavaScript de código abierto que es muy bueno para construir aplicaciones web modernas y escalables. Está basado en React, una biblioteca de JavaScript para construir interfaces de usuario, y se utiliza mucho para crear aplicaciones con representación del lado del servidor (SSR) y generación estática de sitios (SSG).

Aquí hay algunos puntos que me gusta destacar de Next.js:

Renderizado híbrido: Next.js admite tanto SSR como SSG, lo que significa que puede generar páginas estáticas en tiempo de construcción para mejorar la velocidad de carga de la página, al tiempo que puede generar contenido dinámico en el servidor cuando sea necesario.

• Mejora del rendimiento: Next.js tiene funciones de optimización integradas, como la precarga de rutas, carga optimizada de recursos, generación de imágenes receptivas y más. Estas características ayudan a mejorar la velocidad de carga de las páginas, reducir el tiempo de renderizado y mejorar la experiencia del usuario.
• Soporte para TypeScript: Next.js tiene soporte nativo para TypeScript, lo cual es genial porque agrega capacidades avanzadas de tipado estático a JavaScript, lo que ayuda a prevenir errores de programación y mejorar la calidad del código.
• Facilidad de uso: Next.js es fácil de usar y tiene muchas funciones integradas, incluido el soporte para CSS y Sass, enrutamiento integrado, gestión del estado, entre otros. Esta facilidad permite centrarse en la lógica empresarial y crear una gran experiencia de usuario.
• Comunidad activa: Next.js tiene una comunidad activa y muchos recursos de soporte disponibles, como documentación detallada, ejemplos de código y un ecosistema de complementos y paquetes de NPM. Una comunidad activa facilita encontrar ayuda y recursos.

Remix

Remix es una biblioteca de JavaScript para crear aplicaciones web, que fue desarrollada por el equipo de React Training. Pero a diferencia de React, que se centra en los componentes de la interfaz de usuario, Remix.JS adopta un enfoque más completo y ayuda a estructurar toda la arquitectura de la aplicación.

Estas son algunas de las ventajas de Remix:

Rendimiento: Remix fue diseñado para ser extremadamente rápido y eficiente, optimizando la carga de aplicaciones y minimizando el tiempo de respuesta del usuario.

Arquitectura escalable: la biblioteca ofrece una estructura de arquitectura clara y escalable, que permite la creación de aplicaciones complejas y robustas, con una clara separación de responsabilidades.

Compatibilidad con rutas: Remix ofrece un sistema de rutas flexible y fácil de usar que le permite crear direcciones URL fáciles de usar y navegar entre las páginas de la aplicación sin necesidad de volver a cargar la página.

Control de estado: la biblioteca ofrece un sistema de gestión de estado integrado, que ayuda a mantener la coherencia y la sincronización de datos en toda la aplicación.

Herramientas de desarrollo: Remix tiene una serie de herramientas de desarrollo que ayudan a simplificar el proceso de creación y depuración de su aplicación, incluido un servidor de desarrollo integrado, soporte de recarga en caliente y herramientas de depuración avanzadas.

Remix vs Next

Remix y Next.js están destinados a ayudar a crear aplicaciones web modernas y escalables, pero tienen algunas diferencias entre ellos.

En comparación con Next.js, una de las principales diferencias de Remix es su enfoque más integral para estructurar toda la arquitectura de la aplicación. Por otro lado, Next.js se centra más en la capa de visualización de la aplicación y ofrece funciones para la representación del lado del servidor (SSR) y la representación previa de páginas estáticas.

Otra diferencia significativa es que Remix ofrece una solución de gestión de estado integrada, mientras que Next.js no tiene una solución específica, dejando esa elección al desarrollador. Remix también ofrece un sistema de enrutamiento más avanzado con compatibilidad con URL dinámicas, mientras que Next.js todavía tiene algunas limitaciones en esta área.

En lo que respecta al rendimiento, ambos son excelentes, pero Remix es más nuevo y aún no se ha probado tan exhaustivamente en producción como Next.

Pero a diferencia de React, que se centra en los componentes de la interfaz de usuario, Remix.JS adopta un enfoque más completo y ayuda a estructurar toda la arquitectura de la aplicación.

Estas son las cinco ventajas principales que me gustan de Remix.JS:

1- Rendimiento: Remix.JS está diseñado para ser extremadamente rápido y eficiente, optimizando la carga de aplicaciones y minimizando el tiempo de respuesta del usuario.

2- Arquitectura escalable: la biblioteca ofrece una estructura de arquitectura clara y escalable, que permite la creación de aplicaciones complejas y robustas, con una clara separación de responsabilidades.

3- Compatibilidad con rutas: Remix.JS ofrece un sistema de rutas flexible y fácil de usar que le permite crear direcciones URL fáciles de usar y navegar entre las páginas de la aplicación sin necesidad de volver a cargar la página.

4- Control de estado: la biblioteca ofrece un sistema de gestión de estado integrado, lo que ayuda a mantener la coherencia y la sincronización de los datos en toda la aplicación.

5- Herramientas de desarrollo: Remix.JS viene con una serie de herramientas de desarrollo que ayudan a simplificar el proceso de creación y depuración de su aplicación, incluido un servidor de desarrollo integrado, soporte de recarga en caliente y herramientas de depuración avanzadas.

Gatsby

Gatsby es un framework de React que tiene como objetivo ayudar a los desarrolladores a crear aplicaciones y sitios web de forma rápida y sencilla, centrándose en el rendimiento.

El proceso de construcción de Gatsby se divide en tres pasos:

1- En primer lugar, está la fuente de datos, que es la fuente de datos que se utilizará para crear el sitio web o la aplicación.

2- A continuación, se lleva a cabo el proceso de construcción, que incorpora el HTML, JavaScript y CSS necesarios para compilar la aplicación desde la fuente de datos.

3- Finalmente, el Deploy, en el que los archivos se envían a algún servidor para ser visualizados en la web.

El propósito de Gatsby es leer datos de diferentes fuentes, como un CMS, una base de datos de rebajas o incluso JSON, lo que lo hace extremadamente versátil.

Se usa comúnmente en blogs como front-end, donde es posible usar un CMS, como WordPress, para administrar el contenido mientras Gatsby sirve el contenido de forma estática. Gatsby también se usa en sitios web estáticos e incluso en comercio electrónico, lo que la convierte en una herramienta poderosa y en ascenso en el mercado, adoptada por compañías como Nike, PayPal y React.

El hecho de que sea de código abierto facilita la comunidad dentro del marco. Esto significa que cualquiera puede aportar ideas y soluciones, lo que hace que el marco en su conjunto evolucione más rápido. Además, todo el grupo se conecta, comparte conocimientos y dudas dentro de los “temas” del repositorio. Y lo mejor de todo, sin importar dónde se encuentre y cuánto sepa, todos pueden usar y contribuir con la herramienta :)

React sin frameworks

En este punto, es posible que te estés preguntando: "Está bien, ¿no puedo usar React sin frameworks ?". De hecho, si puede.

Para hacerlo, simplemente siga la misma estrategia que la ya obsoleta create-react-app: agregue react y react-dom a través de npm y cree su proceso de compilación. Ya existen dos herramientas que pueden ayudarte en tu proceso:

Vite

Vite (una palabra francesa para "rápido", pronunciado /vit/, como "veet") es una herramienta de construcción que tiene como objetivo proporcionar una experiencia de desarrollo más rápida y fluida para proyectos web. Consta de dos partes principales:

• Un servidor de desarrollo que proporciona mejoras de funciones sobre los módulos ES nativos, por ejemplo, Hot Module Replacement (HMR) extremadamente rápido.
• Un comando de compilación que empaqueta código con Rollup (una biblioteca que empaqueta paquetes JS) preconfigurado para producir archivos estáticos altamente optimizados.

Un dato curioso es que Vite fue creado y desarrollado por Evan You, el creador del framework Vue.

Parcel

Parcel, es una herramienta JavaScript de código abierto, se utiliza para empaquetar y optimizar aplicaciones web. Fue creado para proporcionar una solución más simple para empaquetar código JavaScript ademas de las alternativas existentes (por ejemplo, webpack).

No requiere una configuración compleja para iniciar un proyecto y es capaz de empaquetar una variedad de tipos de archivos, incluidos HTML, CSS, JavaScript, imágenes y más.

Además, Parcel tiene capacidades integradas de reemplazo de hot module replacement (HMR) para permitir que los desarrolladores vean los cambios en tiempo real a medida que realizan cambios en el código. También es compatible con varios idiomas, incluidos TypeScript y Sass.

Entonces, ¿podemos proceder sin ningún framework?

¿Recuerda esos problemas señalados al comienzo de nuestra conversación? Recordatorio rápido de algunos problemas conocidos:

• Incluso si no necesita enrutamiento o obtención de datos al comienzo de su proyecto, probablemente terminará agregando bibliotecas en un futuro cercano para eso.

• A medida que su paquete de JavaScript crece con cada función nueva, es posible que deba dividir el código para cada ruta individualmente.

• A medida que sus necesidades de recopilación de datos se vuelvan más complejas, es probable que encuentre una serie de solicitudes de servidor-cliente que ralentizan su aplicación.

• A medida que aumenta la cantidad de usuarios, es posible que deba lidiar con escenarios en los que las condiciones de la red son malas y los dispositivos utilizados no funcionan bien... Por lo tanto, es posible que desee generar HTML a partir de sus componentes para mostrar el contenido más rápido, ya sea en el servidor o durante el tiempo de compilación.

• Cambiar su configuración para ejecutar parte de su código en el servidor o durante la compilación puede ser muy complicado.

Cuando usamos frameworks, ya tenemos todo empaquetado y listo para usar, sin tener que agregar otros paquetes que lo hagan por nosotros. Está todo ahí, solo úsalo. Vale la pena mencionar que estos no son problemas exclusivos de React, ya que otros frameworks también experimentan esto. Vue tiene Nuxt, Svelte tiene Svelte Kit, por ejemplo.

Estas herramientas existen para estandarizar la forma en que maneja estos problemas, lo que permite que su aplicación se escale sin mayores dificultades. Sin todo el esfuerzo adicional en el lado del diseño, lo que le permite concentrarse realmente en las reglas de su negocio.

Además, las nuevas funciones de React estarán dirigidas a marcos como Server Side Components. Sabiendo que el enfoque del equipo de React será mejorar la biblioteca central para poder potenciar aún más los marcos... elegir crear una nueva aplicación, de la manera "clásica", puede ser una elección arriesgada.

Si ya tiene una aplicación en ejecución, migrarla a un framework será un desafío directamente relacionado con el tamaño y la complejidad de su proyecto.

Referencias para profundizar

Si quieres profundizar más en estos cambios y entender cuál es la mejor opción para tu escenario (¡felicidades! =]) es señal de que tienes la curiosidad necesaria para evolucionar cada vez más como desarrollador. Dejaré aquí la lista de todas mis fuentes de investigación para este artículo:

Documentación React (link https://es.react.dev/learn)

Documentación Next.js (https://nextjs.org/docs)

Documentación Remix (https://remix.run/docs/en/1.15.0)

Web oficial Gatsby (https://www.gatsbyjs.com/how-it-works/)

Web oficial Vite (https://vitejs.dev/)

Web oficial Parcel (https://parceljs.org/)

Vinicios Neves Vinicios es ingeniero de software, involucrado en la arquitectura, diseño e implementación de microservicios, micro frontends y sistemas distribuidos. Tiene una experiencia significativa en aplicaciones, integración y arquitectura empresarial. Es Ingeniero de Software de la UNESA y Arquitecto de Software de la PUC Minas.