Hotwire: tecnología HTML over the wire

 (hotwired.dev)
2 puntos por GN⁺ 2024-06-03 | 1 comentarios | Compartir por WhatsApp
  • Hotwire es un enfoque para crear aplicaciones web modernas enviando HTML en lugar de JSON, con el objetivo de lograr una primera carga rápida y buena capacidad de respuesta sin mucho JavaScript
  • Como deja el renderizado en plantillas del servidor, puede mantener un flujo de desarrollo simple sin importar el lenguaje que se use
  • Los frameworks que 37signals creó para HEY se combinan entre sí para formar el ecosistema Hotwire, que abarca desde la web hasta múltiples plataformas
  • Turbo, el componente central, maneja transiciones de página, envío de formularios, división en componentes y actualizaciones parciales basadas en WebSocket sin escribir JavaScript
  • Stimulus complementa las interacciones personalizadas que no cubre Turbo, y Hotwire Native permite crear apps móviles nativas a partir de una aplicación web existente

Un enfoque de enviar HTML renderizado desde el servidor

  • Hotwire es un enfoque alternativo para construir aplicaciones web modernas mediante HTML-over-the-wire
  • En lugar de JSON, envía HTML por la red, lo que permite crear aplicaciones sin depender de mucho JavaScript
  • Busca una primera carga de página rápida, mantener el renderizado con plantillas del lado del servidor y ofrecer una experiencia de desarrollo más simple y productiva
  • La idea es no renunciar a la velocidad ni a la capacidad de respuesta que normalmente se esperan de una aplicación tradicional de una sola página
  • HTML-over-the-wire también puede usarse como referencia para crear tus propias herramientas, o se pueden usar tal cual los frameworks Hotwire que 37signals creó para HEY

El papel de Turbo, Stimulus y Hotwire Native

  • Turbo es el componente central de Hotwire
    • Ofrece técnicas complementarias para manejar con rapidez las transiciones de página y el envío de formularios
    • Divide páginas complejas en componentes y transmite actualizaciones parciales de la página mediante WebSocket
    • Proporciona estas funciones sin necesidad de escribir JavaScript
  • Stimulus se usa cuando hace falta código personalizado que Turbo por sí solo no cubre
    • Turbo normalmente resuelve al menos el 80% de las interacciones que tradicionalmente requerían JavaScript
    • Stimulus permite manejar estado y conexiones con un enfoque centrado en HTML
  • Hotwire Native es un framework web-first para crear aplicaciones móviles nativas
    • Proporciona las herramientas necesarias para crear apps móviles aprovechando una aplicación web existente

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-06-03
Opiniones en Hacker News

  • Existe una versión menos marketineada de esta función llamada htmx: https://htmx.org/
    Permite hacer este tipo de cosas con un solo archivo JavaScript, y aunque lo he visto usarse sobre todo con backends en Go, parece bastante flexible. Hace más o menos un año que vengo pensando en probarlo.

    • Al menos según Hacker News, diría que htmx tuvo muchísima más exposición.
      Solo en el último año hubo cientos de envíos en HN 0, e incluso hubo publicaciones que superaron los 1000 puntos. En cambio, Hotwire tuvo menos de 30 envíos en el último año 1, y el más popular de ellos es este artículo.
    • No entiendo eso de que htmx está menos marketineado. Es la primera vez que oigo hablar de Hotwire, pero htmx lo veo por todas partes.
      Con solo mirar un rato YouTube, los influencers de programación no paran de promover htmx con miniaturas de sus caras.
    • También vale la pena mencionar https://unpoly.com, que incluye otras funcionalidades.
    • Es posible que HTMX esté mejor marketineado que casi cualquier framework.
      También es muy activo en Twitter, aparece con frecuencia en el canal de YouTube de The Primeagen y es bastante popular.
    • ¿Menos marketineado? Siento que htmx aparece por todos lados en todas las plataformas sociales.

  • Si buscas algo parecido en PHP/Laravel, recomiendo mucho Livewire: https://laravel-livewire.com/
    Para proyectos más complejos sigo usando React, pero siempre resulta refrescante poder escribir todo en Blade/PHP y aun así mantener elementos de UI reactivos. Recuerdo haber visto también un paquete que permite renderizar componentes de React/Vue dentro de Livewire cuando hace falta: https://minglejs.unitedbycode.com/. Parece una vía de escape interesante cuando necesitas incorporar paquetes existentes.

  • Antes era bastante negativo con Hotwire/Livewire, pero ahora los veo como herramientas adecuadas según el contexto.
    Enviar plantillas parciales por el cable es un enfoque de hipermedia; simplemente hoy en día no solemos crear bien aplicaciones de hipermedia. Llegué hasta acá tras volver a leer htmx y el paper de REST de RTF, y aunque no creo que la hipermedia sea una arquitectura inherentemente superior, sí me parece una opción legítima entre varias, y es bueno que siga evolucionando aunque sea lentamente.

  • Es probablemente una de las formas más fáciles de crear una PWA sin meterse en la madriguera de React/Vue/Svelte.
    También las he usado y me parecen excelentes, pero comparadas con htmx se sienten más centradas en la experiencia del desarrollador que en la tecnología. La competencia entre ambas probablemente terminará dependiendo de con qué framework de backend se integre mejor cada una.

    • Si la app móvil es simplemente un WebView, puede ser. Si no, hay que mantener tanto una API REST para la app móvil como handlers de solicitudes Hotwire/Livewire que entreguen fragmentos HTML.
      Personalmente, creo que una PWA es un problema del cliente y debería resolverse del lado del cliente, sin agregar dependencias del servidor.
    • Me da curiosidad por qué este enfoque sería menos madriguera que las alternativas mencionadas.

  • Acá está la conversación de HN de 2020, más cercana al momento en que esto salió por primera vez: https://news.ycombinator.com/item?id=25507942

  • Se siente como si hubiéramos dado casi toda la vuelta. Recuerdo que por 2005 o 2006 interceptábamos los clics, agregábamos parámetros, recibíamos solo fragmentos parciales de HTML renderizado y reemplazábamos el cuerpo con .innerHTML

    • A principios de los 2000, antes de que apareciera AJAX, Adam Rifkin mostró una demo de su startup KnowNow, y en ese momento era impactante que una página web se actualizara sola sin refrescarse
      El truco era mantener abierta la solicitud HTTP y que el servidor enviara actualizaciones de vez en cuando; esas actualizaciones también eran HTML. En esa época quizá ni siquiera se podía manipular el DOM, así que tal vez literalmente era una página con una etiqueta que nunca se cerraba
    • Más que haber dado la vuelta, sería más preciso decir que distintos paradigmas de UI web están ampliando su alcance
      Los frameworks de renderizado en servidor están facilitando las interacciones del cliente, y React, mediante RSC, está facilitando el renderizado en servidor. Si es una web app con mucha interacción, una SPA sigue teniendo ventaja
    • Cada vez que aparece Hotwire o una biblioteca similar se escucha esto, pero en la práctica el CRUD simple basado en AJAX nunca desapareció
      Aunque hay muchísimos proyectos SPA, eso no describe todos los sitios web del mundo
    • En https://animasci.com/ usan un enfoque parecido
      La paginación se implementó así: al desplazarse hacia abajo y presionar “Show more”, se solicita al servidor la siguiente página como fragmento HTML, se carga en un iframe invisible y, cuando termina de cargar, se adjunta a la página actual
    • A fines de los 2000 me gustaba bastante Wicket y odiaba JavaScript, pero gestionar el estado de la UI y las plantillas en el servidor tendía a convertirse en una trampa de rendimiento y escalabilidad en entornos de equipo
      Considerando cuánto han mejorado la web, JavaScript y TypeScript desde entonces, me cuesta entusiasmarme de nuevo con este enfoque

  • No he trabajado mucho con web apps que necesiten frontends altamente interactivos, pero en tiendas de e-commerce y apps internas en Rails, Turbo y Stimulus redujeron mucho lo que un desarrollador nuevo tenía que aprender

    • Si mantenías el stack simple, en realidad nunca era tan difícil
      Por ejemplo, en un proyecto Django armamos rápidamente toda una herramienta de oficina con el ya probado KnockoutJS, y eso también conecta en cierta medida con el espíritu de HTMX. Arrow.JS, que todavía está en una etapa temprana, es parecido. La complejidad, especialmente la de la UI, por lo general fue autoinfligida; las formas antiguas no están para nada obsoletas y, de hecho, están volviendo. Hay una generación de desarrolladores jóvenes que entró en la industria en la época más tonta, cuando se los convencía de que toda aplicación web tenía que convertirse en un bulto excesivamente complejo e insoportable
    • Habiendo usado Stimulus, Stimulus era pésimo y no lo volvería a usar. Hotwire estaba bien

  • Uso Hey de pago desde su lanzamiento, y si la experiencia de la web app de Hey es el mejor ejemplo de Hotwire, prefiero pasar
    En conexiones lentas es mala. Puede ser porque los desarrolladores no agregaron estados de carga o de error, puede ser por la alta complejidad, o puede ser un bug de Hey. No sé, pero no está bien
    Con latencias medias a altas, el comportamiento se siente impredecible o como si tuviera bugs. Se abren cajas sin contenido, los enlaces no funcionan como se espera, y cuando haces varias acciones rápidamente una tras otra no se interrumpen de manera intuitiva. Simplemente se siente desalineado
    Por más malas que sean las SPA, esto parece un paso en dirección contraria a que la UI se sienta nativa y natural

  • La razón por la que este artículo volvió a aparecer ahora es que la semana pasada alguien publicó que Hey era lento abriendo un modal: https://x.com/noahflk/status/1795758603577545035
    Hey lo hizo DHH, y DHH también creó Hotwire y Rails. Después de eso, se mezclaron la respuesta de DHH diciendo que el video original fue grabado en una red limitada, reacciones de que si cargar un modal tarda entonces Hotwire depende demasiado de la red, defensas de Rails/Hotwire y críticas al enfoque, y se volvió una discusión acalorada. Fue un tema grande en Twitter la semana pasada

    • Es cierto que DHH dijo que el video original fue grabado en una red limitada
      El autor también escribió que “lo hizo lento intencionalmente para la demostración”: https://x.com/noahflk/status/1795855075526471915. Dijo que no quería mostrar la experiencia de alguien con “una buena MacBook e internet gigabit en SF”, sino referirse a alguien con internet móvil lento y una laptop barata. También se señaló que la SPA de Google Calendar es mucho más lenta, y tampoco es que las únicas opciones sean “internet gigabit en SF” y “3G fuertemente limitado”. La publicación original era muy engañosa y, en la práctica, casi una mentira
    • Enlace a la respuesta directa de DHH: https://x.com/dhh/status/1796163806650868149
    • Cuando vi Hey hace aproximadamente un año, también se sentía bastante ágil desde el otro lado del Pacífico
      La estructura de la página era especialmente impresionante. Por ejemplo, aplicaba una combinación de details/summary/anchor a los overlays de menú contextual con mejora progresiva, y aunque se desactivara JavaScript o no cargaran los assets, el contenido del menú se cargaba elegantemente con un layout simple. Recuerdo que también había muchas otras partes donde usaban Web API con cuidado, y que el código del cliente casi no estaba ofuscado y traía source maps. No soy fan de DHH ni pienso seguir el drama de esa semana, pero esta vez sentí que 37signals lo hizo bien
    • Ya lo corrigieron. La actualización se puede ver aquí: https://x.com/dhh/status/1797370923391357143

  • Hace 2 años hice Swap JS, una implementación más minimalista de la misma idea: https://github.com/josephernest/Swap
    Lo probé en algunos proyectos y funciona bien