HTML First, el renacimiento de las etiquetas y la madurez de Javascript

Actualmente, no es raro ver a desarrolladores frontend que cansados de la batalla constante con frameworks, han decidido volver al origen: escribir HTML puro, cuidar el CSS y dejar a JavaScript el papel de actor de reparto, no de protagonista. ¿Nostalgia? Para nada.

Esto no es más que una corrección consciente, una reacción a más de una década en la que «JavaScript first» nos hizo la vida compleja a cambio de una web que a veces, ni siquiera funcionaba sin JavaScript lo que es un auténtico peligro para muchos usuarios.

La gran resaca de los frameworks

Durante más de 10 años, el desarrollo web se movió en la onda JavaScript primero. Los sitios eran Single Page Applications (SPAs) donde todo se generaba, cambiaba o destruía con JS.

La parte del HTML y CSS quedaron escondidos tras toneladas de lógica, componentes y hooks, inexplicablemente.

Mientras que la promesa eran interfaces ultra dinámicas y wow, la realidad era que esa implementación terminaba por traer infinidad de problemas extra a la carga de trabajo:

• Páginas en blanco hasta que se «recargaba» el JS.
• SEO y accesibilidad colapsada (crawlers o lectores de pantalla a veces ni veían el contenido).
• Desarrolladores convertidos en operadores de pipelines, configurando bundlers, luchando contra errores de carga y optimizando gráficos de dependencias.
• Sitios más lentos y complicados de mantener.

Esto llevó a una pregunta incómoda: ¿Realmente estabamos resolviendo problemas o solo construyendo castillos de naipes que no tardarían demasiado en caer?

La ascensión del HTML limpio y el encanto de la simplicidad

Ahora, una nueva camada de herramientas y filosofías ha puesto de moda decir: HTML primero y después, el framework. Ejemplos como Astro, HTMX, Enhance o MarkoJS son la perfecta muestra de ello.

La premisa es simple: el HTML proporciona la estructura, el CSS lo embellece y el JavaScript solo debe añadir lo que de verdad mejora la experiencia.

Herramientas HTML first

1. Astro permite entregar sitios con “cero JavaScript por defecto”: escribes HTML y CSS y solo añades JS si lo necesitas.
2. HTMX te deja enviar HTML dinámico al navegador usando simples atributos, sin tener que cargar una app JavaScript mastodóntica.

3. MarkoJS, Enhance y otros siguen la idea de la mejora progresiva. En donde, si no existe JS, el sitio aún sigue funcionando.

¿Qué tienen en común estos enfoques?

• Los sitios cargan más rápido.
• La accesibilidad es prioridad.
• Son más sencillos de mantener.
• Se rebaja la curva de aprendizaje para nuevos desarrolladores.

El JavaScript no desaparece, simplemente crece

Lejos de desaparecer, JavaScript está madurando; ya no es el héroe omnipresente que todo lo resuelve. Su papel es más sutil y sinceramente, más inteligente:

• Renderizado del lado servidor (SSR): React, Next.js, SvelteKit y similares ahora recomiendan usar más procesamiento en el server.
• Componentes «el servidor primero»: React Server Components, Remix, Vue y otros están cambiando el paradigma para procesar en el server y enviar páginas ya listas al navegador.
• HTML y CSS vuelven a controlar el contenido y el estilo, usando el JS como extensión, no como un único motor.

Incluso los gigantes como Google y Shopify están apostando por arquitecturas «HTML primero» o basadas en «islas», donde solamente las partes necesarias usan JavaScript dinámico.

¿Por qué importa este cambio?

Esto no es solo un debate para geeks, existe un importante impacto directo en la experiencia de usuario y la productividad del equipo.

Estas son las mejoras que verás implementarse en tus proyectos si apuestas por el HTML primero «HTML first» por encima del framework y los sitios web más cargados.

• Rendimiento: Carga más rápida (HTML y CSS llegan primero).
• Accesibilidad real: Sin JS, tu sitio sigue mostrando contenido, y los screen readers no pierden nada.
• Sitios más robustos: Soportan caídas parciales y degradan con gracia si algo falla.
• Curva de aprendizaje menor: Las nuevas generaciones pueden aprender lo esencial del web sin memorizar 1000 APIs de JS o perderse en JSX y configuraciones de bundlers.
• SEO sin hacks: Al estar el contenido en el HTML, Google y similares pueden indexar todo sin problemas.

Por si fuera poco, Google ahora toma muy en cuenta la velocidad y experiencia de carga (Core Web Vitals), por lo que NO basta con tener muchos features: Importa cómo, cuándo y cuánto tarda en aparecer lo importante, y el html first encaja perfectamente con esto.

¿Puede escalar una app HTML first?

La duda más típica entre los grandes equipos de desarrolo es, ¿Y qué hacer con los proyectos más gigantes?, ¿No necesitarán aún todo el poder de los frameworks si desean escalar? Cada vez más, la respuesta actual es: Sí, si se puede escalar un proyecto basado principalmente en HTML.

Algunas herramientas, como Enhance o Qwik, muestran cómo la mejora progresiva puede convivir con la carga diferida de JS, actualizaciones dinámicas y la escalabilidad. Solamente que ahora la complejidad es opcional, modular y deliberada.

Cuando dejas de tratar el navegador como un lienzo idiota y realmente aprovechas lo que ofrece nativamente (formularios, urls, el DOM, animaciones CSS) vas a poder llegar realmente mucho más lejos de lo que creías.

La complejidad sigue existiendo, sí, pero se vuelve una elección consciente y no una trampa predeterminada.

¿Qué es lo que los devs deberían aprender en 2025?

Si has pasado años pensando en props, state y routers solo del lado del cliente, el cambio puede llegar a parecerte demasiad raro; pero no se trata de renunciar a tus skills, sino a re-aprender lo básico y re-descubrir la esencia de la web:

• Escribir HTML semántico, accesible y claro.
• Entender los verbos HTTP y considerar más el renderizado del lado del servidor para manejar estados.
• Dominar las capacidades de CSS nativo (animaciones, consultas de medios, consultas del contenedor).
• Diseñar interacciones basadas en formularios y urls navegables, en vez de esconder todo detrás de APIs exclusivas de JavaScript.

Se trata de pensar la arquitectura y la entrega desde el inicio; de ser intencionales en la elección de cada capa.

El futuro se basa en capas y NO en pilas

Los frameworks no van a morir. Pero empiezan a ocupar su sitio correcto: como un potencial extra y no como una base sobre la que construir.

El HTML es la estructura, el CSS el diseño y el JavaScript se encarga de darle vida (exclusivamente cuando es necesario). Este enfoque es mucho más maduro; y sí, puede ser que con todos estos cambios, estemos llegando a la mayoría de edad de JavaScript: menos dogmatismo y más pragmatismo, una web que sirve a los usuarios y no solamente a los desarrolladores.

Al final, el «HTML first» no es resignación: Es una evolución hacía la utilidad, facilidad y sencillez. Es escoger las mejores herramientas, en el orden correcto. Y es, curiosamente, lo que la web siempre ha planteado desde el inicio.

¿Tú también sientes qué ha llegado el cambio? ¿Probaste trabajar HTML primero y JavaScript después? ¡Quizás sea el momento de redescubrir lo fácil que puede ser el desarrollo web cuando cada capa hace realmente lo que debería hacer!