Scott and Wes unravel the mysteries of HTMX, exploring the essentials for getting started, its powerful capabilities, limitations, and possible stacks for building primarily server rendered applications.

Show Notes

00:00 Welcome
02:07 Brought to you by Sentry.io
02:53 What exactly is HTMX?
04:30 What you need to know before working in HTMX.
04:35 You need a server.
05:35 You'll most likely need a templating engine.
06:42 You most likely do not need as much client-side JS.
08:33 You don't work in JSON
11:15 Not something you can swap out your UI with in a SPA.
11:48 Brings back AJAX
13:32 So, what can it do?
15:20 And what it doesn't do.
18:25 It doesn't do server-side responses.
19:09 What about animations?
19:20 What about CSS?
19:57 What about Web Components?
20:06 What about third-party client-side JS?
20:18 What about WebSockets and SSE?
20:30 What about extensions?
21:00 Wes' "bomb" question.
24:16 What Scott likes about HTMX.
25:45 What Scott doesn't like about HTMX.
30:33 Hype, Meta Framework.

All links available at https://syntax.fm/726

------------------------------------------------------------------------------
Hit us up on Socials!

Scott: https://twitter.com/stolinski
Wes: https://twitter.com/wesbos
Randy: @randyrektor 
Syntax: https://twitter.com/syntaxfm

http://www.syntax.fm

Kevin

FaunaDB

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

HTMX is a small library for swapping out parts of the UI with a response from a server. It requires a server to send HTML to the client and can be used for client-side routing, progressively enhancing forms, and more. It simplifies development by moving most of the logic to the server and eliminating the need for extensive client-side JavaScript.

Is HTMX a Joke??

For what it’s worth, I’m just doing my first HTMX fun project: small multiplayer game login, lobby and configuration pages, with sever side pushes of content – the game itself runs in webgl and is separate.
<ul>
<li>
Server-side logic: from my point of view (I’m mostly a backend developer), all in one side simplified my life (and its quality) significantly.
</li>
<li>
Transfer sizes: yes, transfer of the whole parts of the HTML (as opposed to smaller json data) is a bit bigger … but in practice, with most networks in 1st world country, it probably doesn’t matter. Latency is small, transition is imperceptible and things seem responsive (if in the same zone). If you still have a 2400bps modem … probably not for you.
</li>
<li>
I only keep 3 areas that are targetable: navbar rarely change, footer also, and the main content area. There is zero mess in my case. I wonder how it would scale if there were dozens of updatable areas, on different triggers. I simplified by always updating the whole “content area” (it can have lists and forms), so far it works pretty well.
</li>
<li>
Asynchronous events (pushed by the server) triggers Htmx replacements, also all became super simple.
</li>
<li>
Much simpler to learn HTMX than javascript … by a very large margin :). It’s just a few tags to get lots done. For those backend developers like me that try to stay away from javascript as much as we can.
</li>
</ul>
Just to say that for prototyping, small sites of limited complexity, I found Htmx delivered on the promise, and I’d definitely use it again.
On larger/complex sites … I haven’t tried it.
ps.: Its javascript API was trivial and well documented, when I integrated it with my own WebSocket library for the game.

I’ve barely understood what HTMX is, to learn it’s generally a SERVER-SIDE technology was not at all understood to me until now.

Short answer: yes.
Doing roundtrips just to update tiny parts of the UI is the worst thing you can do. You wasting server resources and make the website less responsive (i mean its responds to user actions slower).
Its made for devs who dont know javascript, but they need to learn a whole arsenal of syntax to use htmx. With little more effort they would easily learn JS basics + Svelte for example.

Why did I read <a href="https://htmx.org/" target="_blank" rel="noopener nofollow">https://htmx.org/</a> and try to learn HTMX when they explain it really well 😂. Nice Video 👍🏼

HTMX is a good tech but I think for backend devs who want to do frontend, not all apps are server side heavy and as a frontend dev having to now do server stuff is less like-able, it’s the same as server components to me anyways, we all on the server after all… but the tech is nice, it helped show us how complex our current frameworks are and gonna pave a way for the next generation of tech that won’t bend to complexity and modern flaws… But I don’t see myself using htmx, in fact am making my own htmx but client side first one hehe!