Construir un sitio HTML-first duplicó nuestros usuarios de la noche a la mañana

HTML-first y mejora progresiva

• Muchos ven la historia como un caso de estudio sólido a favor de sitios HTML-first, mejorados progresivamente, especialmente para servicios públicos y formularios.
• Los patrones web clásicos (enlaces, formularios, redirecciones, “wizards” de varias páginas) son elogiados por:
  • Funcionar con JS desactivado o roto.
  • Dar a los usuarios comportamientos de navegador integrados (atrás/adelante, interfaz de validación, foco, acceso por teclado).
  • Reducir los modos de fallo invisibles comunes en las SPA (spinners, errores JSON silenciosos).
• Algunos señalan que esto es, en esencia, un redescubrimiento de la “mejora progresiva” y de lo que marcos como Rails/Django han fomentado durante mucho tiempo.

React, SPA y rendimiento

• Un tema recurrente es la frustración con stacks pesados de React/SPA, pasos de build y megabytes de JS para formularios básicos o contenido mayormente estático.
• Varios argumentan que, aunque sí puedes construir una buena UX con React, es más fácil crear aplicaciones malas, frágiles, inaccesibles o infladas:
  • Los valores predeterminados se inclinan hacia el renderizado en el cliente y widgets personalizados en lugar de HTML semántico.
  • Muchos desarrolladores no saben cómo construir formularios que funcionen sin JS.
• Otros discrepan: el problema real es el diseño y la habilidad del desarrollador, no el framework en sí; también puedes publicar React solo con HTML o sitios renderizados en servidor y lentos.

Astro, HTMX, Go y otros stacks

• Astro recibe elogios repetidos por apostar por HTML estático por defecto y por islas de JS “opt‑in”, a diferencia de la tendencia “opt‑out” de React/Next.
• HTMX + Go + SQLite se cita como un stack “aburrido pero efectivo” para muchas apps, con JS mínimo y despliegue sencillo.
• Algunos comentan Hotwire, enfoques móviles impulsados por el servidor, generadores de sitios estáticos (Jekyll) y SSR simple como alternativas viables.

Accesibilidad, dispositivos y empatía con el usuario

• Los comentaristas destacan usuarios reales en teléfonos de gama baja, navegadores antiguos, consolas o conexiones malas; estos usuarios suelen ser invisibles para las analíticas basadas en JS.
• Hay debate sobre cuántos usuarios carecen realmente de JS o de TLS moderno:
  • Un lado: incluso si es ~1%, a menudo son los más vulnerables y los servicios (especialmente gubernamentales o de servicios públicos) deberían acomodarlos.
  • Otros argumentan que HTTPS-only y las prácticas intensivas en JS son ahora la norma, a veces impulsadas por políticas de navegadores y plataformas.
• Se habla de la edad y la alfabetización digital: muchos usuarios no técnicos (de todas las edades) carecen de modelos mentales de UIs complejas, así que los flujos simples y robustos importan.

Métricas, compensaciones y cultura

• Varios señalan que el resultado de “duplicó usuarios” en realidad trata de una mayor finalización de formularios / menor abandono, no de tráfico.
• Algunos enfatizan las compensaciones:
  • HTML-first puede implicar más trabajo de UI a medida y menos bibliotecas de componentes listas para usar.
  • Los equipos y los procesos de contratación están optimizados para React; desviarse puede parecer arriesgado o “más trabajo”.
• Hay una crítica más amplia a los incentivos de la industria: herramientas guiadas por la moda, poca atención a los fundamentos y escasa empatía por dispositivos lentos y usuarios desfavorecidos.