Search for a command to run...
Y conoce 4 alternativas mucho mejores
I'm a self-made indie developer, passionate about freedom and curiosity. Working in my own stuff from México, learning all the time, and eager to collaborate with the entire world. I'm learning to write (English and Spanish) so here I am.
No comments yet. Be the first to comment.
I was playing around with Qwik. The most insanely fast web framework out there. Yes, the most. And this is mainly because of the philosophy behind Qwik and its creator. Which you can read about here. An excellent read. If you ever liked Angular like ...
El método forEach() del Array, ejecuta la función que le provees una vez por cada elemento en el array.(Mdn docs). Básicamente, el método forEach es una de las mejores maneras para usar un ciclo en un array, es mucho más simple que usar un for(). Lo ...
Si eres un desarrollador front end seguro sabes que no deberías decirle JavaScript. También si te gusta estar actualizado(a) o si eres parte de la comunidad OSS (Open Source) seguro sabrás este grupo de datos, con lo que desde hace ya varios años les...
… Y ahora soy plenamente feliz.
Hablamos todo el tiempo de las buenas prácticas y estilos de código, pero pocas veces hablamos de las malas prácticas en las que inconscientemente caemos muy seguido. Por ello, quiero compartirte 3 malas prácticas en JavaScript que podría ser que no ...
Recuerdo la vida antes de create-react-app (lo llamaremos CRA, para no escribir tantos guiones 😬), corría el año 2016, el equipo de Fixtergeek ejecutaba un bootcamp presencial sobre Python y Django en Pachuca, Hidalgo, y estábamos autoeducándonos aprendiendo React.js, con uno de los buenos; Cory House, vía la plataforma Pluralsight (qué en eso entonces si estaba actualizada). Cory en ese momento promovía justamente los "starter kit", cómo él los llamaba, sobre cómo crear un entorno de desarrollo una sola vez para tu equipo y reusarlo en cada proyecto, también ofrecía un repositorio de Github para comenzar con todo el boilerplate de React, sí, usamos su repo un tiempo y después nuestra curiosidad nos llevó a aprender Webpack.
Como desarrolladores, disfrutamos aprender webpack, era complejo y a la vez simple (solo un objeto gigante de configuración con un chingo de plugins) pero me di cuenta que era "too much" para un principiante, cuando intentamos dar un curso gratis de React en un meet-up al año siguiente. Fue un total desastre.
La primera hora intenté enseñar cómo configurar tu entorno de desarrollo con Webpack, Babel, Eslint, Jest y de paso sintaxis de ES6 en 1 hora... puff, ese fue mi primer descubrimiento sobre la condición del desarrollador latino promedio, específicamente el mexicano. Too much gringo stuff.
Queríamos enseñar React, pero era forzoso pasar por un montón de configuraciones e instalaciones (que siempre fallaban) para poder comenzar con el desarrollo web. Esto asustaba a nuestros estudiantes más principiantes, se convertía en un filtro para comenzar con desarrollo web, las personas se desanimaban y decían que "la programación no era para ellas" ¡solo por las configuraciones!
No, esto no es un buen filtro, no te quedas con los más listos o más inteligentes, no, la tecnología debería ser accesible para todos y la creación de tecnología también, aprendemos a diferentes ritmos, aprendemos de diferentes maneras, en realidad solo te quedas con un grupo de personas que pueden aprender de forma similar, estandarizada, no te quedas realmente con los más inteligentes, incluso creo que pierdes a los creativos, colocando paredes complejas como filtro.
Fue entonces que apareció create-react-app (CRA) de la mano del profeta Dan Abramov (es una broma lo de llamarle profeta he, no te creas, es puro cariño).
Create React App lo cambió todo, nos permitió enseñarle desarrollo web moderno a más personas, nos permitió introducir interfaces más complejas sin tanto dolor y sin tener que pasar por configuraciones exhaustivas que no hacían sentido en ese momento para un principiante y sobre todo, nos permitió quedarnos con todo mundo, las personas podían aprender a su manera y a su ritmo sin dejar de ser creativas con la herramienta, dejando para después y con más calma el entender configuraciones y Node.js.
CRA fue un "game changer" para nuestra escuela Fixtergeek y por su puesto, para nuestros clientes. También logramos aterrizar y vender proyectos más complejos gracias a CRA.
Esto fue en 2016, CRA siguió mejorando, sobre todo del lado del testing con Jest que es otra de esas joyitas de librería, pero también al ser usado por millones de desarrolladores literalmente se volvió un gigante que le cuesta avanzar hacia el futuro, sin mencionar que está construido con prácticas y opiniones del momento.
Afortunadamente (o lamentablemente para CRA) la tecnología y las nuevas ideas se mueven a velocidad luz en tecnología, y específicamente en desarrollo web, las nuevas herramientas aparecen todos los días, los creadores de liberías están sobrehumanamente actualizados y crean herramientas espectaculares, resuelven problemas que muchos pensamos que no son problemas, por ejemplo Webpack.
Webpack nació para resolver problemas y dejar de usar "task runners" como Gulp o Grunt y fue en su momento ¡una gran solución!, pero después alguien lo vio como un gran problema, e inventaron herramientas para resolver "el problema de tener que configurarlo" y aparecen herramientas como Parcel, que te permite tener todas las bondades que te ofrece Webpack, pero con abstracción, es decir, ¡invisible y sin configuración!
A pesar de que esto es genial, también da miedo porque si seguimos así ¿a donde llegaremos? ¿cual será nuestro rol? ¿a caso no sabremos realmente crear tecnología? ¿solo sabremos operar librerías y herramientas que crean para nosotros otra gente que sí son genios? ¿nos estamos convirtiendo en obreros de la web? que solo jalan palancas y oprimen botones , pero no tenemos idea de cómo crear estas librerías.
Pero dejando a un lado mi visión apocalíptica, estas nuevas herramientas no solo resuelven estos problemas que no sabíamos que teníamos, también traen consigo la razón tal vez principal de adoptar estas nuevas ideas: velocidad y optimización.
Sabiendo que la tecnología avanza a pasos agigantados, debería ser natural para el developer web, explorar su curiosidad y cambiar de herramientas rápido, como pasar de un desarmador a un taladro y luego a un desarmador eléctrico en cuanto haya posibilidad, por razones obvias, pero desde mi punto de vista nos pasan 3 cosas mortales a los desarrolladores latinos:
Nos ha costado tanto aprender las herramientas que usamos hoy, que preferimos conservarlas.
Los empleos nos mantienen ocupados y no nos actualizamos regularmente, muchos aprender desarrollo web para tener un empleo "estable" y esto es ingenuo en tecnología.
Al ser una cultura de tradición religiosa (gracias a los conquistadores) tendémos a dogmatizar lo que nos gusta y evitar el cambio.
Tal vez estoy exagerando con el punto 3, pero cada que tengo la oportunidad de cruzar opiniones con otros developers que se resisten a actualizarse, muchas veces es por dogma, es porque piensan que las herramientas que usan "son las mejores" y todo lo demás es pecado. jeje, sigo exagerando ok, pero la web es tan joven que es realmente ingenuo pensar que las herramientas que usamos están aquí para quedarse, es importante mantenerte al día de los "game changers" que están en todas partes, lo mismo que pasa con las apps y tendencias que van apareciendo, por ejemplo, las redes sociales (quien diría que TikTok le provocaría calofríos a Instagram) lo mismo sucede con las herramientas tech.
Todo lo anterior para decirte algunas buenas razones que deberían ser suficientes si dejas el religiosísimo CRA:
CRA es mucho más lento y complejo que otras alternativas para crear aplicaciones React como lo son Parcel o Vite, que por cierto, esta última tiene una comunidad gigante y apasionada por la simplicidad.
Con el tiempo, un app CRA se vuelve aún más lenta según crece por como está construida, además de no usar cache para los "builds" (como lo hace Vite), reinstala y ejecuta muchas cosas innecesariamente.
Uno de esos innecesarios son los "polifylls" de Node.js, estas librerías en búsqueda de compatibilidad, terminan emulando acciones pensadas solo para el servidor y no quieres fs o crypto en el navegador créeme.
Webpack sabiendo que esto es una pésima idea, retiró estos polifylls de su última versión, provocando una gran pila de errores en CRA, checa este issue en Github
Raix tiene toda la razón, pero ve nomás cuanto hate le llovió, ¿en serio a los developers web no les importan las buenas prácticas?
Y con esto ven, acompáñame, te voy a dar un par de mejores razones aún.
Hablando de Webpack, eso me hace recordar un dato curioso:
El creador del mismo fue contratado por Vercel para crear la nueva versión de webpack y traerlo al futuro y se llama Turbopack
¿Recuerdas que la tecnología se mueve a velocidad luz?, bueno, mientras nos peleábamos por si Vite es mejor o no (deberías ir a probar Vite, te dejo un videito aquí) al mismo tiempo comenzaba una carrera retro, por volver al Server Side Rendering (SSR) que ha estado con nosotros desde siempre pero que el extendido uso de CRA no nos dejaba ver pues trajo una maldición de la que nadie se dio cuenta hasta muy tarde.
La gran mayoría de desarrolladores web, que comenzaron su carrera con CRA, lo hicieron del lado del cliente, creando SPAs (Single page applications) y no solo olvidaron que un servidor puede servir HTML, también se acostumbraron a una serie de dolores permanentes que provocaron una búsqueda por soluciones que cuando entiendes como funciona una aplicación fullstack mono repo, pierden total sentido.
Estoy hablando de manejar y mantener un estado local, Redux, Mobex, ReactQuery e incluso GraphQL, son soluciones maravillosas que realmente no necesitas, para problemas que no tienes, te explico.
A menos que estés trabajando en un app gigante tipo Facebook, no necesitas GraphQL, (no me crucifiquen porfa) y mucho menos Redux, puedes hacer consumos simples a tu servidor cuando lo necesites sin necesidad de guardar una copia de la base de datos en tu aplicación de navegador, muchos developers web incluso no saben, que hacer consumos fetch/Ajax es opcional en un sitio web.
Muchas de estas herramientas solo las necesitamos porque iniciamos el proyecto como una SPA cuando ni siquiera era la mejor opción para nuestro proyecto. Y esto es así solo porque la herramienta que usamos así funciona (CRA), pero podemos tener una mejor vida como desarrollador web.
Afortunadamente la comunidad web se dio cuenta de esto hace algunos años ya, y aparecieron alternativas a las SPA, volviendo un poquito atrás, a lo que ya teníamos y despreciamos, el servidor web.
Y volvieron a nosotros con nombres nuevos y relucientes para llamar la atención del desarrollador web. SSR, SSG y hasta CCDN (server side rendering, server site generation and cache content delivery network, respectivamente) que no son otra cosa que servidores web que entregan paginas HTML pre-renderizadas con la data dinámica necesaria (para no necesitar Redux) o que incluso entregan el sitio entero pre-renderizado como en el caso del SSG (Astro es un gran ejemplo de esto).
Voy a dejar los detalles y la comparación de estas opciones para un post aparte y no distraernos del tema que estamos tratando aquí. Pero sí, puedes escoger herramientas como Gatsby, Nextjs, Astro, Qwick, Redwoodjs o mi favorito personal, Remix. que te van a permitir crear aplicaciones web modernas con React, más rápidas y sin el dolor de mantener un estado global en el navegador.
Pero si quieres dar pasos pequeños y no abrumarte con aprender alguno de los frameworks anteriores, porque claro que tienen una curva de aprendizaje, y más si solo has hecho CRA y nunca tocado el servidor. ( Aquí te dejo una forma de aprender desarrollo web full stack conmigo) Quiero enlistarte una pequeña lista de alternativas según el nivel de experiencia que tengas:
Vite. Si solo has usado CRA pero estas lista para actualizarte, ve con Vite. Vite, tiene una comunidad muy abierta y amigable, y la herramienta propone un montón de utilidades profesionales pero simples como su sistema para testing y la hipercompatibilidad con otras herramientas front end como Svelte o Vue, lo que te permite explorar y mejorar como desarrollador web y eso es muy saludable para tu carrera, recuerda que React no es lo único que existe 😉
Parcel. Esta herramienta nació para que la transpilación y compresión de recursos fuera simple y sin dolor, es una gran opción si aún quieres tener la posibilidad de configurar por tu cuenta y tomar las desiciones sobre tus "builds" y cómo son creados y entregados tus chunks a tu cliente. Para trabajar con React sólo tienes que hacer npm i parcel react react-dom Aquí te dejo un video al respecto.
Remix. Si quieres dar el primer paso al SSR, Remix es la mejor opción, es simple, la curva de aprendizaje es cortita y lo mejor es que mientras aprendes Remix aprendes la API oficial de la plataforma web, #useThePlatform, esta es mi recomendación personal. Remix además es super compatible con las plataformas para deployment más eficientes y populares.
Next. Este es el líder sin discución y es una excelente alternativa a CRA y para actualizar tus habilidades como front end dev, recuerda solamente que, no por ser el líder, se es la mejor alternativa, es como pensar que React es el mejor cuando existe Svelte y Solid. (¡hey! ¿qué dijimos del religiosísmo tecnológico?)
¡Y ya está! no era mi intención hacer este post interminable, pero sí aclarar que dejar de utilizar CRA es más por el contexto tecnológico que por razones malignas dentro de la herramienta. Gracias por acompañarme en este pequeño viaje, me gustaría mucho saber que piensas y cual de estas opciones has elegido para mover tu carrera hacia adelante, sígueme y suscríbete a la lista de correo y platiquemos. 🤓
Un abrazo. Bliss.