Hace unos años, si alguien quería montar una página web sencilla, bastaba con un HTML limpio, un poco de CSS y quizás una pizca de JavaScript para darle vida. Hoy, en cambio, es habitual encontrarse con proyectos donde una simple landing de tres secciones arrastra decenas de dependencias, frameworks pesados y una infraestructura que parece sacada de la NASA.
La pregunta es: ¿cómo hemos llegado a este punto?
La respuesta está en la propia evolución de la web. Con el tiempo le hemos pedido más cosas: aplicaciones en tiempo real, colaboración entre usuarios, personalización instantánea. Para eso sí se necesitaban capas nuevas y herramientas más potentes. El problema fue que esa misma receta empezó a aplicarse también a lo que no lo requería. Un martillo útil, convertido en religión.
Hoy, muchos desarrolladores aprenden directamente en frameworks complejos porque es lo que enseñan los tutoriales y lo que piden las empresas. Copiar plantillas recargadas parece una buena idea cuando hay prisa. Y frente a un cliente, mostrar un stack moderno da sensación de sofisticación. El resultado es que lo llamativo se confundió con lo bueno , y lo rápido con lo correcto.
Pero el precio de esta complejidad se paga después. Cada dependencia es un posible punto de fallo. Cada actualización menor puede romper un proyecto entero. El framework de moda que hoy parece el futuro, mañana se convierte en legado difícil de mantener. Y lo peor: el rendimiento en móviles , que debería ser la prioridad, se desploma bajo el peso de tanto código innecesario.
Eso no quiere decir que los frameworks sean un error en sí mismos. Todo lo contrario: son imprescindibles cuando hay estado complejo , reglas de negocio, integraciones en tiempo real. Nadie discute que para un dashboard o una aplicación con lógica transaccional hacen falta esas herramientas. Pero ¿de verdad se necesitan para una web de campaña que durará tres meses? ¿Para un blog? ¿Para una página de producto?
Ahí está la trampa. Hemos olvidado que no todo contenido es una aplicación . Y que, muchas veces, la mejor solución sigue siendo la más simple: HTML semántico , CSS bien trabajado y un poco de JavaScript solo si aporta valor de negocio.
Lo curioso es que, poco a poco, la industria parece estar girando de nuevo hacia ese sentido común. Cada vez más equipos vuelven al enfoque HTML-first : páginas estáticas o generadas en servidor, con pequeños “islotes” de interactividad cuando realmente hacen falta. El resto, limpio, rápido y fácil de mantener. Porque la web no necesita capas infinitas de complejidad por defecto. Lo que necesita es criterio.
Y ese criterio pasa por una pregunta muy sencilla antes de empezar cualquier proyecto: ¿estás construyendo una aplicación o estás publicando contenido? Si es lo primero, usa las herramientas complejas que hagan falta. Si es lo segundo, vuelve a lo básico.
