En la comunidad de desarrollo web actual, parece que hay un nuevo framework de JavaScript cada semana. React, Vue, Angular, Svelte, Solid.js, Qwik... la lista es interminable y el "JavaScript fatigue" (fatiga por la cantidad de herramientas) es un fenómeno bien documentado entre los desarrolladores. Sin embargo, en JCódigos apostamos fuertemente por Vanilla JS para nuestras plantillas interactivas. En este artículo, explicaremos el porqué y cuándo tiene sentido usar cada alternativa.
1. ¿Qué es realmente "Vanilla JS"?
El término "Vanilla JavaScript" o "Vanilla JS" se refiere al lenguaje JavaScript puro, sin ninguna librería ni framework adicional. Es una broma de la comunidad de desarrolladores que surgió como respuesta a la proliferación de librerías: si buscas "Vanilla JS" en internet, encontrarás un sitio web satírico que lo describe como "la librería de JS más ligera del mundo".
En términos prácticos, usar Vanilla JS significa trabajar directamente con las APIs que el navegador expone de forma nativa: document.querySelector() para seleccionar elementos, addEventListener() para escuchar eventos, fetch() para hacer peticiones de red y las APIs de animación como requestAnimationFrame(). Todo esto sin necesidad de descargar ni instalar ninguna dependencia.
2. Los frameworks: ¿para qué sirven realmente?
Los frameworks modernos como React, Vue y Angular no surgieron por capricho. Nacieron para resolver problemas concretos que aparecen cuando se construyen aplicaciones web de gran escala con decenas de desarrolladores trabajando en paralelo. Los principales problemas que resuelven son:
- Gestión de estado complejo: Cuando la interfaz depende de muchos datos que cambian frecuentemente y de forma interdependiente (como un carrito de compras en Amazon con miles de productos).
- Renderizado del lado del servidor (SSR): Para mejorar el SEO y la velocidad percibida en aplicaciones con mucho contenido dinámico.
- Componentización a gran escala: Dividir la aplicación en piezas reutilizables que decenas de desarrolladores pueden trabajar de forma independiente sin pisarse entre sí.
- Ecosistema de herramientas: Testing automatizado, hot-reloading durante el desarrollo, optimización automática del bundle, etc.
Estos son problemas reales... en aplicaciones como Facebook, Airbnb o YouTube. Si estás construyendo una carta interactiva de cumpleaños, una landing page de portafolio o una sorpresa romántica digital, ninguno de estos problemas existe.
3. La sobreingeniería: el enemigo de la accesibilidad
Usar un framework para tareas triviales añade una carga innecesaria al proyecto. React, por ejemplo, tiene un tamaño base de aproximadamente 130KB minificado (la versión de producción). Vue es algo más liviano con ~80KB. Esto puede parecer poco, pero considera que una plantilla de regalo digital básica puede tener solo 15-20KB de código propio. Añadir un framework significa multiplicar el peso de tu proyecto por 5 o 10 veces.
Esto tiene consecuencias directas en la experiencia del usuario:
- Mayor tiempo de carga: Especialmente en conexiones móviles lentas de 3G o en zonas rurales con conectividad limitada.
- Mayor consumo de datos: Si alguien abre tu regalo desde datos móviles, un archivo más pesado le consume más plan de datos.
- Mayor complejidad de mantenimiento: Los frameworks se actualizan constantemente. Un proyecto creado en React 16 puede romper en React 18 por cambios en la API.
- Barrera de entrada más alta: Si quieres compartir el código fuente para que el usuario lo edite, necesitarán instalar Node.js, npm, ejecutar comandos de terminal... algo imposible para la mayoría.
"La herramienta correcta para el trabajo correcto no siempre es la más moderna o la más popular. A veces, la herramienta correcta es la más simple."
4. El rendimiento del DOM nativo en 2025
Uno de los argumentos históricos a favor de frameworks como React era que su "Virtual DOM" era más eficiente que manipular el DOM real directamente. En los años 2010, esto era cierto: los navegadores de la época eran lentos manipulando el DOM y el Virtual DOM de React era una solución inteligente.
En 2025, este argumento está casi completamente obsoleto. Los navegadores modernos (Chrome V8, Firefox SpiderMonkey, Safari JavaScriptCore) han invertido masivamente en optimizar la manipulación del DOM real. Para proyectos de escala pequeña o mediana, el rendimiento del Vanilla JS es indistinguible o incluso superior al de frameworks con Virtual DOM, ya que elimina la capa de abstracción intermedia.
El propio equipo de Svelte, el framework creado por Rich Harris (ex New York Times), llegó a la misma conclusión y diseñó su framework para compilar a JavaScript puro sin Virtual DOM. La tendencia en la industria apunta hacia "menos capa de abstracción, más código nativo".
5. El enfoque de JCódigos: simplicidad como estándar
Nuestros productos, como cartas interactivas, portafolios creativos y componentes web 3D, están diseñados bajo tres principios que nos parecen irrenunciables:
- Fácil de editar sin conocimientos avanzados: Si descargas un código gratuito nuestro, puedes abrirlo en el Bloc de Notas de Windows, cambiar un texto con Ctrl+F y guardarlo. Si usáramos React, tendrías que instalar Node.js, correr
npm install, compilar connpm run build, etc. Eso es una barrera que excluye a la mayoría de nuestros usuarios. - Compatibilidad universal garantizada: Un archivo HTML + CSS + JS funciona en cualquier servidor, en cualquier servicio de hosting gratuito (Netlify, GitHub Pages, Tiiny.host, Vercel), en cualquier año. Un proyecto compilado con Webpack o Vite puede tener incompatibilidades con actualizaciones futuras de dependencias.
- Carga instantánea en móviles: El 87% del tráfico de JCódigos proviene de dispositivos móviles. Cada kilobyte de más en el bundle se traduce en milisegundos de carga perdidos. La velocidad de carga es directamente proporcional a la probabilidad de que el receptor del regalo se lo envíe a alguien más.
6. ¿Cuándo SÍ deberías usar un framework?
Esta es una guía honesta, no un manifiesto antiframeworks. Los frameworks tienen su lugar y son la herramienta correcta en muchos contextos:
- Cuando tienes un equipo de 5+ desarrolladores trabajando en la misma codebase.
- Cuando la aplicación tiene un estado complejo que se actualiza en tiempo real (dashboards de analítica, aplicaciones de chat, editores colaborativos).
- Cuando necesitas renderizado del lado del servidor (SSR) para SEO avanzado.
- Cuando la aplicación tiene más de 50 componentes de UI distintos que se reutilizan en múltiples contextos.
Si alguno de esos puntos describe tu proyecto, entonces sí, usa React, Vue o el framework que mejor se adapte a tu equipo. Si no, considera seriamente si realmente necesitas la complejidad adicional.
Conclusión
La habilidad más importante de un buen desarrollador no es conocer el framework más reciente, sino saber elegir la herramienta correcta para cada trabajo. En JCódigos, hemos elegido Vanilla JS porque resuelve perfectamente nuestros problemas, empodera a nuestros usuarios para personalizar el código por sí mismos y garantiza que cada plantilla funcione durante años sin mantenimiento adicional. Eso es ingeniería inteligente, no limitación técnica.