HTML primero

Reacción general a “HTML First”

• A muchos les gusta el impulso hacia un desarrollo más simple y centrado en HTML, especialmente para sitios pequeños/medianos y aplicaciones renderizadas en el servidor.
• Otros lo ven como una romantización de las prácticas de principios de los 2000 e ignora por qué los frameworks, las herramientas de build y la separación de responsabilidades se volvieron comunes.

HTML vs Frameworks (React, Vue, etc.)

• Pro-HTML-first:
  • La mayoría de las interfaces web son formularios e interactividad básica; el renderizado en servidor + “sprinkles” de JS (htmx, Alpine, etc.) suele ser suficiente.
  • Los frameworks imponen una complejidad pesada (gestión de estado, routing, cadenas de build) y pueden añadir ~50% de esfuerzo a proyectos que no necesitan comportamiento de SPA.
  • Bueno para la facilidad de aprendizaje y “View Source” como herramienta de enseñanza y depuración.
• Escépticos:
  • Para aplicaciones más grandes y con estado (dashboards, motores de reservas, herramientas ricas), los frameworks ayudan a gestionar la complejidad, la reutilización y los flujos de trabajo del equipo.
  • Sin ellos, los equipos tienden a reinventar mini-frameworks ad hoc y aun así luchar con las particularidades del navegador.
  • Muchos desarrolladores valoran usar una sola pila potente en todas partes en lugar de dividir los modelos mentales.

Atributos en línea, localidad y separación de responsabilidades

• Quienes apoyan onclick en línea / clases de utilidad argumentan:
  • La “localidad del comportamiento” (HTML, comportamiento y estilo juntos) hace que los componentes sean más fáciles de entender en un solo lugar.
• Los críticos argumentan:
  • Esto reintroduce precisamente el spaghetti que la separación de CSS/JS resolvió; es difícil de refactorizar y depurar a escala.
  • El JS en línea rompe o debilita CSP, aumenta la exposición a XSS y complica las revisiones de seguridad.
  • La accesibilidad se resiente (por ejemplo, un <div> clicable en lugar de un <button>).

CSS, Tailwind y diseño de clases

• Tailwind es elogiado por:
  • Evitar archivos CSS semánticos inmantenibles mediante la composición de pequeñas clases de utilidad.
  • Funcionar bien a nivel de componente y fomentar tokens de diseño consistentes.
• Críticas:
  • En la práctica convierte class en un segundo atributo style; el HTML se vuelve recargado.
  • Requiere un paso de build (purga/generación de CSS), lo que entra en conflicto con ideales de “sin build”.
  • Algunas mediciones sugieren que los bundles de Tailwind pueden ser más grandes que un CSS semántico bien diseñado.

HTMX, hyperscript y librerías “basadas en HTML”

• HTMX y Alpine se citan como buenas formas “HTML-first” de añadir interactividad sin SPAs completas.
• Preocupaciones:
  • Devolver HTML desde APIs puede enredar las preocupaciones del front-end y del back-end.
  • hyperscript es explícitamente un DSL personalizado, lo que contradice la propia advertencia del artículo contra las sintaxis personalizadas.
  • Algunos ven HTMX como adecuado para herramientas internas y aplicaciones modestas, no para frontends muy grandes.

Accesibilidad, UX y elementos nativos

• Muchos enfatizan la semántica nativa (<button>, <details>, <summary>, <datalist>, ARIA adecuada) como crucial para la accesibilidad y el soporte de teclado/lector de pantalla.
• Otros señalan que los controles nativos (selectores de fecha, multiselects) son inconsistentes, difíciles de estilizar y a menudo demasiado limitados, empujando a los equipos de vuelta a componentes JS personalizados.

Temas históricos / meta

• Varios comentarios enmarcan esto como otro giro de un ciclo recurrente: inline → separación CSS/JS → frameworks JS → ahora “HTML-first” de nuevo.
• Hay un fuerte desacuerdo sobre si esto es progreso genuino, una corrección de rumbo útil o simplemente la última moda.