HTMX: Enhancing Web Development

Muy bien, voy a dar una charla llamada No en serio, HTMX es Pro JavaScript. Por alguna razón, siento que la gente no me toma en serio. No sé cuál es la situación.

Así que sobre mí, mi nombre es Carson Gross. Trabajo en un montón de diferentes proyectos de código abierto. HTMX es probablemente el que has oído. También trabajo en algo llamado HyperScript, que es un lenguaje de scripting para la web. Idiomorph, que es un algoritmo de morphing, de hecho 37signals lo está usando en Rails ahora. Escribí un ensayo tonto sobre desarrollo de software llamado Grugbrain que puedes leer en grugbrain.dev. Y tengo un libro que puedes comprar si quieres o leer en línea gratis en hypermedia.systems.

Y hoy de lo que voy a hablar es de HTMX, obviamente, para eso estás aquí. Y voy a dar algunas demostraciones de HTMX. Y vamos a hablar un poco sobre la relación entre HTMX y JavaScript porque es un poco más incómoda que la relación entre, digamos, React y JavaScript.

Entonces, HTMX, ¿qué es? Bueno, es algo que llamo una biblioteca de front-end orientada a hipermedia. Y lo que eso significa es que mejora HTML como hipermedia en términos de hipermedia. Y eso es diferente estilísticamente a la mayoría de los frameworks o bibliotecas que la gente aquí estaría acostumbrada donde esos frameworks tienden a inclinarse hacia JavaScript. Así que simplemente toma una mirada diferente a las cosas desde, ya sabes, aborda el desarrollo web desde una perspectiva diferente. Y se basa en esta idea de lo que se llaman controles de hipermedia en HTML.

Y este es un concepto que no quiero decir que ha caído en tiempos difíciles pero no es tan interesante, no ha estado en la mente de los desarrolladores web por un tiempo desde que el enfoque estándar se ha convertido en aplicaciones de una sola página. Pero probablemente todos saben lo que es un control de hipermedia, incluso si nunca han pensado en el término antes porque el control de hipermedia canónico es un hipervínculo. En HTML esto se implementa como una etiqueta de anclaje. Así que aquí tenemos una etiqueta de anclaje en la pantalla frente a nosotros, una muy simple. Y esto permite lo que se llama enlace no lineal. Así que cuando se creó la hipermedia, se contrastó con los medios antiguos. Así que papel y PDFs y cosas así. Y lo que era único sobre la hipermedia es que podías saltar, podías elegir lo que querías hacer. Y esto, ya sabes, el hipervínculo obviamente es la mecánica de navegación fundamental de la World Wide Web. Hay otro control de hipermedia llamado el formulario. Y los formularios son más complicados. Puede que los hayas usado en tus aplicaciones.

Y estos permiten a las personas expresar interacciones más sofisticadas con un servidor remoto. Así que actualizaciones y búsquedas y demás. Pero se da más control al autor con los formularios. Así que si quieres entender HTMX, creo que lo mejor que puedes hacer es mirar un, mirar de cerca un hipervínculo o una etiqueta de anclaje. Y si miras esta etiqueta de anclaje, de nuevo, un control de hipermedia muy simple, enlace muy simple. Lo que le está diciendo al navegador o al cliente de hipermedia es renderizar algún texto. Y luego, cuando un usuario hace clic en ese texto, quiero que emitas un get a un servidor remoto y luego reemplaces el contenido de toda la ventana de visualización con cualquier documento HTML que regrese. Lo que hace HTMX es que en realidad, simplemente, generaliza esa idea. Así que hay cuatro componentes en esa idea. Y esos cuatro componentes son el disparador, el elemento que está emitiendo la solicitud de la cosa que en realidad es un control de hipermedia, el verbo o acción que se está utilizando para hacer esa solicitud, y luego dónde y cómo se está colocando el contenido en el DOM. Y así, HTMX, el objetivo de HTMX es generalizar todas esas cosas basadas en este concepto central de controles de hipermedia ya presentes en HTML.

Así que así es como lo hacemos. Aquí hay un ejemplo de un botón de me gusta potenciado por HTMX. No es un gran botón, pero es mi botón de me gusta. Así que la forma en que funciona este botón de me gusta es que puedes ver que hemos puesto algunos atributos en él. Y esos atributos todos comienzan con HX. Ese es el prefijo que usa HTMX. Así que lo que esto está diciendo, el primer atributo es HX put, y luego hay una URL relativa después de él. Y lo que eso está diciendo es que cuando se interactúa con este elemento, quiero que hagas una solicitud a un servidor remoto, y este es el tipo de solicitud que quiero que hagas. Y así, hay un conjunto de atributos que todos corresponden a los varios verbos HTTP. Así que tenemos post, patch, delete, y demás. Y eso hace posible que cualquier elemento en un documento HTML se convierta en un control de hipermedia, y también puedes emitir cualquier tipo de solicitud, lo cual contrasta con los anclajes y formularios básicos en HTML donde realmente solo puedes emitir gets y posts, desafortunadamente. El siguiente atributo en él es HX trigger, y esto generaliza esa noción de qué evento impulsa la solicitud. Así que en lugar de solo clics o en el caso de envíos de formularios, ¿por qué no permitir que cualquier evento pueda desencadenar solicitudes? Y finalmente hay un atributo HX target, y puedes ver que toma un selector CSS. Está dirigiéndose a este elemento de salida. Lo creas o no, output es una etiqueta HTML legal que tiene el ID output. Y así, este HX target nos permite dirigirnos a cualquier elemento en el DOM en lugar de solo reemplazar toda la ventana de visualización. Así que el término técnico para esto, a veces voy a conferencias académicas, se llama transclusión. Así que esto generaliza la transclusión con HTMX.

Y así, con estos atributos, HTMX realmente toma este concepto de controles de hipermedia, lo generaliza, lo hace disponible en cualquier parte de tu documento respondiendo a cualquier evento. También hay algunos otros atributos prácticos en HTML. Así que HX swap que te permite cambiar exactamente cómo se intercambia el contenido. HX indicator que se usa para mostrar un indicador cuando una solicitud está en curso para que el usuario sepa que algo está sucediendo. Y en total tenemos un total de, diría, tal vez una docena de atributos. Creo que en total hay un poco más de 20. Realmente, la mayoría de las personas que trabajan con HTMX suelen usar como 5 o 6 atributos y tal vez un total de 12 que podrías llamar el núcleo. Puedes ir a htmx.org slash reference para ver cuál es el núcleo de la API.

Y eso es genial. Así que idea nerd, controles de hipermedia, controles de hipermedia generalizados. Pero al final del día somos desarrolladores prácticos, queremos hacer las cosas. Entonces, ¿qué podemos lograr con esta generalización? Bueno, creo que la mejor manera de mostrarle a la gente lo que puedes lograr con esto es con demos. Y mi demo favorita se llama active search. Así que todos hemos ido a Google y comenzado a escribir un término de búsqueda y hemos visto los resultados aparecer mientras escribimos. Y eso, olvido exactamente cómo lo llama Google. Pero yo lo llamo active search. Así que mientras escribes, las cosas aparecen. Y quiero cambiar rápidamente a otra pestaña. Y puedes ver todos los ejemplos que tengo para HTMX en htmx.org slash examples.

Pero te voy a mostrar active search. Y lo que tenemos aquí es un input, así que solo un input de búsqueda estándar. Y vamos a hacer un post a search. Y el disparador es probablemente el aspecto más interesante de esta demo. Así que lo vamos a activar en el evento de búsqueda. No te preocupes por eso. Eso es básicamente lo que sucede cuando alguien – los inputs de búsqueda a menudo muestran una pequeña X que puedes hacer clic para borrar el término de búsqueda. Pero más importante en el evento de input, y eso se activará cada vez que alguien cambie el input. Y vamos a – después del indicador de input para el evento, le vamos a dar dos modificadores.

El primero es changed, lo que significa que el valor de este input debe haber cambiado para que realmente emitamos una solicitud. Y finalmente, delay colon 500 milliseconds, y este es el importante. Entonces, lo que hace esto es que realmente desbalancea la solicitud, porque no quieres saturar el servidor mientras escribes, ya sabes. Cada vez que alguien escribe, no quieres emitir una solicitud. Y entonces lo que dice esto es, está bien, espera 500 milisegundos, y si otro evento, otro evento de cambio no ha llegado, entonces emite la solicitud.

Y verás que cuando vas a Google mientras escribes, hay un pequeño retraso. Y eso se llama desbalanceo. Así que htmx tiene esto para proporcionar ese tipo de funcionalidad. Y finalmente, vamos a apuntar a los resultados de búsqueda, que es solo el cuerpo de esta tabla de resultados aquí abajo. Y lo que quiero hacer es bajar aquí, y hay realmente una demo. Y voy a presionar A, y puedes ver que hay una especie de depurador – un truco total, es horrible, no mires el código, pero muestra las solicitudes que se están haciendo.

Y así escribí A en este input, y obtuvimos de vuelta algo de HTML. Y htmx, dado que está orientado a hipermedia, obtiene de vuelta el HTML. Puedes ver un poco el contenido que obtuvo de esa solicitud allí. Y luego simplemente lo inserta en el DOM donde le dijimos. Y eso es todo. Eso es realmente todo lo que hace. Pero al mismo tiempo, puedes ver, mientras escribo aquí, se está filtrando. Está haciendo estas solicitudes. Y puedes ver que pude escribir E y luego S, y hubo un retraso porque no – después de que escribí la E, se activó un evento, pero esperó 500 milisegundos. Escribí S antes de eso, y entonces esperó. Luego escribí S, pausó por un segundo, obtuvo los resultados de vuelta. Y así puedes ver que estamos trabajando con el servidor en términos de HTML, algo así como la forma antigua de HTML, pero lo estamos haciendo a un nivel más sofisticado de lo que haríamos si solo tuviéramos una barra de búsqueda y presionaras enviar. Así que una cosa que notarás es, por ejemplo, el estado de desplazamiento no se reinicia y todo eso. Todas las cosas malas sobre las antiguas aplicaciones web han desaparecido hasta cierto punto aquí.

Así que podemos trabajar con esto y podemos trabajar con HTML en lo que creo que son términos de HTML y términos de hipermedia de todos modos, pero lograr una mejor experiencia de usuario. Así que ese es nuestro ejemplo de búsqueda activa. Creo que es un buen ejemplo porque realmente muestra cuán dinámico puede ser el comportamiento, incluso con el modelo de hipermedia, incluso usando hipermedia como nuestro mecanismo para nuestra programación estándar. Así que al generalizar la hipermedia, podemos hacer más con HTML.

Lo que notarás si miras este ejemplo es que como desarrollador de JavaScript podrías decir, ¿dónde está el JavaScript? Y la respuesta es que no hay ninguno, o al menos no hay ninguno que el usuario esté escribiendo. Así que HTMX está escrito en JavaScript, pero el usuario mismo, no escribe una tonelada de JavaScript para lograr esta interfaz de usuario. Usan unos pocos atributos en su lugar. ¿De acuerdo? Ahora podemos construir algunas aplicaciones web, no todas, y tengo un ensayo sobre lo que creo que es bueno para hipermedia en el sitio web de HTMX. Ciertamente podemos construir muchas aplicaciones sin una tonelada de JavaScript. Creo que desafortunadamente, y es solo la forma en que es el mundo, debido a eso, HTMX a menudo se ve como anti-JavaScript. Y creo que eso es cierto hasta cierto punto en que HTMX definitivamente atrae a personas que no les gusta JavaScript porque ahora pueden participar en el desarrollo web moderno, al menos pueden lograr algo como una búsqueda activa, o veremos algunos otros ejemplos más adelante, o puedes ver algunos otros ejemplos en la página de ejemplos en HTMX. Pueden lograr esas interfaces de usuario sin necesidad de escribir mucho JavaScript. Y veo esto mucho en línea. Ahora tengo que admitir que la forma en que actúo en Twitter, tengo suerte de que a alguien le guste, pero ciertamente hay una actitud y un subconjunto de desarrolladores de HTMX que es anti-JavaScript. Ahora no creo que eso sea totalmente justo. Entiendo de dónde viene. Pero por supuesto HTMX en sí está escrito en JavaScript. De hecho, es solo una gran bola de JavaScript si alguna vez has visto el... Si alguna vez has ido al repositorio de GitHub, puedes ver que es un único archivo JS gigante porque así es como quería codificarlo. Así que creo que a algún nivel es imposible que HTMX sea anti-JavaScript porque es JavaScript. Pero creo que a un nivel más profundo se podría argumentar que HTMX es en realidad muy pro-JavaScript. Esto es... Aguanta... Quédate conmigo aquí. Pero el argumento que voy a hacer es que HTMX se centra en mejorar HTML que expande la clase de problemas que HTML puede abordar en términos de hipermedia. Y sí, eso reduce la cantidad de cosas que necesitan ser abordadas usando algo como JavaScript. Pero creo que eso es realmente bueno en que permite que JavaScript se use para lo que fue originalmente diseñado, un lenguaje de scripting ligero para la web. Y así la forma en que HTMX y JavaScript interactúan puede ser muy beneficiosa mutuamente. Puede realmente reducir las responsabilidades de JavaScript en tu aplicación web y permitir que sea un componente de mayor valor de tu sitio web. Así que en términos relativos, al menos por línea de código, JavaScript puede aumentar dramáticamente en valor. Así que veamos otra demo para mostrar esto. Este es un ejemplo usando SortableJS. Y así lo que SortableJS, si nunca lo has visto antes, permite un comportamiento de arrastrar y soltar realmente agradable en HTML. Es una biblioteca de JavaScript.

Lo añades, ya sabes, lo añades y lo conectas a tu DOM y puedes hacer que las cosas soporten arrastrar y soltar. Y así este es el JavaScript que es necesario para hacer eso.

Así que HTMX tiene una función onload que se ejecutará cada vez que se ponga nuevo contenido en el DOM. Pasará el contenido en el callback. Y así lo que esto está haciendo es simplemente buscar cualquier cosa con una clase sortable en ella y luego inicializar esta instancia sortable en ella.

Y así si miramos aquí abajo, tenemos un formulario que tiene esa clase sortable en él. Así que estamos añadiendo este comportamiento habilitado por JavaScript al formulario y tiene un montón de divs dentro de él con algunas entradas ocultas. Y lo que esto va a permitir es que los usuarios puedan arrastrar y soltar, reordenar estos elementos usando la funcionalidad de SortableJS. Una de las cosas que hace SortableJS es que cuando se completa un arrastre, en realidad dispara un evento de finalización. Y eso es genial porque ahora HTMX puede integrarse con SortableJS escuchando ese evento. Cuando ocurre un evento de finalización, es disparado por SortableJS, va a emitir un post a slash item. Así que va a decirle al servidor, oye, esto ha sido actualizado.

Y así si bajamos aquí, voy a agarrar el ítem uno y arrastrarlo aquí abajo. Y puedes ver que esa es la funcionalidad que SortableJS está proporcionando, una experiencia de arrastrar y soltar realmente agradable. Y cuando lo suelto, puedes ver que se hizo una solicitud. Y configuramos las entradas ocultas con ese formulario, de esa solicitud de formulario al servidor. Y el servidor puede reordenar esos elementos y luego volver a renderizar toda la lista.

Y así este es, creo, un gran ejemplo, un gran ejemplo dinámico donde mientras interactuamos con esta lista, mientras arrastramos y soltamos cosas, podemos integrar HTMX con SortableJS y persistir esto, el reordenamiento que el usuario ha solicitado al servidor. Así que ese es un ejemplo donde HTMX ha trabajado en conjunto con JavaScript. Así que HTMX no podría lograr esta experiencia de usuario por sí solo, al menos no bien. Si recuerdas, no sé qué tan viejas son las personas aquí, pero solías tener botones de subir y bajar para reordenar cosas en la web, y hacía una solicitud completa horrible.

Y así, obviamente, esta es una experiencia mucho más agradable. Y creo que muestra cómo estas dos tecnologías, JavaScript y HTMX, son complementarias entre sí. Y complementarias como tecnologías. Esto es, nuevamente, algo que HTMX no podría lograr por sí solo. Y así tenemos una biblioteca de JavaScript que está extendiendo y mejorando la experiencia del usuario, lo cual está exactamente en línea con el objetivo original del scripting en la arquitectura web.

Así que Roy Fielding es un ingeniero que trabajó en muchas de las tecnologías tempranas de la web. Y escribió una disertación bastante famosa en la que definió el término REST. Y así esa disertación se convirtió en la forma en que muchos de nosotros, especialmente los desarrolladores web más antiguos, pensamos y hablamos sobre la web. Y mencionó explícitamente el scripting en ese documento. Bien. Vamos a tener, para ser REST, es una restricción opcional, sin entrar demasiado en el lenguaje académico, pero se llama código bajo demanda, o lo que probablemente llamaríamos scripting hoy. Y esto es lo que tenía que decir sobre el scripting. Así que REST permite que la funcionalidad del cliente se extienda descargando y ejecutando código en forma de applets o scripts. Esto simplifica los clientes al reducir el número de características que deben preimplementarse.

Y aquí cuando dice clientes, se refiere a los navegadores. Habrá cosas que los navegadores no pueden hacer que el scripting les permitirá hacer. De eso está hablando allí. Permitir que las características se descarguen después del despliegue mejora la extensibilidad del sistema. Y así el sistema del que está hablando allí es la web. Así que la web es un sistema RESTful y tiene scripting, y eso nos permite hacer cosas interesantes con la web que la web misma no fue diseñada para hacer, porque tenemos esta capacidad de scripting.

Y realmente la clave, creo, para integrar entre el mundo del scripting y el mundo hipermedia es esta noción de eventos. Así que los eventos nos permiten conectar limpiamente estos dos mundos, porque podemos tener una biblioteca de JavaScript como SortableJS. Hace algunas cosas locas con el DOM, hace que todo se vea súper genial, comportamiento de arrastrar y soltar que es increíble, desliza cosas, hace todas las animaciones. Pero al final del día, cuando las cosas se asientan y queremos persistir eso en la web, decimos, está bien, disparas un evento, me dices, y luego voy a interactuar con la web de la manera tradicional orientada a hipermedia, y así es como HTMX puede integrarse tan bien con SortableJS. Así que con estos eventos, estas dos tecnologías pueden trabajar en conjunto, y además, si haces eso, entonces HTMX puede liberar a JavaScript de tener que hacer todo para tu aplicación web. Así que HTMX puede encargarse de persistir el estado. Puedes tener solo una especie de fuente de registro, o sistema de verdad para donde está el estado en el servidor. Y cuando haces eso, eso puede simplificar enormemente tus aplicaciones web. Así que no es perfecto para cada aplicación web. Ciertamente hay aplicaciones web muy dinámicas para las que el modelo hipermedia no es bueno, pero al emparejar el modelo hipermedia con el scripting en su sentido tradicional en el entorno web, realmente puedes lograr bastante, y a menudo a un nivel mucho menor de complejidad que sería necesario si hicieras que JavaScript se encargara de todo en tu aplicación web.

Y así, en ese sentido, creo que es discutible no solo que HTMX está, como, escrito en JavaScript, sino que también es muy pro JavaScript. Puede permitir que JavaScript sea de muy alto valor. Puede permitir que se enfoque su valor en exactamente lo que JavaScript y solo JavaScript puede hacer, que es ser el lenguaje de scripting nativo para la web.

Gracias. La primera pregunta que tengo aquí es ¿para qué tipo de aplicaciones es mejor HTMX? Y supongo que probablemente podrías darle la vuelta, como, ¿cuál es un tipo de aplicación tal vez que no construirías con HTMX? Claro. Creo que HTMX funciona mejor cuanto más cerca estés de una aplicación CRUD. Así que cuanto más... mejor sería como una aplicación web tradicional, mejor sería con un poco de HTMX espolvoreado sobre ella. Así que muchas, ya sabes, aplicaciones de negocio, de línea de negocio y cosas así. Creo que podrías hacer un Gmail bastante bueno. Estaría en línea. Así que la funcionalidad offline, ese es uno de los grandes problemas. Si necesitas comportamiento offline, entonces HTMX no es una buena elección. Algo como Google Maps es típicamente un ejemplo que doy porque con Google Maps, tienes muchas interacciones que son muy rápidas, y obviamente hacer un viaje al servidor en cada interacción no es una buena idea. Por otro lado, Dragable.js muestra que puedes integrar una experiencia más altamente interactiva con HTMX. Solo tienes que hacerlo con eventos.

Entiendo. Y en esa nota, como, ¿hay otras bibliotecas que crees que se combinan bien con HTMX para dar esa interactividad que si la estás perdiendo? Sí, seguro. Alpine.js es la más grande, diría yo, que he visto que mucha gente usa con éxito. Pero también, sé que hay una demo bastante famosa que un desarrollador dio en Djangocon en Europa donde usa HTMX, básicamente reescribe una aplicación en HTMX y tiene una buena experiencia. Pero sé que terminó usando un componente de vista dentro de una aplicación HTMX para una experiencia de edición altamente interactiva.

Y así puedes usarlos juntos, pero nuevamente, permite que esa aplicación de vista sea un pequeño componente en lugar de toda la aplicación.

¿Cuáles son las limitaciones de HTMX, si pudieras añadir alguna? Sí, creo que solo entender el modelo de hipermedia y, está bien, va a haber una interacción con un servidor, así que eso no significa que cada interacción tenga que ser con el servidor. Por ejemplo, esa demo de sortable JS que hicimos, podría reescribirse para que en lugar de reordenar y hacer una solicitud en cada caída, hagas clic en un botón y entres en modo de reordenamiento y luego les permitas reordenar y luego hacer clic en un botón de guardar y luego hacer otra solicitud. Ahora, eso obviamente no es una experiencia tan sofisticada, y estos son los tipos de concesiones que tienes que hacer cuando estás construyendo una aplicación basada en hipermedia.

Eso tiene sentido. Y tenemos un par de preguntas aquí sobre pruebas. Así que hay una que dice, ¿puedes integrarte con Cypress? Sí, y hay otra que es como, ¿cómo lo pruebas? ¿Es la prueba de extremo a extremo la única manera? Sí, la prueba de extremo a extremo es definitivamente la forma en que funciona, pero hay una infraestructura de pruebas de extremo a extremo bastante buena en este momento. Y así diría que es la forma normal en que pruebas una aplicación ahora. Probablemente lo que están contrastando es con probar tu API JSON. Y lo entiendo, pero con HTMX, colapsas. Dado que estás construyendo tu front-end en el back-end, estás construyendo tu HTML en el back-end, mueves mucha de tu lógica allí, y así puedes probarla allí. Y así tu estrategia de pruebas simplemente se vuelve diferente. Oh, sí, esa es una gran manera de pensarlo, porque en ese punto, sí, es solo probar tus puntos finales del back-end, no necesariamente cómo HTMX interactúa con él. Correcto. No sé si esto es una broma o no, pero hay una pregunta aquí. ¿Escala? ¿Escala? Supongo que también, tal vez si pudieras hablar sobre, ¿hay ejemplos por ahí de aplicaciones más grandes que se han construido con HTMX? Sí. HTMX no escala. Está bien. No, depende de lo que quieras decir. Depende de lo que quieras decir por escala. Así que hay algunas definiciones diferentes de ello. Desde un punto de vista de rendimiento, creo que la hipermedia escala muy bien. La web es un ejemplo de un sistema de hipermedia gigante, y ha escalado tremendamente. Puede que no escale si tu empresa está acostumbrada a la división front-end, back-end, porque HTMX elimina eso. Y así, si tu estrategia de escalado se basa en esa división, entonces podría ser difícil. Pero lo que sí hace es que hace a todos full stack. Cuando haces desarrollo en HTMX, te conviertes más en un desarrollador full stack. Así que la ventaja de eso es que ahora un desarrollador individual tiene propiedad sobre una característica en lugar de la mitad de una característica, ya sea el back-end o el front-end de ella. Y así creo que puede escalar en el sentido de que las personas pueden capacitarse en ello. Es un modelo más simple en muchos sentidos que los enfoques SPA más sofisticados, y así puedes escalar a tus empleados más fácilmente, creo, en la mayoría de los casos con él.

Pero hay concesiones. No quiero pretender que no las hay. Seguro. Esta es la más votada ahora mismo. Así que mucho del desarrollo web hoy en día está usando React, Next.js, etc. ¿Cómo ves a HTMX encajando en el ecosistema JSX? Sé que mucha gente está usando JSX en el lado del servidor, porque es un muy buen lenguaje de plantillas y creo que eso es probablemente lo más fácil, si estás familiarizado con JSX, probablemente lo más fácil. Y este es un error que he visto cometer a la gente, de hecho, con HTMX. Mucha gente se emociona con HTMX porque pueden usar un lenguaje de programación de back-end diferente. Así que, oh, voy a probar Go o voy a probar Rust o algo así, y entonces hacen tanto HTMX como un nuevo entorno del lado del servidor, y creo que eso es un error porque es simplemente demasiado. Creo que deberías hacer una cosa a la vez, y si estás familiarizado con JSX y conoces JSX, entonces probablemente lo que deberías hacer es simplemente usar JSX en el lado del servidor y comenzar a usar HTMX. No es súper difícil averiguar cómo hacerlo. Y así creo que ese es probablemente el mejor primer paso para un ingeniero de JavaScript es elegir algo y decir, está bien, vamos a hacer esto en SSR, pero voy a usar JSX en el lado del servidor y comenzar a trabajar con ello y averiguar cuáles son los patrones porque es simplemente una mentalidad diferente. Creo que también otra forma buena y efectiva para que los desarrolladores de JavaScript piensen sobre HTMX es usemos HTMX para las cosas tontas y usemos JavaScript para las cosas geniales. Y a menudo recomiendo probarlo con una herramienta interna que tal vez no tenga una gran experiencia de usuario ahora mismo y no tenga mucha atención. Pruébalo allí y adáptate a ello porque es una mentalidad muy diferente. Creo que mi libro, Hypermedia Systems, que puedes obtener en hypermedia.systems, es bueno, pero es un cambio de mentalidad, así que tienes que darle tiempo, y si introduces otra variable allí, como un nuevo lenguaje del lado del servidor, eso a menudo puede hacer que sea una mala experiencia. Eso tiene sentido. Mencionaré que tengo experiencia con, creo que se llama typed HTMX, y puedes realmente obtener autocompletado en tus atributos dentro de tu JSX. Sí, las herramientas están avanzando seguro. Sí, definitivamente funcionan bien juntos. Y había una pregunta aquí, como qué pilas de backend funcionan bien con HTMX? Creo que todo funciona bien con HTMX, y eso es algo de lo que estoy realmente apasionado es que la web siempre ha sido este tipo de sistema abierto con un montón de diferentes lenguajes de programación, Perl, espero que Perl haga un regreso, pero PHP, Java, JavaScript, OCaml, como todos estos lenguajes, Haskell Lisp, todos estos lenguajes, quiero que todos ellos puedan hacer desarrollo web y hacer, ya sabes, buen desarrollo web. Y así, HTMX, al poner ese enfoque de nuevo en el lado de hipermedia de las cosas, creo que permite que estos lenguajes sean geniales para el desarrollo web. Y así, creo que si tienes HTMX, tu decisión en el backend se convierte más en, ¿qué lenguaje quiero usar? ¿Qué herramientas son como, si estás en IA, tal vez Python sea el camino a seguir, porque hay tantas bibliotecas para ello. Y así, puedes tomar esa decisión basada en tus necesidades de backend, en lugar de como, bueno, vamos a tener una base de código JavaScript gigante de todos modos, así que también podríamos usar JavaScript en el backend. Definitivamente. Y esta siguiente pregunta es, parece amigable con JavaScript, pero ¿qué hay de TypeScript? ¿TypeScript? Siguiente pregunta. No, estoy bromeando. Estoy bromeando. No tengo ningún problema con TypeScript. No lo conozco muy bien. Obviamente HTMX no está escrito en TypeScript, pero, ya sabes, creo que es un, me gusta, quiero decir, ¿de qué voy a hablar mal de TypeScript? Me gusta Java. Así que, siento que es un buen lenguaje de programación, y puedes usarlo en el lado del servidor para crear HTML, así que, genial. Ya sabes, puedes usar HTMX con él efectivamente, apostaría. Genial. Muy bien. Esas son todas las preguntas para las que tenemos tiempo ahora, pero si tienes más preguntas, puedes seguir a Carson hasta el Glassroom, y puedes realmente hacer tus preguntas en persona, pero muchas gracias, y por favor denle un aplauso a Carson una vez más. Gracias.