Mi Historia con CRA
Recuerdo cuando comencé a aprender javascript en mis tiempos de ocio mientras estudiaba en la universidad, veía videos sobre los posibles frameworks que aprendería una vez ya tuviese una base solida en javascript, y el framework que más me llamaba la atención era ReactJS, lo que más me atraía era la implementación que tenia en conjunto con jsx y la forma de manejar el flujo de datos de las aplicaciones.
Luego de haber aprendido bien las bases de javascript comencé un bootcamp en escalab.academy en el cual tomé el curso de ReactJS. (Aprox. verano 2022)
En este curso se utilizaba CRA como herramienta de creación de nuevas aplicaciones de ReactJS, el cual generaba una aplicación simple de React, ya que crear una aplicación desde cero de ReactJS supone extensas configuraciones y por tanto no es muy “beginner friendly”.
Fue así mi primer acercamiento con create-react-app.
Primeras impresiones
La verdad es que create-react-app me pareció asombroso, en ese tiempo siendo un novato en todo lo relacionado con las tecnologías web, con un simple comando podías crear una aplicación funcional, con testing y con una estructura de carpetas ya definida.
Para comenzar a aprender me pareció excelente, cada vez que quisiera crear algún proyecto para estudiar o hacer alguna aplicación simple, create-react-app era la primera opción.
Limites de CRA
Luego de hacer un par de proyectos en ReactJS, decidí buscar trabajo y gracias a estos proyectos logré conseguir trabajo como frontend developer, cuando me asignaron a mi primer proyecto, noté que utilizaban create-react-app, esto me dio algo más de confianza en el momento de mi onboarding, luego de realizar algunas features y acoplarme con mis compañeros de trabajo, nos tocó dar el paso a producción de la aplicación y yo como junior developer estaba muy emocionado, iba a ser la primera aplicación que estaría publica en internet la cual tiene features implementadas por mí. Pero fue aquí cuando comencé a entender ciertas falencias que tenía CRA cuando se realizaba un build para producción.
Al crear la pipeline para subir la aplicación a un contenedor ECS de AWS, el tiempo de build al ejecutar el comando npm build demoraba mucho tiempo, para una aplicación bastante simple, podía demorar aproximadamente entré 10 a 12 minutos y esto es soló considerando el build, también habría que sumar los pasos de linting, testing.
Busqué en internet, en los issues del repo de create-react-app y encontraba gente comentando lo mismo, lentos procesos de build en sus proyectos, llegados a una cierta cantidad de componentes o de librerías instaladas.
Configuración personalizada
Ya que en el proyecto anterior no erá de gran tamaño, ni con demasiadas configuraciones personalizadas, cuando me cambiaron al nuevo proyecto luego de haber terminado con el anterior, me di cuenta inmediatamente cuando instalaba el entorno local e hice por primera vez npm start que en iniciar el servidor local demoraba aproximadamente entre 30 a 60 segundos, luego al hacer cambios en el código, se notaba que el HMR (Hot Module Replacement) demoraba en cargar los cambios realizados.
Y que además para sobrescribir algunas configuraciones del bundler, en este caso, webpack, se debía instalar otra herramienta llamada CRACO (create-react-app-configuration-override) que permitía cambiar configuraciones de forma más fácil, lo negativo de esto, es que ahora el build de tu aplicación depende de dos librerías independientes, ya que, CRA era mantenida por facebook y CRACO por la comunidad.
Fue ahí donde comprendí los limites de CRA.
Conclusión
Para futuros proyectos, comencé a utilizar mejores alternativas a create-react-app, como vite que es una mejor alternativa a CRA y su proceso de build para producción es mucho más rápido ya que utiliza esbuild, en cambio CRA utilizaba webpack 4 o 5 (depende de la version de CRA).
O derechamente utilizar un framework de ReactJS como NextJS o RemixJS como lo menciona la nueva documentación de ReactJS.
Hasta la proxima!