<Cambiar />, un nuevo componente para desarrollar nuestros frontends
Guille Paz
Hace unos meses empecé a meterme con React (si, tarde pero seguro) y pude ver con mis propios dedos, todos los beneficios que tiene en cuanto a performance y buenas prácticas para con el frontender. Me gusta.
Esto me llevo a ver muchas charlas y leer posts de grandes empresas (Netflix, Airbnb, Paypal, Wallmart, etc) en los que cuentan cómo utilizan React dentro de su stack y cómo trabajan en la construcción de sus frontends.
Al ver la cantidad de empresas grandes que lo están adoptando, me surgieron varias preguntas: ¿Cuántos años de vida le queda a React como para tomar una decisión así? ¿Cómo hacen para migrar lo que van construyendo? ¿Cuánto tiempo tardan en realizar el cambio? ¿Será todo parte de una lucha entre Facebook y Google para ver quién tiene el control sobre la liberaría / framework de moda? ¿Por qué Sibarita es tan rica?
Estas preguntas me ayudaron a llegar a una conclusión, que para muchos puede ser obvia, y es que lo importante no es la librería / framework que se elija, sino el por qué hoy la elegimos y cómo la vamos a utilizar. Es decir, entender qué problema soluciona y cómo vamos a construir las cosas para que sean sencillas de cambiar a futuro.
En los últimos años, hubo un avance muy rápido de las tecnologías y de la forma en la que construimos frontends: Grunt quedó viejo. Gulp no es necesario. Browserify no va más. Ahora parece que todo hay que hacerlo con Webpack.
“The world is changing and we must change with it.” — Ragnar Lothbrok
Nos toca aceptar que vamos a estar cambiando la forma en la que construimos nuestros frontends, cada 3 años o menos y que todo avanza mucho más rápido de lo podemos codear.
Tenemos que estar preparados para cambiar y nuestro código también tiene que estar preparado. Es nuestra responsabilidad, como frontenders, tener esto en cuenta y mantenernos al día de dichos cambios y de lo que se viene.
Además, es muy importante tomar consciencia de la forma en la que trabajamos y seguir buenas prácticas, standards, documentar, realizar tests, etc. El código que tenga todas estas cosas va a ser mucho más fácil de mantener en el tiempo y cambiarlo, en caso de ser necesario.
Seguramente, mañana tengamos otros problemas, surjan nuevas herramientas que los solucionen y tengamos que cambiar.
Chao. 🚀