Carson is so amazingly down to earth and sensible. The whole web development world gets a jolt with his library and ... "yeah, I don't really do a whole lot of web development"
Using a combination of htmx and a UI heavy weight framework is incredibly powerful. You cover basically all your bases. Htmx would be in control of the vast majority of your UI, and the UI heavy weight framework will only be used when you need that need that highly dynamic client side UI that would otherwise suffer from a round trip to the server. It's great stuff!
I don't recommend trying this with a React framework, as their use of two DOMs (shadow and real) quickly make this approach a nightmare. Curious how this might work with Svelte, though, since it doesn't compare DOMs to provide reactivity; would its use of classes to make components discrete wind up getting in the way, or helping?
@@fleeb React would only be controlling its own slice of the DOM though so diffing shouldn’t be affected. If you start targeting React controlled DOM with htmx then yea, you’re in for a rough ride.
I can't remember where else I said this, but I had thought of something like HTMX back in the mid-'00s, and I'm just glad that someone else wasn't as lazy as I was. I haven't used HTMX for any projects yet, but I'm considering it for one, and I recommended a friend look into HTMX.
I just started a project recently, and scrapped the SvelteKit approach I originally took to use htmx instead (because it looked like it might fit the use case better, and I don't really like using JS on the backend). I don't have any regrets. The app I want to build has some tricky elements to it, and occasionally I find myself dipping into some peculiar stuff with htmx and its companion (_hyperscript), but when I find myself getting into the weeds, a shift of thinking causes me to find a simpler approach that works well. So far, it feels snappy and the code looks fairly clean. The stack: golang with templ, htmx, _hyperscript, sqlboiler (a golang library for an ORM... but some folks might want to consider SQLC instead), sql-migrate (golang library to manage database migrations), and tailwindcss-extra (using daisyui as a plugin). With this stack, I can mostly build the app and see the changes to my UX happen on-the-fly, with an occasional need to regenerate the tailwind.css (which I might be able to address if I figure out how to get tailwindcss-extra to properly watch all the correct files while I'm developing, and get templ to react to regenerating tailwind.css).
If you think about it, HTMX is like manually creating Microsoft Web Forms (with some UpdatePanels). I have a large Web Forms database frontend, and I'm going to use HTMX to throw in some pages that are a little more SPA like. It's a huge site, so there just isn't any good place for code I have to do a build on. My initial testing with HTMX is going well. Even though I know how to use React, it's just too hard to work into a multi-page application. Converting the multi-page application to React or Vue would be a huge undertaking. Working by myself, I like to keep things simple. As soon as I saw HTMX, I thought, "I can make that work."
At 17:58 he mentions the very real issue of JSON data's inefficiency due to repeating the keys of the objects when transferring tabular data. I ran into this very issue years ago, working around it by transferring CSV and converting that to JSON after it loaded (using tools like d3js). Another facet of inefficiency that this technique doesn't address, though, is if the values of your data also repeat quite a bit. I figured out a way around this as well, using something not dissimilar to how ZIP files work, by transferring an array of strings, then a CSV of the data where the column data were numbers pointing into this array of string. These techniques allowed me to transfer a stunning amount of information for my use case without consuming a lot of bandwidth or memory. HTMX would not have helped me for these scenarios, and thankfully JavaScript has come a long ways, allowing these techniques to work very well. OTOH, some might say I should have used more queries on the server's side to handle this ridiculous information overload, but in my use case, I needed to create a dynamic 'report' that worked offline, so this wasn't an option.
I don't know why exists this persistent idea that React is a walled garden, because you can add React without making your backend or even all frontend React, you can add react just for a simple component and have 99.99% on JQuery or something else, even HTMX, the problem is that we devs get scared of the interop between technology and we are attracted to the wall garden because there are tools to bootstrap everything and is the trendy cool fad that we are already hating and cursing.
I finally finished the HTMX version of Wes's sick fits! Changed the theme to be my own so it wasn't a one to one carbon copy of the UI - ua-cam.com/video/Is0aMyMAAj4/v-deo.html
while technically true, this statement feels a little pedantic. htmx is an engine to make what any of us old farts wished SSI could do 30 years ago. Engine has to be written in something, and really the only rational language to write that in is JavaScript because ubiquity.
Yep, in the same sense of a wheel, that works into a car as well as into a train. Both complete a similar job, despite that it performs in a completely different way. In the end, everything is JS, just running out of the browser! Hahaha
Carson is so amazingly down to earth and sensible. The whole web development world gets a jolt with his library and ... "yeah, I don't really do a whole lot of web development"
HTMX has made me enjoy frontend development again
Honestly, htmx with vanilla php is looking really tempting these days.
This is my current stack lol 😊 PHP 8.0 + HTMX v2 = ❤
Really good devs embrace simplicity, it's so good to see people aiming to simple and effective instead of abstract code acrobatics to create stuff.
Reading his book right now - great stuff!
Using a combination of htmx and a UI heavy weight framework is incredibly powerful. You cover basically all your bases.
Htmx would be in control of the vast majority of your UI, and the UI heavy weight framework will only be used when you need that need that highly dynamic client side UI that would otherwise suffer from a round trip to the server.
It's great stuff!
I don't recommend trying this with a React framework, as their use of two DOMs (shadow and real) quickly make this approach a nightmare. Curious how this might work with Svelte, though, since it doesn't compare DOMs to provide reactivity; would its use of classes to make components discrete wind up getting in the way, or helping?
@@fleeb React would only be controlling its own slice of the DOM though so diffing shouldn’t be affected.
If you start targeting React controlled DOM with htmx then yea, you’re in for a rough ride.
This was awesome, fun hearing some behind the scenes on htmx!
I am using HTMX and Stimulus... and simply rocks
HTMX is so unbelievably useful, simple and logical that it just exposes how clunky most JS frameworks have become.
Carson hits the trifecta again … baseball hat with St. Louis Cardinals logo, camouflage, and flannel. I love htmx!
Carson looks like a very cool guy. I wish I had such proffesors at college
Another Banger incoming!!!! HTMX is super dope!
I can't remember where else I said this, but I had thought of something like HTMX back in the mid-'00s, and I'm just glad that someone else wasn't as lazy as I was. I haven't used HTMX for any projects yet, but I'm considering it for one, and I recommended a friend look into HTMX.
I just started a project recently, and scrapped the SvelteKit approach I originally took to use htmx instead (because it looked like it might fit the use case better, and I don't really like using JS on the backend). I don't have any regrets. The app I want to build has some tricky elements to it, and occasionally I find myself dipping into some peculiar stuff with htmx and its companion (_hyperscript), but when I find myself getting into the weeds, a shift of thinking causes me to find a simpler approach that works well. So far, it feels snappy and the code looks fairly clean. The stack: golang with templ, htmx, _hyperscript, sqlboiler (a golang library for an ORM... but some folks might want to consider SQLC instead), sql-migrate (golang library to manage database migrations), and tailwindcss-extra (using daisyui as a plugin). With this stack, I can mostly build the app and see the changes to my UX happen on-the-fly, with an occasional need to regenerate the tailwind.css (which I might be able to address if I figure out how to get tailwindcss-extra to properly watch all the correct files while I'm developing, and get templ to react to regenerating tailwind.css).
If you think about it, HTMX is like manually creating Microsoft Web Forms (with some UpdatePanels). I have a large Web Forms database frontend, and I'm going to use HTMX to throw in some pages that are a little more SPA like. It's a huge site, so there just isn't any good place for code I have to do a build on. My initial testing with HTMX is going well. Even though I know how to use React, it's just too hard to work into a multi-page application. Converting the multi-page application to React or Vue would be a huge undertaking. Working by myself, I like to keep things simple. As soon as I saw HTMX, I thought, "I can make that work."
At 17:58 he mentions the very real issue of JSON data's inefficiency due to repeating the keys of the objects when transferring tabular data. I ran into this very issue years ago, working around it by transferring CSV and converting that to JSON after it loaded (using tools like d3js). Another facet of inefficiency that this technique doesn't address, though, is if the values of your data also repeat quite a bit. I figured out a way around this as well, using something not dissimilar to how ZIP files work, by transferring an array of strings, then a CSV of the data where the column data were numbers pointing into this array of string. These techniques allowed me to transfer a stunning amount of information for my use case without consuming a lot of bandwidth or memory. HTMX would not have helped me for these scenarios, and thankfully JavaScript has come a long ways, allowing these techniques to work very well. OTOH, some might say I should have used more queries on the server's side to handle this ridiculous information overload, but in my use case, I needed to create a dynamic 'report' that worked offline, so this wasn't an option.
Is that... a vintage iPod in Carson's background (bottom left, on a chair)?
OK that Microsoft story is hilarious. "Interesting" 😂
long time listener first time watcher
I appreciate the video podcasts! What took you so long? Lol
Syntax was always a side project for us. Now that it’s our main gig we were able to hire a producer and up our game.
htmx2? 😮
Locality of Behavior is similar to what the Functional Programming community has been called Referential Transparency
I don't know why exists this persistent idea that React is a walled garden, because you can add React without making your backend or even all frontend React, you can add react just for a simple component and have 99.99% on JQuery or something else, even HTMX, the problem is that we devs get scared of the interop between technology and we are attracted to the wall garden because there are tools to bootstrap everything and is the trendy cool fad that we are already hating and cursing.
A bit surprised that anyone puts Elixir and Liveview on the table since it's like HTMX on steroids
I finally finished the HTMX version of Wes's sick fits! Changed the theme to be my own so it wasn't a one to one carbon copy of the UI - ua-cam.com/video/Is0aMyMAAj4/v-deo.html
Thanks that was fun to watch
if you have clunky full page refreshes is your fault as developer.
HTMX is JS. You feel like is HTML while coding, but is simply javascript.
while technically true, this statement feels a little pedantic. htmx is an engine to make what any of us old farts wished SSI could do 30 years ago. Engine has to be written in something, and really the only rational language to write that in is JavaScript because ubiquity.
Yep, in the same sense of a wheel, that works into a car as well as into a train. Both complete a similar job, despite that it performs in a completely different way. In the end, everything is JS, just running out of the browser! Hahaha