Los frameworks tienen lugar cuando el tamaño del producto lo justifica, pero existe un espacio enorme donde vanilla JavaScript bien organizado aporta claridad de dependencias y coste de entrada bajo tanto para desarrolladores como para operaciones.
El error habitual es usar «vanilla» como sinónimo de archivo único gigante. La solución está en aplicar mentalidad de componentes sin imponer un runtime específico.
Qué entiendo por componente en este contexto
Un componente no es necesariamente un JSX: es una pieza autocontenida con comportamiento conocido en el cliente, marca accesible y estilos con alcance definido (scope). Puede exponer métodos públicos claros como mount, destroy o callbacks registrados mediante eventos del DOM estándar.
La clave es que nadie llega al interior del DOM ajeno. Si necesitas comunicación, usa Custom Events o un canal pequeño de mensajes en memoria donde los módulos se suscriben por nombre de tema, no por referencias imperativas entre todos.
Estructura de carpetas que escala tranquilamente
Un patrón que funciona muy bien para sitios contenido-pesados o paneles intermedios:
components/con una carpeta por bloque (hero/,filter-bar/, …) conteniendoComponent.ts,styles.css, y cuando haga faltatemplate.htmlo helpers.lib/para utilidades compartidas sin acoplar a UI.pages/solo como composición que importa y monta componentes.
Las hojas de estilo pueden importarse desde el mismo módulo o concatenarse por build si usas Astro, Vite o similar —lo importante es co-localizar.
Rendimiento percibido y bundle
Ventaja directa reducida: solo cargas el JS del componente donde el HTML lo marca. Comparado con un árbol de React que inicializa incluso vistas no vistas, bien encajado el vanilla permite hidratar con coste proporcional.
Eso ayuda cuando el equipo prioriza Lighthouse o mercados donde la velocidad influye fuertemente en conversión —tema relacionado de hecho con otras auditorías que publico sobre Core Web Vitals.
Migración cuando el proyecto crece
El camino habitual es partir de markup estático bien semántico y añadir capas incrementales:
- Estado local en cada componente antes de exponer estado global compartido.
- Una capa mínima de «router» que solo muestra/oculta secciones o delega URLs.
- Opcional más adelante: adoptar herramientas que compilen al mismo modelo Web Components si quieres reutilización multi-proyecto.
Conclusión
Arquitectura basada en componentes no necesita sintaxis JSX ni un virtual DOM. Lo que necesita son contratos claros, límites y disciplina igual que cualquier equipo front maduro —con la ventaja añadida de que cargas menos abstracción cuando el proyecto aún puede permitírselo.