Desarrollo web Aburrido, Rápido y furioso
Ó porque mi próxima aplicación web no será escrita en React/Vue/etc…
Por ahi por el 2008 éramos unas balas desarrollando aplicaciones (en Rails), nada nos detenía, todo era server rendereado con pequeñas cuotas de JS. No era muy elegante, harto jQuery, pero funcionaba y lo mejor era que desarrollábamos rápido.
Por ahi por el 2016 me subí al tren de React, anteriormente ya había desarrollado cosas con Backbone js. Basicamente migré de Backbone a React porque encontraba que Backbone.js era mucha vuelta para algo que React js resolvía de forma “simple” y en una sola capa, sin MVC en la vista. Los desarrollos en Backbone eran difíciles de mantener, sobre todo cuando volvías de las vacaciones.
Tiempo después caería en cuenta que las apps en React también son difíciles de mantener. React es elegante: cuando funciona, funciona. Pero en mi opinión caemos en la ilusión de creer que lo que estamos resolviendo es mas complejo de lo que en realidad es. Una extraña suerte de ilusión de complejidad. Sin embargo, estos tiempos de pandemia evidencian con más claridad la grasa (de las capitales) y de ciertos procesos de desarrollo. No hay tiempo que perder.
Hace un tiempo atrás escuché a alguien decir en twitter algo así como: “oh, Vue es maravilloso pude hacer un dropdown en solo un par de horas”. Esto lo decía un programador muy experimentado, y me pareció curioso. Pareciera que hubo un cambio de paradigma ahí. El asumir la complejidad que traen consigo los frameworks de javascript como algo natural, como el nuevo estado de las cosas. En otras palabras, no ver (o no querer ver) la carga que va a significar escribir y luego mantener esa base de código. Una vuelta larga para que todo ocurra sin recargar la página, ¿no?.
Me encanta React y llevo años trabajando intensamente con esta librería, pero en mi experiencia he detectado los siguientes problemas, que podrían ser ciertos también en otras librerías y configuraciones:
Bundles de js infinitos:
A medida que tu aplicación crece, tu bundle crece con ella. el problema de esto es que el compilado de js lo cargan los visitantes y no está bueno que eso solo siga creciendo. A esto le sumas el tiempo que demora el bundle en tus CI y tus Deploys. (confío en que nuevas herramientas como ESbuild resuelvan ese problema)
No es un estándar:
Vas a necesitar decenas de librerías para que tu JSX compile, babel, babel-transform y un gran etc … a medida que pasan los años vas a tener que ir actualizando las dependencias. (esto también es cierto para los frameworks como Rails y sus gemas, véase el caso reciente de mimemagic)
Repites un estado y lógica:
Un CRUD te toma un par de minutos en un framework full-stack como Django, Laravel o Rails, pero para echar a andar React en el mismo framework generalmente tienes que: crear los endpoints json, crear tu router, crear los formularios y los inputs y manejar un estado que actualice los componentes apropiadamente. El resultado es basicamente el mismo pero te demoraste días; horas si eres capo. Seguro que lograrlo es un gran triunfo. Sin embargo, al final del día sobre-complicas algo que es muy simple y seguramente lo programas a tu pinta por que eres seco en React.
Aquí me imagino esos relojes antiguos, de autor, con hartos engranajes. son lindos y complejos a la vez y cuando funcionan, verlo es alucinante, pero si tienes que hacerlas de relojero uf ….
API: Tienes una API gratis porque estas apps consumen JSON. Eso está bueno. Pero tu app realmente necesita una API? si es solo la UI de tu app que consume data de tu app tal vez no era necesaria. Desarrollar APIS en general trae consigo desafíos extras como serializar datos y mantener N+1 queries que se generan por ahi cuando hacemos las cosas a lo loco. De mantener una autenticación con tokens… ni hablar.
Ahora, preguntarse lo siguiente: Si toda esa complicación de API y AUTH era solo por que la app tenía que ser React, ¿es React un capricho?.
2021: DHH lo hace de nuevo.
Con la entrada de Hotwire, y sus amigos como: cableReady, Stimulus , LiveWire (laravel) LiveView (Phoenix) llega un nuevo enfoque para abordar el desarrollo. Su promesa es que traficas el HTML que ya tienes en tu app con un JS mínimo. No necesitas otra capa, otro router, otro modelo de datos que maneje un estado, sin containers o reducers. Sin embargo tienes la sensación de que la pagina recarga sin refrescar el navegador, es decir, recargas solo ciertas porciones y no el html completo. Tal y como se comportaría una app SPA. ¿ta bueno no?
Probablemente ya tienes tu app escrita en React/Vue/etc.. y te la piensas dos veces antes de migrar o siquiera intentar el nuevo (y vieja escuela) enfoque de “HTML over the wire”. Al menos yo he estado estos últimos días en esa encrucijada y creo que lo mas difícil es cambiar el mapa mental hacia entender que las cosas son mas simples de lo que parecen, en otras palabras, lo mas complicado es emanciparte de la ilusión de complejidad que traen consigo estas librerías como React.
Si haces un mapa de las cosas mas complejas de tu app React, ¿cuales son? en mi caso son los componentes Ordenables. (sortables, draggables), ventanas modales y alertas que reaccionan a eventos con su estado en Redux, editores de texto wysiwyg y routers js. En Chaskiq resolví varios de esos problemas donde utilicé y escribí librerías js que resuelven esos desafíos. Chaskiq es una app grande en React y Graphql donde, si bien me pican las manos por reescribirla con Hotwire, dudo que lo haga en el corto plazo.
Mi recomendación: toma un proyecto Rails antiguo (o nuevo) que ojalá no tenga React :) y dale.
Mi prueba de concepto
Para poder comparar tecnologías es necesario meter los pies en el agua. En mi caso tomé un proyecto antiguo del 2008 , el que se me ocurrió portar a react 😒 por ahi por el 2018, por suerte tenia pocos componentes (pero funcionaba como relojito 😄). un sortable anidado, unos toggles y por ahi sería, era abordable. Para mi sorpresa, ese componente que encontraba complejo (donde usaba React-Sortable creo) fue muy rápido de programar con Stimulus y Turbo (Hotwire), JS no mas de 10 lineas. Los tabs y uploaders también, los modales,. algo trivial.
Mi balance con Hotwire es muy postivo, el bundle compilado de la app pesa ~300kb, aprender Stimulus es muy sencillo, si vienes de React/Vue definitivamente estás sobre calificado para usarlo. La reescritura la hice en un par de días y lo mejor, terminas eliminado muucho código. de forma práctica y conceptualmente, le quitas una capa tremenda de complejidad a tu desarrollo.
Demo:
La app está en pañales pero la funcionalidad está ahí. Pullentity es un administrador de sitios web, como un CMS donde administras tus portafolios. Donde todo es secciones, paginas textos e imágenes.
El contenido de los sitios es administrado en la App Rails, pero, paradójicamente, los templates de los sitios si los hago en React, con Nextjs o create react app, en realidad cualquier tipo de aplicación que pueda ser deployada en Vercel.com. debería funcionar. Esto ultimo es una nueva funcionalidad de la plataforma y unos de los desafíos era hacer un deployador de sitios a Vercel via API. acá un ejemplo de la acción de deploy que debería correr en un Worker en el server y el log que se actualiza de forma reactiva con HotWire en el cliente con cero JS.
