Por qué JavaScript vanilla
Los defensores de JavaScript “vanilla” sostienen que los navegadores modernos, Web Components y pequeños ayudantes personalizados bastan para muchas aplicaciones, y que frameworks grandes como React o Angular a menudo introducen complejidad innecesaria, herramientas de compilación y sobrecarga de rendimiento, sobre todo para equipos pequeños o interfaces simples. Otros replican que los frameworks se ganan su lugar en proyectos moderadamente complejos o de larga vida al imponer estructura compartida, patrones predecibles y una incorporación más fácil, aunque añadan abstracción y cambios constantes. Varios participantes señalan además cómo TypeScript, JSDoc y los LLMs vuelven a cambiar la balanza, facilitando trabajar directamente con la plataforma sin perder seguridad de tipos ni soporte de generación de código.
Ámbito de JS vanilla frente a frameworks
- Muchos coinciden en que JavaScript vanilla es viable y agradable para proyectos pequeños o personales: menos dependencias, sin paso de compilación, control total del navegador “como framework”.
- Varios sostienen que el JavaScript moderno (características de ES5+), junto con las Web APIs, ya es suficiente para que los frameworks pesados sean a menudo innecesarios para CRUD básico y “interactividad dispersa”.
- Otros replican que, para cualquier “interfaz de usuario moderadamente compleja”, los enfoques vanilla tienden a acumularse hasta convertirse en un framework a medida, poco documentado, con decisiones de diseño ad hoc.
Trabajo en equipo, estructura y escalado
- Tema fuerte: los frameworks ofrecen convenciones compartidas, previsibilidad y límites de seguridad para los equipos, especialmente a medida que crecen las bases de código y el número de personas.
- Usar un framework popular simplifica la contratación y la incorporación; los nuevos desarrolladores y los LLMs ya conocen los patrones.
- Los críticos señalan que los propios frameworks se fragmentan (variantes de React, gestores de estado, sistemas de estilos), así que elegir uno no elimina por completo el desacuerdo ni la complejidad.
Web Components y abstracciones “ligeras”
- Algunos defienden Web Components y JavaScript vanilla modular como un punto intermedio escalable: interfaces de usuario componentizadas, importaciones dinámicas y pools de componentes compartidos sin herramientas pesadas.
- Otros ven las abstracciones personalizadas del artículo (incluido EHTML) como microframeworks de facto, añadiendo otra capa a medida que aprender.
Sistemas de tipos y herramientas
- Varios comentarios promueven TypeScript o JSDoc/@ts-check para comprobación estática, con desacuerdo sobre si un paso de compilación es aceptable o necesario.
- Hay escepticismo sobre configuraciones “sin build” para aplicaciones complejas debido a la falta de minificación/división de código y a la fragilidad a largo plazo de las herramientas personalizadas.
Rendimiento, UX y decisiones de arquitectura
- Debate sobre SPA frente a aplicaciones multipágina: algunos insisten en que las MPA son rápidas con una buena caché; otros dicen que las SPA pueden sentirse más ágiles y dinámicas.
- Varios critican a React por añadir latencia y complejidad a interfaces que solo necesitan unas pocas actualizaciones del DOM; otros ven React como un poderoso “destornillador eléctrico” para SPA grandes.
LLMs y el futuro de los frameworks
- Algunos esperan que los LLMs reduzcan la necesidad de grandes frameworks al facilitar el trabajo directo con las APIs de la plataforma o pequeños ayudantes.
- Otros señalan que los frameworks actúan como límites de seguridad para el código no determinista generado por LLMs, y que los LLMs ya funcionan bien con stacks convencionales como React/TypeScript.