Escribinos
Navegación
← Volver al blog
Tech

Por qué elegimos no usar build tools

Nada de Webpack, Vite ni frameworks pesados. HTML, CSS y JS vanilla, con dependencias por CDN. Así laburamos la mayoría de nuestros proyectos, y no es por vagos.

Diagrama: HTML, CSS y JS yendo directo al navegador sin bundler
Sin paso de build: lo que escribís es lo que se sube al servidor.

Cuando contás que no usás build tools, la reacción típica en el mundo dev es de sorpresa, casi de sospecha. ¿Cómo vas a laburar sin bundler, sin transpilador, sin un pipeline de CI que compile todo antes de subirlo? La respuesta corta: para la mayoría de nuestros clientes, esas herramientas resuelven un problema que no tienen.

El contexto real de nuestros proyectos

Trabajamos con negocios locales: bares, radios, comercios, estudios chicos. Sitios que se despliegan por FTP o cPanel, en hostings compartidos, sin acceso a terminal ni a un pipeline de deploy automatizado. En ese contexto, un proyecto armado con Webpack o Vite agrega una capa entera de complejidad que nadie del otro lado va a poder tocar ni mantener si nosotros no estamos.

Con HTML, CSS y JS plano, lo que ves en el editor es exactamente lo que se sube al servidor. No hay paso de build que pueda romperse, no hay node_modules que versionar, no hay que explicarle a un cliente por qué de repente el sitio no compila.

Deploys sin fricción

Subir un cambio es literalmente arrastrar un archivo por FTP o pegarlo en el file manager de cPanel. Eso significa que un ajuste chico —cambiar un texto, un precio, una imagen— se resuelve en minutos, sin depender de que ande un pipeline, sin esperar un build en la nube.

Para dependencias externas, usamos CDN en vez de instalar paquetes: Tone.js, MediaPipe, lo que haga falta, se carga directo desde un script tag. Es la misma lógica: menos capas entre el código y lo que efectivamente corre en el navegador del usuario.

No es una limitación, es una elección

Sabemos usar frameworks y herramientas de build, y cuando un proyecto realmente lo justifica —una app compleja, con estado difícil de manejar a mano, con un equipo grande trabajando en paralelo— las usamos sin problema. Pero para la mayoría de los sitios y productos que vendemos, vanilla es la opción más rápida de construir, más fácil de mantener y más barata de operar.

La herramienta correcta no es la más nueva. Es la que tu cliente puede sostener después de que te vayas.

Esa es la lógica que nos guía: menos dependencias, menos puntos de falla, más control real para quien se queda con el sitio.