- htmx fue seleccionado para el primer GitHub Open Source Accelerator, lo que le dará la oportunidad de colaborar con proyectos open source maduros y aprender de ellos
- Esta participación servirá como una oportunidad para dar a conocer hypermedia y el enfoque de htmx a una comunidad de desarrolladores más amplia
- htmx planea aprovechar el periodo del Accelerator para comenzar el trabajo en htmx 2.0
- Para sostener el mantenimiento y el desarrollo del proyecto, aprender cómo convertir el trabajo en htmx en un empleo de tiempo completo sigue siendo una tarea importante
- Los proyectos seleccionados junto con htmx abarcan diversas áreas del open source, como seguridad, documentación, autenticación, notificaciones y CMS, lo que muestra el alcance de GitHub Accelerator
La oportunidad que obtiene htmx
- htmx fue seleccionado para la primera generación de GitHub Open Source Accelerator
- Esta selección le permitirá aprender de desarrolladores y proyectos open source exitosos, y colaborar con ellos
- htmx considera que este proceso puede ayudar a difundir más ampliamente hypermedia y htmx
- Los principales objetivos durante su participación en el Accelerator son dos
- Comenzar el trabajo en htmx 2.0
- Aprender cómo convertir el trabajo en htmx en un empleo de tiempo completo
Proyectos open source seleccionados junto con htmx
- BoxyHQ: suite de API para seguridad y privacidad que ayuda a los equipos de ingeniería a crear y desplegar más rápido aplicaciones cloud que cumplan con las normativas
- Cal.com: herramienta de calendario que ayuda a agendar reuniones sin tener que intercambiar correos una y otra vez
- Crowd.dev: ayuda a centralizar datos de comunidad, producto y clientes para identificar qué empresas participan en proyectos open source
- Documenso: alternativa open source a DocuSign, cuyo objetivo es ganar confianza mediante self-hosting y revisión de su funcionamiento interno
- Erxes: alternativa open source a HubSpot que permite crear experiencias para distintos tipos de negocio mediante un único XOS
- Formbricks: permite enviar encuestas a grupos de usuarios segmentados en cualquier punto del recorrido del usuario, y recopilar hasta 6 veces más insights con microencuestas dirigidas
- Forward Email: servicio gratuito de reenvío de correo para dominios personalizados, usado durante más de 6 años por creadores, desarrolladores y empresas
- GitWonk: herramienta open source de documentación técnica diseñada y construida con foco en la experiencia del desarrollador
- Hanko: herramienta open source de autenticación y gestión de usuarios para la era de las passkeys, integrable en apps web y móviles en minutos
- Infisical: plataforma open source con cifrado de extremo a extremo para gestionar de forma segura secretos y configuraciones en equipos, dispositivos e infraestructura
- Novu: infraestructura open source de notificaciones para desarrolladores, que ofrece componentes y API para gestionar todos los canales de comunicación en un solo lugar
- OpenBB: democratiza la investigación de inversiones mediante un ecosistema financiero open source; con OpenBB Terminal se puede realizar investigación de inversiones desde cualquier lugar
- Sniffnet: herramienta de monitoreo de red que ayuda a rastrear fácilmente el tráfico de internet
- Typebot: ofrece bloques para crear experiencias de chat únicas, que pueden embeberse en cualquier parte de una app para recopilar resultados
- Webiny: CMS serverless open source de nivel empresarial, con énfasis en la propiedad de los datos, la escalabilidad y la personalización
- Webstudio: seleccionado como alternativa open source a Webflow
1 comentarios
Opiniones de Hacker News
Hola, como muchos saben, soy el creador de htmx y puedo responder preguntas relacionadas
htmx ganó mucha popularidad a partir del video de fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) y de una serie de videos del popular streamer de Twitch ThePrimeagen
Si leen HN, quizá también les interese mi colección de textos sobre htmx e hipermedia en general: https://htmx.org/essays, y también vale la pena ver el libro que publiqué recientemente con varios autores sobre hipermedia, htmx e Hyperview, hipermedia móvil: https://hypermedia.systems
Obviamente soy fan de htmx, pero creo que el punto central más profundo es la hipermedia. Aunque no tengan pensado usar htmx en su desarrollo diario, es un concepto que vale la pena explorar
También hay muchas bibliotecas excelentes orientadas a hipermedia, como Hotwire de 37signals o https://unpoly.com, mi favorita después de htmx
Es de gran ayuda para muchos desarrolladores de Django
Hace unos meses, cuando implementé la función de dar “me gusta” a un artículo, antes de htmx tenía que llamar a un servidor de API JSON con jQuery y actualizar el contador de likes, pero con HTMX se sintió como usar HTML común y corriente junto con la lógica de Django
Es de lo mejor que he encontrado hasta ahora, y el manejo de formularios también es muy sencillo. HTMX mejora mucho tanto la experiencia de usuario como la experiencia de desarrollo
Considerando que incluso en proyectos muy populares normalmente los contribuidores existentes se encargan de la mayor parte del código, es una señal fuerte de crecimiento
https://devboard.gitsense.com/bigskysoftware/htmx
Para que conste, esta es una herramienta que hice yo
Al revisar un poco el sitio web y los ejemplos, parece que la respuesta HTTP del servidor contiene el marcado completo y, con base en eso, se actualiza el estado del cliente; es decir, el foco está en reescribir el DOM
Me pregunto si htmx también ofrece concesiones para triggers solo del cliente o contenido generado en el cliente
La ventaja de los frameworks de cliente centrados en JavaScript actuales es que pueden trasladar al navegador la mayor cantidad posible de trabajo, reduciendo el uso de datos y CPU del servidor. En aplicaciones a escala web, eso hace una gran diferencia
Me pregunto si HTMX también puede satisfacer estos objetivos de ingeniería o si es un proyecto con un propósito completamente distinto. Entiendo que clientes como Facebook no están orientados a hipermedia, pero de todos modos la comparación será difícil de evitar
Se siente natural, autoexplicativo y bien diseñado. Realmente se siente como una extensión natural de HTML
Para mí, la única pieza que le falta a htmx es un modelo de componentes; para quienes busquen algo así, parece encajar muy bien con Astro[1]. Astro permite definir y usar componentes HTML sin la carga de runtime de Vue o React
[1] http://astro.build
Htmx me recuerda a Tailwind. Al fin y al cabo, crea nombres y valores de atributos que una sola biblioteca lee en tiempo de ejecución
No necesitar un build de frontend es una ventaja enorme para la mayoría de los desarrolladores que no quieren tocar npm ni webpack, ni tienen por qué hacerlo
El límite de tamaño de página parece similar al de una app pequeña de página única, y si crece demasiado, se podría dividir en otra app de página única
Lo que probablemente extrañen especialmente los desarrolladores de React/Vue es la perspectiva de tener un único objeto que representa el estado global, y una función definida jerárquicamente en la base de código de componentes que lo renderiza como UI
Sin embargo, esa perspectiva en sí también trae mucha carga, genera muchas diferencias de opinión y desgaste emocional, y viene acompañada del build de frontend y sus variantes confusas
Todavía no lo uso, pero ya soy un gran fan
Es una buena noticia.
Durante el último año he usado htmx con buenos resultados y experiencias gratificantes, y fue especialmente excelente al hacer renderizado del lado del servidor con hiccup en Clojure.
Una vez que entiendes htmx, casi sorprende lo simple y flexible que es. Cuesta creer que HTML no haya evolucionado así como hipermedia.
Se vuelve muy claro que el desarrollo web debió haber evolucionado de esta manera. Espero que algún día lo que htmx está haciendo con JavaScript quede integrado tal cual en HTML y en los clientes de navegador.
Si ves erróneamente a htmx como poco más que un derivado de Angular, o no entiendes la importancia de haber avanzado la arquitectura de hipermedia, te recomiendo mucho leer los excelentes artículos del sitio. Entonces entenderás qué es REST y por qué el verdadero HATEOAS importa: https://htmx.org/essays/
También hay un libro gratuito: https://hypermedia.systems/
Hace 10 o 15 años, en vez de ampliar y enriquecer la hipermedia, que era una idea nueva y potente de la web temprana, tomamos un camino equivocado y costoso al intentar reconstruir clientes pesados sobre la web con arquitecturas de API JSON.
Me alegra que htmx exista y que a mucha gente le funcione bien, pero en mi trabajo muchas veces no ha sido la mejor opción. Y eso está bien.
Es genial que la web haya podido crecer de muchas maneras, y no hace falta pensar que necesariamente debió evolucionar en una sola dirección.
El mayor error del desarrollo web en la última década más o menos fue la idea de que tenía que haber una única respuesta correcta.
Ya sea que estés construyendo el próximo Gmail o un blog estático, el cargo cult de la industria dice que todo debe hacerse de la misma manera, pero el sentido común dice que no es así.
Sería suficiente para más del 98% de la web. Para el 1.9% restante, se puede usar una pequeña biblioteca de JavaScript.
Solo el 0.1% que queda son webapps de JavaScript puro.
Parece la misma idea: agregar algunos atributos a HTML para volver dinámicos los casos fáciles.
Angular 1, Vue y muchos otros frameworks empezaron así y, después de ganar cierta popularidad, crecieron hasta convertirse en frameworks completos de aplicaciones de una sola página por la demanda real de casos más difíciles.
Si tuviera que elegir un framework “tipo Angular 1”, escogería uno que documente claramente sus límites y ofrezca una ruta clara para usar un framework maduro de aplicaciones de una sola página cuando haya que cruzar esos límites. Si alguien conoce uno así, compártalo, por favor.
Soy fan de HTMX desde “antes de que se pusiera de moda”
Me alegra mucho la atención y el éxito recientes, y también disfruto bastante las burlas en tono de broma y la resistencia que vienen del lado del frontend, donde creen que la web se inventó en 2013 y que ellos construyeron la ciudad
Ya tenía cierto sesgo desde la época de Backbone.js; en aquel entonces entendía parte del dolor, pero también era bastante escéptico
Luego apareció React y, cuando gente joven y llena de energía empezó a convertir sitios web muy simples de 5 páginas en máquinas de Rube Goldberg de frameworks frontend, cobré mis fichas tecnológicas y no toqué nada de eso
Los detalles de implementación son bastante distintos, pero la idea de una aplicación basada en hipermedia estaba en el centro de todo lo que hacíamos
Lamentablemente, a largo plazo no logró ganarse a la gente, y el desarrollo impulsado por blogs —es decir, el cargo cult— reemplazó nuestros esfuerzos
Ahora que parece que HTMX está ganando popularidad, en cierto modo se siente como una reivindicación. Da gusto ver que no éramos los únicos que pensábamos en estos conceptos
Claro que, si el concepto era sólido, quizá eso signifique que mi ejecución fue deficiente, así que tal vez no debería alegrarme demasiado
También escuché que una banda vendió sus guitarras y compró tornamesas
Escuché que reescribieron un endpoint HTTP para que devolviera JSON, y que eso era REST
También escuché que una banda vendió sus tornamesas y compró guitarras
Escuché que reescribieron un endpoint HTTP para que devolviera fragmentos de HTML con plantillas, y que eso era HATEOAS
Estoy perdiendo el toque, recuperándolo, perdiéndolo y recuperándolo
Eso sí, Backbone era un poco laxo y, hasta que apareció Angular, no se sentía muy empresarial
En cualquier caso, este flujo de aplicaciones web se volvió popular a mi alrededor porque separaba backend y frontend, y un solo backend, normalmente REST/JSON, podía alimentar por separado a clientes móviles y web
Esa fue la razón por la que creamos aplicaciones de una sola página, pero parece que ahora se volvió a olvidar
En mi mundo tenía sentido para apps detrás de un inicio de sesión. Pero “ellos” querían convertir también sitios públicos de internet, como tiendas online, en aplicaciones de una sola página
También lo entiendo. Hice algunos sitios web con Gatsby, y la navegación es increíblemente rápida sin dejar de estar indexada por los motores de búsqueda
Pero en algunos casos se fue volviendo cada vez más complejo, hasta llegar a cosas como React del lado del servidor. Por suerte, no tuve que tocar eso
Por otro lado, espero que htmx, y más en general la hipermedia, se acepten como herramientas. Son útiles, pero al final no dejan de ser herramientas
También me gustaría que así las aceptara la gente de frontend que durante un tiempo no pensó mucho en la hipermedia
No veo los dos enfoques como mutuamente excluyentes, y estoy de acuerdo con el concepto de aplicaciones web transicionales de Rich Harris, es decir, una forma de mezclar ambos enfoques
Solo que yo trazo la línea para abandonar la hipermedia y pasar a un enfoque del lado del cliente más sofisticado en un lugar distinto al de él
Yo definitivamente lo pienso
Empecé en 1996 con Perl y pasé por casi todas las corrientes: PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL y NextJS.
Htmx se siente como una rama que se sale de esa corriente, y vale la pena pensar en ella.
Htmx plantea una buena pregunta: “¿La complejidad de tu trabajo está esencialmente en el servidor o en el cliente?”
En la mayoría de los sitios web, la complejidad está esencialmente en el servidor. La mayoría de nosotros no estamos creando Figma ni Google Sheets. Muchos sitios web, aunque tengan mucha interacción, son solo apps CRUD con una interfaz atractiva.
Frameworks como NextJS intentan corregir los problemas de clientes excesivamente complejos llevando React al servidor, pero muchas veces terminan aumentando la complejidad en vez de reducirla.
Entonces, ¿no sería mejor sacar React del stack? Si tienes un cliente complejo, puedes saltarte el DOM y JavaScript y usar canvas y WebAssembly compilado. Si tienes un servidor complejo, puedes usar actualizaciones finas del DOM dirigidas por el servidor.
El problema que veo con este enfoque es que, aunque la complejidad de la mayoría de los sitios web esté en el servidor, casi siempre hay algunas tareas de alta complejidad que deben estar en el cliente: edición de imágenes, ordenamiento, filtrado y cálculos en tiempo real, gestos de arrastrar y táctiles, etc.
Se necesita un enfoque híbrido. No basta con que sean compatibles. Se puede usar htmx y React en la misma página web, pero hay que aislarlos entre sí. Lo que quiero no es aislamiento, sino una integración fundamental.
El framework ideal debería soportar actualizaciones reactivas y finas del DOM, y a la vez integrarse estrechamente con WebAssembly compilado encargado de las tareas complejas del cliente.
Quiero escribir todo el código en un lenguaje potente que no sea JavaScript. El depurador debería manejar tanto servidor como cliente, y la diferencia entre ambos debería desaparecer. Debería ser desarrollo full-stack real, es decir, una aplicación de stack único.
Clojure + ClojureScript parece acercarse a una aplicación de stack único, pero solo de forma superficial.
Si apareciera un killer framework para Common Lisp, creo que encajaría perfecto con una aplicación de stack único.
El enfoque híbrido es el enfoque de islas que propone Astro: https://docs.astro.build/en/concepts/islands/
Este enfoque encaja bien con htmx y sus amigos, y en nuestros proyectos con htmx estamos usando JavaScript vanilla simple en las partes que necesitan interacción.
Para proyectos pequeños y medianos, y equipos pequeños, esto puede ser suficiente. Es realmente refrescante poder abrir las herramientas de desarrollo, apuntar a una parte de la página y entenderla completa viendo solo el HTML y un pequeño fragmento de JS.
Ya sea en el servidor o en el cliente, programas de la misma manera en C#. En la primera carga de la página, todo se renderiza del lado del servidor; después, WebAssembly va tomando el control gradualmente y empieza a cargar código C# en el cliente para hacer rápidas las interacciones de UI que no necesitan datos del servidor.
Funciona bien, pero el reto actual es reducir el tamaño de los archivos WebAssembly. Ahora están en el rango de varios MB.
https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
Felicitaciones. Fue divertido hacer un proyecto pequeño con Htmx, pero al final terminé usando mucho openlayers y elegí otra cosa.
Las bibliotecas de mapas son conocidas por ser pesadas en JavaScript del lado del cliente, y para ese trabajo Svelte fue una mejor herramienta.
Planeo volver a usarlo en proyectos con Golang en el futuro y seguir de cerca su evolución.
Si tu app necesita un frontend simple o de complejidad media, especialmente si ya estás usando fragmentos de plantillas[0], recomiendo mucho probar HTMX. Incluso viniendo del mundo de JavaScript, se trabaja con bastante gusto.
Y la persona que maneja la cuenta de Twitter[1] es realmente graciosa.
[0] https://htmx.org/essays/template-fragments/
[1] https://twitter.com/htmx_org
Es difícil tomar a htmx en serio como herramienta para construir apps web o sitios modernos. Siento que vuelve imposible crear funciones que los usuarios ya esperan
Por ejemplo, búsqueda facetada, donde se filtra por fechas anteriores, entre dos fechas o posteriores, pero solo se muestran los filtros cuando el usuario quiere; o funciones para cambiar la pantalla de resultados a otras columnas, a un mapa o a una vista dibujada en un canvas como un gráfico
Seguramente algunas de esas cosas se pueden hacer con htmx, pero en algún momento terminarás necesitando JSON
Angular también puede hacer estas cosas y, si usas algo como SolidJS, en realidad puede ser bastante agradable construirlas
Una API JSON se puede reutilizar en otras apps, pero htmx se siente como si alguien hubiera reinventado Thymeleaf
Yo pensaba lo mismo, pero en el video tratan concretamente cómo implementaron búsqueda facetada con htmx
La segunda parte probablemente terminarás resolviéndola escribiendo JavaScript directamente o con hyperscript
Habría que construirlo de verdad y usarlo intensivamente para saber si es una buena forma, pero sin duda se me ocurren escenarios donde encaja bien
El punto sobre una API JSON es válido. Si necesitas una API pública, eso debe reflejarse en la decisión. Pero no todos los proyectos tienen esa restricción
Incluso un smartphone no tiene ningún problema para buscar en una tabla de mil filas
En esos casos, con htmx le daría al usuario un rango amplio de datos y luego permitiría con JS un filtrado en tiempo real más detallado
Si quieres que también se puedan buscar datos que no se muestran inicialmente, puedes enviarlos junto con una clase CSS oculta y luego quitar esa clase cuando coincidan con la búsqueda
htmx, como cualquier otra tecnología, encaja muy bien con ciertos conjuntos de problemas. Está bien siempre que no lo obligues a hacer trucos para los que no es bueno
Estas cosas son lo bastante complejas como para requerir cierto grado de scripting completo, y no estoy en contra de eso en sí mismo
https://htmx.org/essays/hypermedia-friendly-scripting/
Por los giros de mi carrera, casi me salté las guerras de frameworks JavaScript de frontend, así que me alegra ver que el viejo y simple HTML vuelve fortalecido
Eso es un retroceso en términos de degradación progresiva
Creo que hacen falta casos impresionantes hechos con htmx. Sería bueno tener ejemplos de “made with htmx” que abran camino a un nuevo tipo de experiencia web
La gente encasilló a htmx como algo para casos de uso simples, no como para sacar el “armamento serio”
Hay algo de cierto en eso, pero es una visión limitada. El enfoque de volver al servidor relacionado con htmx es una categoría aparte que, por varias razones, no se exploró antes
HTMX revive una categoría antigua de apps de una forma que no depende del backend
No hace nada nuevo ni que justifique hablar de una “nueva categoría de apps”
Es una forma de construir hipermedia —sitios centrados en contenido— como catálogos de compras, foros, frontends de administración o blogs
Es parecido a jquery/liveview/turbolinks, pero independiente del backend y sin tener que mantener mucha lógica JS de frontend, o incluso ninguna
Cuando necesitas interacciones pesadas como Google Docs o Figma, los beneficios que ofrece htmx se reducen mucho
https://htmx.org/essays/a-real-world-react-to-htmx-port/
Es un frontend de comercio electrónico escrito con HTMX y Hyperscript
https://www.makaron.cz/
Podrías hacer un frontend TodoMVC con HTMX, pero ¿qué usarías en el backend? Go, C#, Rust y algunas otras opciones parecen naturales, pero siempre depende del caso
Menciono C# porque ASP.Net MVC + Razor parece encajar de forma muy limpia con el paradigma de HTMX
No tengo ninguna relación con ellos, pero está hecho con htmx y algo de JS para funciones más complejas
Considerando que htmx tiene explícitamente el objetivo de extender un buen enfoque antiguo, no estoy seguro de que pueda ofrecer un “nuevo tipo de experiencia web”
Al principio htmx se ve bien, pero si intentas hacer algo para lo que normalmente usarías JavaScript, ya sea vanilla o con un framework, como un botón desplegable, al final terminas evaluando hyperscript
Luego ves los ejemplos y no te gusta cómo se ven esas cosas parecidas a oraciones dentro del código, así que pasas a otra cosa
Quizá habría que probar htmx sin hyperscript, o quizá habría que darle más tiempo a hyperscript
Pero si pienso en algo que voy a mantener durante varios años, se siente demasiado extraño, y no quiero quedar atado a eso si después nunca vuelvo a usarlo
A htmx no le importa en absoluto qué herramienta uses para las interacciones del lado del cliente, así que es un tema aparte de si htmx es útil
Personalmente, si quisiera evitar herramientas de build de JS y similares, elegiría htmx + Alpine.js
¿Cómo se podría manejar cuando crezca y se vuelva complejo?
Ayudé en una aplicación que usaba htmx y había dos problemas. Me pregunto si alguien tuvo una experiencia similar, si eran problemas causados por usar mal la tecnología, o si hay trabajo en curso para resolverlos
Primero, se necesitaba mucho middleware personalizado en los controladores para decidir si un endpoint debía devolver el HTML de la página completa o solo el fragmento que necesitaba htmx
Del lado de htmx parece simple, pero probablemente sea una parte que todos los proyectos que usan htmx tienen que volver a crear
Segundo, hacía falta llevar la contabilidad alrededor de
hx-trigger. Cuando la UI se vuelve compleja, muchos elementos deben reaccionar a cambios externosEn vez de leer algún estado y esperar que el framework programe la actualización, había que gestionar manualmente la lista de eventos a los que reaccionar
¿Alguien más lo sintió de manera similar?