Cada vez dependemos más de los frameworks, pero en otros tiempos, los programadores se enfrentaban a un lienzo en blanco antes de empezar su trabajo: la etiqueta <body>. Planificaban meticulosamente, referenciando entidades y relaciones, y luego elaboraban interfaces hermosas a mano con puro HTML y un toque de JavaScript.
Estos eran los pioneros del código, lidiando con sitios web con editores básicos. Construían estructuras a partir de tablas, filas y columnas con una sangría interminable. Un solo cierre de etiqueta faltante podía hacer explotar tu monitor, un CRT de 14 pulgadas con protector de radiación, nada menos. La leyenda dice que algunos, debido a la pura fortaleza mental y física requerida, trabajaban casi sin ropa.
Los más civilizados escribían reglas CSS en el encabezado del documento, y los más audaces añadían adornos exóticos como «marquee» para envíos de formularios elegantes. Al fin y al cabo, Internet Explorer dominaba el mercado (¡alrededor del 90%!), por lo que solo el control de calidad podría notarlo… si alguna vez presionaban ‘enviar’. Pero datos falsos en la base de datos significaban problemas con los DBA, una raza ahora extinta conocida por su comportamiento gruñón.
A menudo (sobre)elogiamos a Steve Jobs por su innovación en productos, su genialidad en marketing y otras características que lo hicieron un tech. Pero yo lo recuerdo principalmente por haber matado a Flash.
Para los no iniciados, aquí hay un vistazo al potencial de Flash:
Wikipedia pinta una imagen diferente: “Adobe Flash Player… era un software para crear o usar principalmente animaciones vectoriales, principalmente para la web… También evolucionó hasta convertirse en una herramienta poderosa para Aplicaciones Ricas de Internet y streaming de audio/video…” Pero en julio de 2017, Adobe anunció la desaparición de Flash en favor de HTML5, WebGL y otros.
La caída de Flash se debió a sus animaciones que consumían muchos recursos y las vulnerabilidades de seguridad causadas por su naturaleza aislada dentro del navegador. El contenido de Flash aún existe, requiriendo el último reproductor (con riesgos de seguridad persistentes). Wikipedia lo minimiza, pero Flash incluso funcionaba en Arduino.
Sus scripts se volvieron tan omnipresentes que algunos sitios web te hacían esperar 10 segundos solo para ver a un gato de dibujos animados lamiéndose la pata.
Jobs tuvo suficiente. Prohibió Flash en los productos de Apple.
A foja cero (o casi)
Llegó HTML5, y las redes sociales florecieron, en parte gracias a Jobs y su iPhone. Ahora, el desafío era hacer que los sitios web se mostraran perfectamente en innumerables dispositivos.
Twitter (quienes quiera que sean ahora) lanzó Bootstrap, un framework que ofrecía herramientas y reglas de diseño preconstruidas para una visualización impecable de páginas web en cualquier tamaño de pantalla. Inicialmente, fue un salvavidas, estandarizando el diseño web. Las interfaces se volvieron limpias y minimalistas, y de la noche a la mañana, muchos horrores visuales desaparecieron. Finalmente, las noches no se pasaban buscando «¡important!» en cada etiqueta.
Pero con cada año que pasaba y cada anuncio, los frameworks se convirtieron en el estándar, el punto de no retorno.
Empezamos a dar las cosas por sentadas. La velocidad superó la comprensión, y cada vez más confiamos en «cajas mágicas» que resolvían problemas de manera opaca. Los frameworks se volvieron más fáciles de usar pero mucho más complejos por dentro. Pocos se molestaban en mirar dentro, lo que llevó a una pérdida de conocimiento valioso.
Comenzamos a usarlos como un cañón para aplastar una mosca: descargando megabytes de código para homepages o forzando la uniformidad en pequeñas aplicaciones CRUD. Si bien no extraño codificar a mano el htaccess para el enrutamiento, desearía que la gente lo recordara, para comprender los mecanismos y, si es necesario, personalizar el comportamiento del framework sin el temido «Angular no permite eso».
«No permite» es una palabra fuerte. La mayoría de las veces, lo permite, pero con un baño de sangre. La complejidad que los frameworks introducen para tareas simples puede llevarte a dimensiones paralelas donde arriba es abajo. Así que, para evitar perder la cabeza, simplemente haces lo que dice.
Por supuesto, cargar con un bloque de código masivo afecta el rendimiento. Debido a la complejidad, pocos entenderán realmente lo que JavaScript está haciendo con tu pequeño trozo de HTML. Reza, come tu hígado y espera lo mejor.
Dada la confusión de vulnerabilidades de módulos npm del año pasado, no me detendré en la seguridad. No puedes garantizar una seguridad completa; las herramientas adecuadas son imprescindibles. Los frameworks a menudo involucran diversas habilidades y profesionales como los expertos en DevOps, lo que hace que las cosas sean aún más complejas para los freelancers o desarrolladores solitarios.
Por último, está la independencia. Los frameworks se actualizan constantemente, lo que puede causar incompatibilidades o requerir cambios significativos en el código. Evitarlos significa no depender de ellos, permitiéndote dormir tranquilo (bueno, casi) cada vez que tu servidor se actualiza.
Los frameworks ofrecen muchos beneficios, permitiendo la colaboración con las mejores prácticas, manteniendo estándares y evitando el desarrollo desde cero. Si tuviera un euro por cada palabra maldicha dirigida al programador fantasma que me dejó con código sin probar y sin documentar (adornado con comentarios coloridos sobre el programador anterior), sería millonario. Y definitivamente no habría cometido el error embarazoso de decirle a un cliente «Quien escribió esto es un idiota» solo para descubrir que era mi propio código de hace un año.
Desde Angular hasta Slim, abracemos las herramientas que nos ayudan a resolver nuestros problemas cotidianos. Pero cuidado con quedar «atrapados» en ellos. Recuerda, cuando te estés golpeando la cabeza contra un problema trivial resuelto de una manera abstrusa, imagina tu framework vestido como Jessica Rabbit susurrándote al oído: «No soy mala, solo me dibujaron así…»
