Is HTMX a Joke??
Vložit
- čas přidán 15. 05. 2024
- 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 syntax.fm/726
------------------------------------------------------------------------------
Hit us up on Socials!
Scott: / stolinski
Wes: / wesbos
Randy: @randyrektor
Syntax: / syntaxfm
www.syntax.fm
It also gives backend devs and option to create UIs without the need to learn react, nextjs, Svelte,...
For like internal tooling or Apps.
Thymeleaf exists :D
@@FlintBits Thymeleaf is "just" a templating engine.
This!!! I have refused to learn javascript. Every attempt ive tried to do an ajax call in pure js or with jquery, i just couldnt get it to work. I scoured so many results from google trying example upon example and couldnt get anything to ever work. I dont want a full js front end either. im a backend dev. and htmx just made it easy to make things responsive with only a couple of tags. The next hurdle in my journey is whether or not i want to use a template engine or stick with vanilla php, concat my html into a var, and then output the var.
HTMX is awesome, feels natural. Haven't needed anything else.
I'd love to hear where it falls short for you.
@@syntaxfm So far for my workflows, none that I can think of at the moment. In any case, the HTMX documentation makes clear scenarios where it may not be the best tool.
I haven't thought of a way for my UI to be a function of my application state with htmx unless I send down the full page and just boost.
Sending down partial UI updates is very imperative, and feels a lot like the jQuery and backbone days.
What do you think about separation of concerns? Htmx makes the backend and the frontend be tightly coupled and that may be bad for big teams and big projects.
This might be a strange analogy but what Next did for react devs is what HTMX does for backend devs. Theo had a good video about this but just like Next (or Remix) allows your react app to reach into the backend sphere, HTMX allows those using templating engines to reach a little further into front-end interactivity.
I have been liking HTMX so far, I made a tiny search engine with it on a Go server and it felt natural to tap back into the PHP days except my users don't need a full browser reload when I return some hypermedia (or when navigating with the app with hx-boost). You can keep that similar paradigm but give your users a little more of that more cohesive SPA feel.
a live coding session would be much appreciated. It was a great talk!
This is a very insightful conversation. A lot of good points made!
Glad to hear it. Def interesting/
Used HTMX in my last project.
Saved bunch of time for me.
I was toying around with HTMX and went a little crazy and ended up re-creating my personal website with it. Went with an Express server and was kinda shocked I was able to pull it all off without a template engine. On the server I just used template strings, pushed to an array and ended with a res.send(content.join(' '). I was even able to create a markdown editor with a live preview. Got a bit excited because I was using Django and that was a pain in the ass to deploy on my dedicated server via docker.
Is the markdown editor on GitHub? Would love to see it
I like it because I don't have to learn a new language/framework. I just decorate, route the requests and send back HTML (in this case snippets of templates from Go). It gives me opportunities and lightens the client side coding.
I really like this style of discussion today. It's like Scott kinda prepped to be the expert, and then Wes played the first reactions or student or maybe skeptical side - and then they could explore the middle ground. Maybe it's just that I've never seen it on video? (I haven't listened in a while). Something I've been toying with when creating video lessons - is to have more people involved and to have pairing instead of just one person going through their steps. This reminds me of that feel.
Yeah I looked at a project I did and I was using react query for the majority of my state which was server state. The rest of the js was popovers and dialogs. I did use preact on one page for an interactive table with cells and stuff. But I’m totally fine for pulling in reactivity when I need i
To me the main downside is that all the convenience tooling has been focused on spas and js frameworks so you have to roll some of these things yourself. I’d like to see more in this space
HTMX looks amazing! How does it handle optimistic rendering? It seems the SPA's might still have the edge for that?
Great explanation as always.
To be clear when you say optimistic rendering, you are referring to optimistic ui responses when mutating data?
any news on hype the meta framework?
Node + JSX + Alpine + HTMX 💚
Would love to see a part two where you do it together in code
@7:16 - Alpine is not a competitor of HTMX, they work synergistically. While HTMX fetches the state from the server as a snippet of HTML, Alpine allows you to handle the state on the client-side end, both done in the hypertext. That way, HTMX does the talking with the server and Alpine does the reactivity. While I am worried about the HTML getting bloated, I look at the stuff going on in my javascript tags or linked js files sometimes and just think that maybe it's better that way.
Well HTMX with a template engine like nunjucks..easily replaces react in most use cases (where it's not already replaced by htmx/whatever back end)...
24:06 I think you should revisit this question. You hashed out the strawman version of it, which is that React’s virtual DOM is terrible and that’s why everyone is moving away from virtual DOMs. But that’s not the Sveltekit strategy. In Svelte land I can be 100% server rendered for as long as I want and then opt-in to a little bit of client side in seconds if the use case pops up. It seems like that flexibility is going to be a massive win over HTMX for long lived projects that need to grow and evolve.
I don’t know if I’m actually right about that because I feel like I still don’t quite get HTMX. I would love to hear someone who’s really familiar with HTMX make the argument against “modern”, non-vDOM frameworks like Svelte or Vue.
Same. To be clear, I’m not even sure what the ideal solution is in personally, I still prefer Svelte. But there is something super enticing about cutting out the complexity.
In 2019 I was looking at doing a rewrite and I wasn't happy with all the javascript. So I started to look at at moving as much as I can to the server. I was still returning JSON, but sometimes that JSON would have HTML to replace parts of the page and sometimes that JSON will have a single value to update a single textbox. I had full control over what I replaced, how much, and when. My stack was just C#, HTML, vanilla JS, and a little bit of CSS. No other libraries was needed. Then HTMX get release in late 2020.
People looked down on my idea pretty hard... then comes 2023 and suddenly doing it all on the server is cool again and HTMX becomes popular. /Insert guy flipping table here...
At least you know you have good intention.
@@syntaxfm I suppose... but everything I developed, designed, built, and planned for the future was just ignored by my boss who switched back to building 2 applications. 1 front end application and 1 back end application. Yes, doing another full rewrite less than 2 years after I proved my approach was a great fit for what were doing. I was so frustrated and unhappy that I changed jobs and now I'm at the worst job I've ever been. What was talked about in the interviews was the complete opposite of what the job actually is. Anyway...
I've slowly started work on my own, I guess, library to take my ideas further. The main goal is to have as little JS as possible. I wrote a little app over a year ago now using TryPhotino that controls volume levels on my system and can override windows. The code base isn't pretty... it's more of a working experiment, but it ended up with only 4k of uncompressed vanilla js. Using JSON and websockets I was able to update the UI with C# generated HTML, but could then push updates to the UI every 50ms and only update values to show volume levels of each app on the left and right channels without replacing any HTML resulting in a much smoother UI experience.
Vanilla HTMX wants you to return just HTML from the server, but I prefer the options JSON gives me where I can return HTML if I want/need, but can also return data or even both in a single response using just 1 endpoint. With HTMX, it seems like you need extra stuff to have the best of both. My experience with HTMX is still very limited so maybe I'm wrong here.
I'm finding it fascinating to see how other people are doing server side rendering and partial UI updates. Looking forward to take a look at Hype. I'll quit my rambling now :)
30 years later and tacking "x" onto everything is coming back in style
How quickly everything is forgotten, a little over a decade ago used this approach everywhere, I think the new generation does not realize how difficult it is to support such applications, and where it was enough they continued to do without htmx
This approach was not done a decade ago. We started doing some of these techniques in Rails back then, but it's really not the same. Try to keep an open mind because it is different.
@@syntaxfm PJAX not the same, where is real difference?
There is generally just more control here with all things like forms being progressively enhanced. The argument isn't that we should be using HTMX for everything, but there are tons of use-cases where it excels and front end frameworks importing json fail.
Wes can't get out of React frame of mind. Funny. 🤣
htmx is so refreshing. rsc's is too much. i'm back in school to do something else long term. i've worked in the industry for around 10 years. enough is enough for me.
LMAO Lang + HTMX FTW
Wait, we stopped using the term AJAX? Man, I didn't get _that_ memo! Maybe because I'm a back-end guy from the 90s 😂 We still say Web 2.0, right?
Yeah, ajax hasn't been talked about much since the rise of front end frameworks.
@@syntaxfm Hah! I still call it an "AJAX request" and none of my team pick me up on it. They must think I'm such a Boomer (although I'm actually Gen X-Wing) 😂
Your option will depended on when you went to school or came into the market. People have a bias for what the know. here I am having used every web library since 1995
"Bug Creator" 😆
With HTMX you don't have to have "Client side state management". No React Context, no Redux, no complexity. HTML IS the state.
Sorry but I'm going there. "htmlX Gon' Give It To Ya!" Again, apologies. [Has left the conversation]
Would I be correct if I say HTMX uses SOAP(Instead of REST) for API?
Hey guys, real talk, you can improve your podcasts by NOT staring at the computer instead of engaging us with eye-contact. Or, if you do, show the screen, show us what you are looking at.
Other than that, nice job!!
I don't think Scott went enough into the downsides. There are serious ones.
We are having the creator of HTMX on the show next week. What kind of downsides would you like me to ask him about? What kind of downsides did you run into? Not saying there aren’t any, but I’m curious what other people are hitting.
*hTmL iSn'T cOdInG* in shambles
HTML / CSS / JavaScript -> my favorite programming languages
wes is triggered
It’s funny to see the kids be in awe about what we were doing with jQuery for 10 years before the JS Frameworks of 2016 brought a decade of stupid. HTMX just does 2010 better, with zero boilerplate code. But the way to think about the app is the same. It brought back common sense into the field.
I feel like it’s 2008 again when the generation of devs trained on Flash/Adobe Flex were finally dumping that for HTML5/CSS3/Ajax.
In 5 years, the tech debt left behind by all versions of all JS frameworks will be even worse than what Flash ever did.
Calling us kids is flattering tbh. FWIW we’ve both been in the industry since web safe colors and table based layouts.
@@syntaxfm no no, i meant the young devs in general, not you guys :) but you do look young. Feel ya for the table based layouts. Remember chopping up PNGs in Photoshop to create shadows around stuff before box-shadow? And then realizing everything’s broken in IE6. Good times haha
@@life_days Slicing psds like a chef. Sliding doors, image buttons, image swapping on hover. The classics.
I dislike DSLs.. the best part about react is that it’s pure JS/TS .. no learning how (a lot) of weird attributes work specific to that framework 🤷♂️
jsx has a lot of non standard JavaScript/HTML, where custom attributes are valid html. You could say this about things like svelte or vue, but htmx is way more pure in this regard than jsx.
htmx is probably the biggest joke in web dev in recent years. You can't create any serious large-scale interactive web apps with it. Good luck trying to create PWA that need to work offline or anything like Google Maps with htmx. Yes - it is a joke.
Why would you use a tool like htmx to make that kind of app? How many web apps are you personally building that actually work well offline?
I did exactly this last week. I created a PWA using htmx where the service worker intercepts certain API requests, queries an IndexedDB database, and returns HTML. Offline support works great!
@@markvolkmann1117 it would be much easier and cleaner to do it with a modern frontend framework like Next or Nuxt.
You don’t need to critique things just because you haven’t tried it yet. People said the same about tailwind and see where we are. Sometimes you just need to step back and look at things and ask why am I doing this and the way I am doing things.
I was getting really upset 😂