npm arruina el desarrollador

En 2020, redescubrí el placer de crear un sitio web con HTML, CSS y JavaScript simples: sin transpilación, sin compilación, sin herramientas de construcción más que mis manos en el teclado.

Dado que mi marca personal podría resumirse “tan tarde para el partido que demolieron el estadio”, decidí iniciar un podcast en 2020. Es el podcast de mi agencia, Clearleft, y le han dado un título tremendamente imaginativo. del podcast Clearleft . Estoy muy satisfecho con cómo resultó la primera temporada. También estoy muy satisfecho con el sitio web que preparé.

El sitio web no es muy grande, aunque crecerá con el tiempo. Pensé en cuál debería ser el proceso de construcción del sitio y después de literalmente segundos de debate, me decidí por ningún proceso de construcción. Cero. Nada.

Esto resultó ser enormemente liberador. Fue muy práctico escribir el HTML y CSS reales que se entregarán a los usuarios finales, sin ninguna mediación. Sentí como si estuviera metiendo las manos en la tierra del sitio.

CSS ha evolucionado tanto en los últimos años (con características como calc() propiedades personalizadas) que no es necesario utilizar preprocesadores como Sass . Y JavaScript básico es potente, tiene todas las funciones y funciona en todos los navegadores sin necesidad de compilación.

No me malinterpretes: entiendo perfectamente por qué son necesarios canales complicados para sitios web complicados. Si eres parte de un equipo grande, probablemente necesites implementar procesos para que todos puedan contribuir al código base de manera consistente. Cuanto más compleja sea la base de código, más tecnología necesitará para ayudarle a automatizar su trabajo y detectar errores antes de que se publiquen.

Pero esa configuración no es apropiada para todos los sitios web. Y todas esas herramientas y procesos que se supone que ahorran tiempo a veces terminan siendo una pérdida de tiempo en el futuro. ¿Alguna vez ha tenido que revisar un proyecto después de, digamos, seis o doce meses? Quizás sólo quieras hacer un pequeño cambio en el CSS. Pero no puedes porque se rompe una dependencia. Entonces intentas actualizarlo. Pero se basa en una versión diferente de Node. Antes de que te des cuenta, eres Bryan Cranston cambiando una bombilla. Deberías estar modificando una línea de CSS pero, en cambio, estás luchando contra la entropía .

Siempre que abordo un problema de desarrollo front-end, me gusta aplicar el principio de potencia mínima : elegir el lenguaje menos potente adecuado para un propósito determinado. Un ejemplo clásico sería usar un elemento de botón HTML simple en lugar de intentar recrear toda la funcionalidad nativa de un botón usando un div con enlaces de ARIA y JavaScript. Este año me di cuenta de que este mismo principio se aplica también a las herramientas de construcción.

En lugar de recurrir a una cadena de herramientas que canta y baila de forma predeterminada, comenzaré con una línea de base aburrida . Si eso se vuelve demasiado doloroso o difícil de manejar, entonces incluiré un administrador de tareas. Pero cada vez que agrego una dependencia, limitaré la vida útil del proyecto.

Mi propósito de año nuevo para 2021 será ponerme a dieta. No más node_modulescarpetas pesadas; simplemente HTML, CSS y JavaScript crujientes y deliciosos.