JavaScript no necesita más frameworks

Abrís un proyecto nuevo y antes de escribir la primera línea útil ya estás instalando React, Next.js, tres librerías de estado, dos de formularios y una de animaciones. El package.json tiene 47 dependencias y ni siquiera mostraste un "Hola mundo". JavaScript moderno es tan poderoso que la mayoría de los frameworks que instalás están resolviendo problemas que ya no existen.

No es una crítica a los frameworks, es un recordatorio de que JavaScript vanilla evolucionó. Fetch API, async/await, módulos ES6, template literals, optional chaining, destructuring. Todo eso que antes necesitaba Lodash, jQuery o Babel ahora viene de fábrica. Y sin embargo, seguimos tratando al lenguaje como si fuera el JavaScript del 2010.

El costo oculto de abstraer todo

Cada framework que sumás a tu stack agrega tres capas de complejidad: la configuración inicial, la curva de aprendizaje y el mantenimiento futuro. La mayoría de las aplicaciones web no necesitan server components, streaming SSR o hydration parcial. Necesitan mostrar datos, validar un formulario y hacer requests HTTP.

El problema no es técnico, es cultural. Nos acostumbramos a buscar soluciones antes de entender el problema. "Necesito hacer una request" → instalar Axios. "Necesito renderizar una lista" → instalar React. "Necesito ruteo" → instalar React Router. Y así hasta que el bundle pesa 400KB y el sitio tarda 3 segundos en ser interactivo.

Ejemplo real: Una página de checkout que solo necesitaba validar un formulario y enviar datos a una API terminó con 18 dependencias. Migrarla a JavaScript vanilla redujo el bundle de 380KB a 45KB y el tiempo de carga se dividió por cuatro. Mismo resultado, menos abstracción.

Lo que JavaScript ya hace mejor que cualquier librería

Manipulación del DOM sin jQuery

// Antes (jQuery)
$('.button').on('click', function() {
  $(this).addClass('active');
  $('.modal').fadeIn();
});

// Ahora (JavaScript vanilla)
document.querySelectorAll('.button').forEach(button => {
  button.addEventListener('click', () => {
    button.classList.add('active');
    document.querySelector('.modal').classList.add('visible');
  });
});

querySelector, querySelectorAll, classList, addEventListener. Todo lo que hacía jQuery está en el lenguaje desde hace años. Y es más rápido porque no hay capa de abstracción.

Requests HTTP sin Axios

// Fetch con manejo de errores completo
async function getUserData(id) {
  try {
    const response = await fetch(`/api/users/${id}`, {
      method: 'GET',
      headers: { 'Content-Type': 'application/json' }
    });
    
    if (!response.ok) {
      throw new Error(`HTTP error: ${response.status}`);
    }
    
    const data = await response.json();
    return data;
  } catch (error) {
    console.error('Error fetching user:', error);
    return null;
  }
}

Fetch API nativa soporta async/await, permite configurar headers, maneja diferentes tipos de respuesta y funciona en todos los navegadores modernos. No necesitás Axios para el 95% de los casos.

Estado reactivo sin frameworks

// Estado reactivo con Proxy (nativo desde ES6)
function createStore(initialState) {
  const listeners = new Set();
  
  const state = new Proxy(initialState, {
    set(target, property, value) {
      target[property] = value;
      listeners.forEach(listener => listener(state));
      return true;
    }
  });
  
  return {
    state,
    subscribe: (fn) => listeners.add(fn),
    unsubscribe: (fn) => listeners.delete(fn)
  };
}

// Uso
const store = createStore({ count: 0 });

store.subscribe((state) => {
  document.querySelector('#counter').textContent = state.count;
});

store.state.count++; // El DOM se actualiza automáticamente

15 líneas de código y tenés reactividad. Sin Vue, sin Svelte, sin magic. Proxy es parte de JavaScript desde ES6 y permite observar cambios en objetos de forma nativa.

Cuándo sí tiene sentido usar un framework

No todo es blanco o negro. Los frameworks resuelven problemas reales en contextos específicos:

• React/Vue/Svelte: Aplicaciones con cientos de componentes interconectados, estado complejo compartido entre múltiples vistas.
• Next.js/Nuxt: SEO crítico + contenido dinámico + necesidad de SSR real.
• Astro: Sitios de contenido con islas de interactividad mínima.

La pregunta clave: ¿el problema que estás resolviendo justifica la complejidad que estás agregando? Si tu aplicación tiene 5 pantallas y 3 formularios, probablemente no.

Patrones modernos sin dependencias

Template literals para componentes

function UserCard({ name, email, avatar }) {
  return `
    <div class="user-card">
      <img src="${avatar}" alt="${name}">
      <h3>${name}</h3>
      <p>${email}</p>
    </div>
  `;
}

// Renderizar
document.querySelector('#app').innerHTML = UserCard({
  name: 'Ana García',
  email: 'ana@example.com',
  avatar: '/avatars/ana.jpg'
});

Template literals permiten crear componentes reutilizables sin JSX ni compiladores. Puro JavaScript.

Módulos ES6 para organización

// utils/validation.js
export function validateEmail(email) {
  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
}

export function validateRequired(value) {
  return value.trim().length > 0;
}

// main.js
import { validateEmail, validateRequired } from './utils/validation.js';

const form = document.querySelector('#signup-form');
form.addEventListener('submit', (e) => {
  e.preventDefault();
  const email = form.elements.email.value;
  
  if (!validateRequired(email) || !validateEmail(email)) {
    alert('Email inválido');
    return;
  }
  
  // Enviar formulario
});

Módulos nativos funcionan en todos los navegadores modernos. No necesitás Webpack para tener código organizado.

Web Components para reusabilidad

class ToggleButton extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
  }
  
  connectedCallback() {
    this.shadowRoot.innerHTML = `
      <style>
        button { padding: 10px 20px; }
        button.active { background: #007bff; color: white; }
      </style>
      <button>Toggle</button>
    `;
    
    const button = this.shadowRoot.querySelector('button');
    button.addEventListener('click', () => {
      button.classList.toggle('active');
      this.dispatchEvent(new CustomEvent('toggle', {
        detail: { active: button.classList.contains('active') }
      }));
    });
  }
}

customElements.define('toggle-button', ToggleButton);

// Uso: <toggle-button></toggle-button>

Web Components son estándar del navegador. Encapsulación, shadow DOM, eventos personalizados. Todo nativo.

El problema de la sobre-ingeniería

La industria tiene un sesgo hacia la complejidad. Un desarrollador que implementa microservicios con Kubernetes parece más senior que uno que resuelve el mismo problema con un monolito bien estructurado. Lo mismo pasa con JavaScript: usar el último framework de moda se percibe como "saber más" que dominar el lenguaje base.

Pero la realidad es inversa. Conocer JavaScript profundamente te permite evaluar si un framework aporta valor o solo agrega capas. La mejor arquitectura no es la más sofisticada, es la más simple que resuelve el problema.

Checklist antes de instalar un framework:

1. ¿Probé resolver esto con JavaScript vanilla primero?
2. ¿El framework reduce complejidad o solo la mueve?
3. ¿Mi equipo va a mantener esto en 6 meses?
4. ¿El peso del bundle está justificado por la funcionalidad?
5. ¿Estoy eligiendo esto porque lo necesito o porque está de moda?

Si la respuesta a 3 o más es dudosa, probablemente no necesitás el framework.

Preguntas frecuentes

¿JavaScript vanilla escala para aplicaciones grandes?
Sí, pero requiere disciplina. Módulos ES6, patrones consistentes y buena arquitectura son clave. Gmail estuvo años en JavaScript vanilla antes de migrar a frameworks internos. La escala no la define el framework, la define la organización del código.

¿Los frameworks no hacen el desarrollo más rápido?
En proyectos complejos, sí. En proyectos simples, no. El tiempo que ahorrás en no configurar bundlers, no lidiar con breaking changes y no debuggear abstracciones suele compensar escribir algunas líneas más de código.

¿Qué navegadores soportan JavaScript moderno?
Todos los evergreen browsers: Chrome, Firefox, Safari, Edge. Si necesitás soportar IE11 (que ya está deprecado), ahí sí podrías necesitar transpilación. Pero en 2024, la compatibilidad dejó de ser excusa.

Tu próximo proyecto sin dependencias

La próxima vez que vayas a crear un proyecto nuevo, intentá esto: empezá con un archivo HTML, un archivo CSS y un archivo JavaScript. Sin bundlers, sin frameworks, sin configuración. Resolvé el problema más simple primero. Agregás complejidad solo cuando la necesites, no de forma preventiva.

Checklist para empezar:

• Estructura HTML semántico con etiquetas nativas
• CSS moderno (grid, flexbox, custom properties)
• JavaScript modular con imports/exports
• Fetch API para comunicación HTTP
• Local Storage para persistencia simple
• Template literals para templates dinámicos
• Event delegation para manejo de eventos eficiente

JavaScript no necesita más frameworks. Necesita más desarrolladores que entiendan el lenguaje lo suficiente como para saber cuándo no necesitan uno.