Presentación en HN: HTMX Playground implementado 100% en el navegador
(lassebomh.github.io)- Es un sandbox de código que permite empezar a experimentar con HTMX dentro del navegador sin instalación ni configuración local
- En
server.jsse manejan los endpoints y el renderizado de plantillas, y las solicitudes de HTMX son interceptadas por un servidor simulado dentro del navegador - El procesamiento de solicitudes y el enfoque de plantillas resultan familiares para usuarios de Django, y también puede usarse para experimentar con librerías distintas de HTMX
- Para compartir, se exporta con “Copy as JSON” y luego se ingresa la URL raw de Gist en “Load Playground”
- Hay que tener en cuenta la ausencia de navegación entre páginas, el soporte móvil limitado y la posible pérdida de actualizaciones de estado en
on.get("/")debido a la carga inicial del iframe
Un sandbox de HTMX que se ejecuta dentro del navegador
- HTMX Playground es un sandbox de código simple para experimentar con HTMX sin instalar nada
- Ofrece ejemplos adaptados de los ejemplos originales de htmx.org
- Permite escribir código dentro del navegador con un flujo similar al de un backend
- Define endpoints dentro de
server.js - Permite renderizar plantillas directamente
- Funciona un servidor simulado que intercepta las solicitudes salientes de HTMX
- Define endpoints dentro de
- El procesamiento de solicitudes y el motor de plantillas tienen una forma familiar para usuarios de Django
- El proyecto en sí no se limita a HTMX, por lo que también se pueden probar otras librerías
- El código está publicado en GitHub
Forma de guardar y compartir, y limitaciones conocidas
-
Guardado y compartido
- Presiona “Copy as JSON” en la esquina superior derecha para copiar el contenido
- Sube el contenido copiado a Gist
- Ingresa la URL raw en “Load Playground”
- Cuando se actualice la URL de la página, ya se puede compartir
-
Limitaciones
- No hay navegación entre páginas
- El soporte móvil es limitado
server.jspuede tener estado, como en el ejemplo Click to Edit- Si se actualiza el estado en la vista
on.get("/"), esa actualización puede desaparecer- Esto se debe a que la carga inicial de la página se obtiene primero en un iframe separado antes de actualizar el iframe de la pantalla
-
Librerías utilizadas
- Svelte
- Ace
- PollyJS
- Nunjucks
1 comentarios
Comentarios de Hacker News
Soy la persona que creó htmx, y siento que esto es realmente genial; muchas gracias por hacerlo.
En una página existente, si se completa y envía un formulario, la respuesta llega como una página completa; si se pudiera decirle a htmx: “vuelve una página completa, pero actualiza solo #my-form”, no habría que agregar una rama en el servidor del tipo “si es una solicitud htmx”.
Sería bueno para quienes quieren que el sitio funcione incluso sin JavaScript, y también permitiría manejar varias funciones, como comentarios, suscripciones por correo y botones de “me gusta”, con un solo endpoint de backend.
Pensé en probar HTMX en serio, pero me preocupa que el pool de desarrolladores sea demasiado chico y que contratar sea difícil.
Estaba acostumbrado a frameworks propietarios similares a Thymeleaf, como isml de Intershop, y últimamente quería pasarme a un stack frontend con Angular porque es más fácil contratar desarrolladores frontend dedicados.
Un enfoque como htmx puede volverse complejo, los desarrolladores no quieren pelearse con un monstruo de espagueti, y si el frontend solo produce HTML y el backend tiene que unirlo todo, los desarrolladores backend pueden convertirse en un cuello de botella.
Me pregunto si HTMX tuvo en cuenta estas trampas y cómo las aborda.
Dicho eso, HTMX no resuelve todas las situaciones, y a veces hace falta una app de una sola página que use un framework de JavaScript.
Frameworks como Angular dan estructura, pero la complejidad sigue ahí, y probablemente pueda ser mucho mayor.
Al final, lo que se necesita es un desarrollador frontend que conozca bien el stack web, como JavaScript, CSS, HTML y las API del navegador; alguien así puede elegir las herramientas y frameworks adecuados para el trabajo, y aprende algo como HTMX rápidamente.
https://risingstars.js.org/2023/en#section-framework
Está justo detrás de React y por encima de Vue, Svelte y Angular, así que en ese sentido el futuro se ve bien. Dicho eso, espero que baje en el ranking cuando se calme el entusiasmo inicial.
htmx es bastante simple, así que la mayoría de los desarrolladores web pueden aprenderlo en más o menos un día, pero como su forma de desarrollo empuja a la organización hacia un paradigma full-stack en el que el desarrollador se hace cargo de toda la funcionalidad, requiere un cambio de mentalidad no solo de los desarrolladores, sino también de PMs y arquitectos.
También hay un libro gratuito en línea: https://hypermedia.systems
Además de la documentación (https://htmx.org/docs, que toma alrededor de una hora leer), hay artículos que tratan cuestiones filosóficas y prácticas sobre htmx y la hipermedia en general: https://htmx.org/essays
htmx tiene muy pocas ideas base, y se intenta que sea “extensible”, al punto de que comportamientos útiles como la carga diferida pueden implementarse con dos atributos: https://htmx.org/examples/lazy-load
Al mismo tiempo, también tiene hooks y funciones más profundas, como eventos y filtros de eventos, así que si uno profundiza puede implementar el comportamiento que quiera.
El código espagueti es un riesgo siempre presente en todo desarrollo de software, y personalmente nunca me convenció la idea de que las bibliotecas para apps de una sola página lo eviten.
Con htmx conviene concentrar el esfuerzo en el backend y descomponer bien la aplicación usando las herramientas que ofrece el entorno del lado del servidor.
Como htmx permite elegir cualquier tecnología de servidor, ofrece más opciones y paradigmas para organizar la lógica de la aplicación que una app de una sola página, donde ya hay una gran aplicación JavaScript/TypeScript en el frontend que termina empujando el backend hacia ese lado.
También intenté resumir aquí para qué tipo de aplicaciones htmx es una buena opción: https://htmx.org/essays/when-to-use-hypermedia/
htmx es una buena herramienta en muchos casos, pero no deja de ser una herramienta, no una solución universal para el desarrollo web.
Es como contratar a un desarrollador backend que pueda hacer algo de frontend, así que no hace falta que HTMX aparezca en el currículum; basta con fundamentos como JavaScript.
La mayoría de los desarrolladores web cumple con esa condición.
He estado usando MapLibre junto con Django y htmx, y debería subir un ejemplo para poder compartirlo con otros.
Nadie lo usa, pero igual me gustaría ver ese proyecto.
Tengo entendido que Monaco, por diseño, no funciona en móviles, por eso en móviles se usa Ace.
Al menos así era la última vez que revisé el issue de GitHub.
[0] https://github.com/Microsoft/monaco-editor/issues/246
¿Esto también soporta ActiveX?
Recuerdo que en las primeras versiones toda la UI era ActiveX y se veían un montón de barras de progreso instalando DLL
También se podría crear algo así usando un Service Worker y permitir navegar abriendo varias páginas en otras pestañas
No parece que vaya a ser tan difícil, y para generar las páginas se podría usar JavaScript puro o lo que el usuario quiera
Si está hecho con Svelte, ¿dónde quedaron los puristas de MPA y sus horcas?
Me gusta el concepto de htmx y hoy empecé a leer el libro, pero cada vez que pienso que algún día también tendría que soportar apps móviles nativas, me hace dudar en usarlo
En ese caso siento que tendría que reescribir no solo el frontend, sino también buena parte del backend
Conozco hyperview.org, pero para los casos de uso que me interesan una app de React Native no alcanza
Basta con mantener la lógica de dominio fuera de los controladores
Me pregunto si hay gente creando apps offline con un servidor virtual definido dentro de un Service Worker y un esquema de solicitudes-respuestas HTML/HTMX
Me gusta htmx, pero no pude usarlo en situaciones donde también tenía que funcionar offline
Si se pudiera ejecutar el código del servidor tal cual dentro de un worker, sería un hack excelente
En teoría, puede ser cualquier stack de servidor que se pueda autohospedar
El objetivo es crear un binario único sin dependencias de servicios externos, y estoy usando Go
Ya hay muchos componentes listos, como un servicio local con autoactualización y una base de datos replicada, y además es fácil hacer compilación cruzada para varios sistemas operativos y arquitecturas
Como alternativa a meter todo en el navegador, este enfoque parece bastante razonable si se asume que se puede ejecutar un proceso aparte
Eso sí, me gustaría que Go tuviera una gestión de permisos como la de Deno
Uso este patrón en todas mis apps personales, aunque uso una pequeña biblioteca propia parecida a htmx
No creo que cambiarlo a HTMX sea tan difícil
Me pregunto si sería buena idea llevar HATEOAS al lado de las apps de escritorio o móviles, y podría ser un experimento interesante
Funciona bien, pero no es tan flexible como la web, y hay que desarrollar cada pantalla enlazable como una caja negra estricta
El intento en sí fue interesante, pero no estoy seguro de cuánto valor tenga usarlo en producción
REST fue bienvenido porque simplificó los monstruos de SOAP, pero también vino con bastante dogmatismo
Entiendo el propósito fundamental de REST, porque alinea la arquitectura de conceptos, datos y servicios de una forma natural para el usuario
Pero HATEOAS me pareció más bien el resultado de querer más dogmatismo y postureo en reuniones de arquitectura, en lugar de enfocarse en si la experiencia de usuario mejora gracias al modelo
Me pregunto si existe algún ejemplo de UI que muestre por qué HATEOAS debería tomarse como principio base
Básicamente, cada página tiene enlaces a “lo siguiente por hacer”, y HATEOAS se siente como una forma llamativa de llevar ese modelo de estado a las llamadas de servicios REST