Por qué volver a JavaScript puro hoy

Si llevas un tiempo trabajando en frontend, seguro has visto el mismo patrón repetirse: arrancas con una idea simple y, antes de darte cuenta, el proyecto ya depende de cinco librerías para resolver cosas que JavaScript puro ya hacía bastante bien. Un botón que abre un menú termina con una dependencia para el estado, otra para los estilos, otra para el render, otra para el build y otra para el test. El resultado no siempre es mejor. A veces solo es más pesado.

Volver a JavaScript puro no significa vivir en 2012 ni rechazar herramientas útiles por deporte. Significa mirar con más frialdad qué te aporta cada capa y qué costo real te está dejando. Si tú o tu equipo quieren reducir peso, complejidad y fricción de mantenimiento, vale la pena revisar cuándo el lenguaje base alcanza por sí solo.

El costo oculto de depender de demasiadas librerías

La primera ventaja de JavaScript puro es obvia solo cuando la comparas con un proyecto real: menos dependencias, menos puntos de falla. Cada paquete que agregas introduce versiones, cambios de API, vulnerabilidades, incompatibilidades y tiempo de actualización. No es teoría. En un equipo pequeño, una actualización que rompe algo puede comerse medio día o más entre revisar cambios, ajustar código y volver a probar.

Ese costo no siempre aparece en el ticket inicial. Se disfraza de velocidad. Instalas una librería y en 20 minutos resuelves un problema puntual. El problema llega después, cuando esa librería deja de ser tan pequeña, o cuando el ecosistema alrededor cambia y tú te quedas con una pieza que nadie quiere tocar. Si además usas varias, el mantenimiento se vuelve una suma de pequeñas obligaciones.

También hay un costo mental. Si para hacer una interacción simple necesitas recordar la API de tres paquetes, el equipo ya no está leyendo código, está interpretando convenciones ajenas. JavaScript puro reduce esa capa intermedia. Lo que ves en el archivo se parece más a lo que hace el navegador.

Menos dependencias, menos superficie de ataque

Menos paquetes no solo ayuda a mantener el código. También reduce la superficie de ataque. En frontend esto importa más de lo que parece, porque muchas aplicaciones cargan dependencias para cosas muy básicas: formateo, utilidades, animaciones, date handling o pequeños helpers. Cada paquete adicional es otra pieza que puede romperse o quedar desactualizada.

Si quieres revisar buenas prácticas de seguridad y manejo de dependencias, la documentación de npm es un buen punto de partida: https://docs.npmjs.com/ . No necesitas memorizar cada riesgo para entender la idea central: si no dependes de algo, tampoco heredas sus problemas.

Menos versiones, menos fricción entre equipos

Cuando un frontend vive sobre un stack con muchas capas, el onboarding se alarga. Una persona nueva no solo aprende el negocio; también aprende el framework, sus plugins, el patrón de estado, el sistema de build y las convenciones de cada dependencia. Eso puede estar bien en productos grandes, pero en equipos pequeños o medianos se vuelve fricción.

Con JavaScript puro, la curva se achata. No desaparece la complejidad del producto, pero sí desaparece parte de la complejidad impuesta por la herramienta. Para equipos distribuidos en LatAm, donde a veces conviven perfiles muy distintos y rotación más alta de la deseada, eso puede marcar diferencia.

Qué sí te da JavaScript puro en proyectos reales

JavaScript puro no es sinónimo de hacer todo a mano de forma artesanal. Es usar primero lo que ya trae el navegador y el lenguaje antes de traer una librería. En muchos casos, eso es suficiente. Menús, tabs, modales, validaciones simples, fetch de datos, manejo de eventos, almacenamiento local y pequeños estados de UI se resuelven con APIs estándar.

La ventaja práctica es que el comportamiento vive cerca del DOM y del navegador. No tienes que traducir tu intención a la sintaxis de una librería si el problema es simple. Eso hace que depurar sea más directo. Abres DevTools, ves el evento, el estado y el DOM. No hay una cadena larga de abstracciones en el medio.

Además, el código suele ser más portable. Si mañana cambias de framework o decides extraer un componente a otra app, la lógica escrita con APIs estándar tiene más probabilidades de sobrevivir sin reescritura total. No siempre será plug and play, pero sí más reutilizable.

Ejemplo simple: un menú desplegable

Este es el tipo de caso donde muchas veces no necesitas una dependencia. Un menú desplegable básico puede resolverse con unas pocas líneas:

<button id="menuButton" aria-expanded="false" aria-controls="menuList">
  Abrir menú
</button>
<ul id="menuList" hidden>
  <li>Perfil</li>
  <li>Configuración</li>
  <li>Cerrar sesión</li>
</ul>

<script>
  const button = document.getElementById('menuButton');
  const menu = document.getElementById('menuList');

  button.addEventListener('click', () => {
    const isOpen = !menu.hidden;
    menu.hidden = isOpen;
    button.setAttribute('aria-expanded', String(!isOpen));
  });
</script>

No hay magia aquí. Hay estado mínimo, accesibilidad básica y comportamiento claro. Si tu caso de uso es ese, meter una dependencia completa para manejar el mismo patrón suele ser exceso.

Cuando el navegador ya trae la solución

Muchos equipos cargan librerías para resolver problemas que el navegador ya cubre: fetch para peticiones, IntersectionObserver para visibilidad, localStorage para persistencia simple, classList para clases CSS, querySelector para selección de nodos. No todo debe hacerse con vanilla JavaScript, pero sí conviene preguntar si la dependencia aporta algo más allá de abstraer lo obvio.

La documentación oficial de MDN sobre fetch es una referencia útil para recordar que la plataforma ya resuelve bastante: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API . Si tu objetivo es una app simple o una interfaz con pocas interacciones, empezar por ahí suele ser más sensato que sumar otra capa.

Mantenibilidad: menos abstracción, más lectura directa

La mantenibilidad no se mide solo por cuántas líneas tiene un archivo. Se mide por cuánto tiempo tardas en entenderlo seis meses después. Un código de 80 líneas con una librería poco conocida puede ser más difícil de mantener que uno de 120 líneas escrito con APIs estándar y nombres claros.

JavaScript puro ayuda porque reduce la distancia entre intención y ejecución. Si ves un addEventListener, sabes qué pasa. Si ves fetch, sabes que hay una petición. Si ves classList.toggle, entiendes el efecto. En cambio, con demasiadas abstracciones, el equipo termina aprendiendo la librería en vez de entender el producto.

Eso no significa que toda abstracción sea mala. Significa que la abstracción debe pagar su renta. Si una dependencia te ahorra mucho trabajo repetitivo, bien. Si solo te ahorra escribir tres líneas, probablemente no compense el costo de mantenerla.

Señales de que una dependencia ya te está estorbando

Hay señales bastante claras de que una librería pasó de útil a pesada:

1. La usas para una sola función que el navegador ya resuelve.
2. Nadie del equipo entiende bien su API sin mirar la documentación.
3. Actualizarla requiere tocar código que no debería cambiar.
4. Su bundle pesa más que el problema que resuelve.
5. Tienes varios issues abiertos por incompatibilidades menores.

Si te reconoces en dos o más puntos, vale la pena reevaluar. No hace falta eliminar todo de golpe. A veces basta con reemplazar un módulo por una solución nativa en la siguiente iteración.

Tabla de comparación rápida

Peso, performance y experiencia de usuario

Hablar de peso no es un capricho de performance nerd. En frontend, el tamaño del bundle afecta el tiempo de carga, el tiempo hasta interactuar y la experiencia en redes lentas. No todos tus usuarios están en fibra óptica. En LatAm sigue siendo común navegar con móviles de gama media, datos limitados o conexiones inestables.

Menos JavaScript también significa menos trabajo de parseo y ejecución para el navegador. Eso no convierte automáticamente tu app en rápida, pero sí elimina una carga innecesaria. Si una interfaz puede funcionar con 20 KB menos de scripts, el usuario lo agradece aunque nunca vea el número exacto.

Aquí el punto no es obsesionarte con cada kilobyte. Es entender que el costo de agregar herramientas se acumula. Tres librerías pequeñas pueden terminar pesando más que una funcionalidad completa si no revisas el bundle con regularidad.

Qué revisar antes de sumar otra librería

Antes de instalar otra dependencia, conviene hacerte estas preguntas:

• ¿El navegador ya ofrece esta capacidad de forma nativa?
• ¿La librería resuelve un problema repetitivo o solo acelera una tarea puntual?
• ¿Cuánto pesa en producción y no solo en desarrollo?
• ¿Qué pasa si queda sin mantenimiento durante 12 meses?
• ¿El equipo la entiende o solo la copia?

Si la respuesta a varias de esas preguntas es incómoda, quizá no necesitas más código, sino menos capas.

Cuándo sí conviene usar un framework o una librería

Defender JavaScript puro no significa negar que los frameworks existan por una razón. Cuando tienes una app grande, con estado complejo, muchas vistas, routing avanzado, SSR, caché de datos, formularios pesados y un equipo grande, un framework puede ahorrarte tiempo real. La clave está en no usarlo por reflejo.

Si tu producto necesita composición de UI a gran escala, convenciones compartidas y una estructura clara para muchas personas, React, Vue, Svelte o Next.js pueden ser la mejor base. El error no es usar un framework. El error es usarlo para un problema que todavía era simple.

Hay una diferencia entre construir un dashboard de 30 pantallas y una landing con un formulario, un menú y una sección de preguntas frecuentes. En el segundo caso, JavaScript puro puede darte menos fricción, menos dependencia y menos mantenimiento futuro.

Regla práctica para decidir

Un criterio simple que usamos en equipos es este:

• Si el problema se resuelve con APIs nativas y menos de una jornada de trabajo, prueba primero sin dependencia.
• Si vas a repetir el patrón en varias pantallas y el código empieza a duplicarse, evalúa una abstracción.
• Si la librería solo existe para ahorrar tres líneas, probablemente no vale la pena.
• Si el negocio depende de esa pieza todos los días, revisa el costo de mantenerla con la misma seriedad que revisas el costo de contratar.

No es una regla rígida, pero sí evita decisiones por inercia.

Cómo volver a JavaScript puro sin romper tu equipo

No necesitas hacer una migración dramática. De hecho, suele salir mejor si empiezas por zonas pequeñas y medibles. El objetivo no es purificar el stack, sino bajar la complejidad donde más duele.

Empieza por identificar componentes o utilidades que dependan de librerías por costumbre, no por necesidad. Un date picker simple, un modal, un accordion, un tooltip básico, validaciones de formulario o un script de analytics pueden ser candidatos para reemplazo o simplificación.

También conviene medir. Si quitas una dependencia, compara bundle, tiempo de carga y facilidad de mantenimiento. Si no mejoras nada, no sigas por ideología. Si mejoras claridad y reduces peso, ya tienes una señal útil.

Plan de transición en 5 pasos

1. Haz inventario de dependencias y marca las que resuelven tareas simples.
2. Prioriza las que afectan más el bundle o tienen más fricción de mantenimiento.
3. Reescribe una pieza pequeña con APIs nativas y prueba en producción.
4. Documenta el patrón para que el equipo no vuelva a instalar una librería por defecto.
5. Repite solo si el cambio te ahorra tiempo o reduce peso de forma medible.

Un ejemplo de decisión práctica

Supón que tu equipo usa una librería de utilidades para manipular clases CSS, manejar eventos y hacer toggles. Si el uso real se limita a tres funciones nativas, probablemente puedas reemplazarla con classList, addEventListener y algunas funciones pequeñas propias. Eso no solo reduce dependencias; también hace que el código quede más alineado con el navegador.

Si en cambio esa misma librería ya sostiene parte importante de la arquitectura, cambiarla de golpe no es la mejor jugada. Ahí conviene evaluar costo de salida, riesgo de regresión y tiempo del equipo. Volver a JavaScript puro también es una estrategia de reducción de riesgo, no una cruzada.

Tabla resumen

JavaScript puro no es nostalgia. Es una forma de recuperar control sobre el frontend cuando el stack empieza a crecer por inercia. Si tú puedes resolver algo con menos piezas, menos dependencias y menos fricción, casi siempre vas a terminar con un sistema más fácil de mantener.

La pregunta correcta no es si puedes usar otra librería. La pregunta es si realmente la necesitas. Si la respuesta es no, el navegador ya te está ofreciendo bastante.