Talking Drupal #514 - HTMX

John: This is Talking Drupal, a weekly chat about web design development from a group of people with one thing in common. We love Drupal. This is episode five 14, HTMX. On today's show we're talking about HTMX, what it is and why it could be a game changer for Drupal. With our guests, Shawn Duncan and Carson Gross.

We'll also cover refresh list as our module of the week

welcomes talking Drupal. Our guests today are Shawn Duncan and Carson Gross. Shawn has been developing solutions with Drupal since 2009. He is an active volunteer in the Drupal NYC community, serving as chair of Drupal NYC Incorporated. He recently became a subsystem maintainer of Drupal Core Ajax. We'll probably talk about that a little bit.

And Shawn and his wife make their home in New York City. He is an ordained priest in the Episcopal Church, enjoys computer gaming and training his Labrador Retriever. Shawn, welcome to the show and thanks for joining us. Happy to be here. John Carson Gross is a coder and teaches computer science at Montana State University.

He is the creator of many open source projects, including HTMX, a hypermedia oriented frontend library for web development. He lives in Bozeman, Montana. Carson, welcome to the show. Thanks for joining us.

Carson: Thanks for having me on, guys. Appreciate it.

John: I'm gonna continue on, but no word of a lie. I have so many questions just about, just about the facts in your intros, but we'll see if we can, we can cover some of those in the show as we go.

For those that don't know, I'm John Picozzi, solutions architect at EPAM and today my co-hosts are joining us for I believe, his second show, Rich Lawson, associate Director of Technology at Evolving Web. How's it going, Rich?

Rich: Going well, thanks, John. Glad to here and,

John: and joining us. As always, Nick Laflin, founder at nLightened Development.

Nic: Happy to be here.

John: And now to talk about our module of the week, let's turn it over to Martin Anderson Includes a principal solutions engineer at Acquia and a maintainer of a number of Drupal modules and recipes of his own.

Martin, what do you have for us this week?

Martin: Thanks John. Have you ever wanted to give your Drupal site a more application like feel by only reloading parts of the page that need to change? There's a module for that. It's called Refresh List, and it was created in March of 2016 by Wim Lear, but recent releases are by Ambient Impact, a fellow Canadian.

It has a 2.0 0.0 alpha nine release available and it is actively maintained, has security coverage and test coverage, as well as a documentation guide. Now, there are 40 open issues on the project, only two of which are active bugs against, against the current branch, and according to drupal.org, the.

Project is in use by two sites currently. Now, the refresh list module aims to give Drupal sites a smooth, fast, and responsive experience by using JavaScript to selectively update the parts of the existing page that need to change instead of a full page refresh. It uses the HTML five history API to ensure the browsing behavior is equivalent and unsupported.

Browsers will see a standard page refresh instead using refle refresh list also makes it possible to use transitions with or without the view transition, API in modern browsers, morphing and persistent elements to enhance the application like feel. There is some indication that sites may encounter issues if they use refresh list with JS aggregation enabled.

So it's probably better to use it if your site has HT P enabled in its hosting. Refresh list is currently built on the Turbo library built for Ruby on Rails, but there is already an issue open to move the implementation to use HTMX instead, which is why I thought it might be a good conversation for today's episode.

So let's talk about refresh.

John: My, my first question here, which is like, this seems very cool, but I'm just wondering like, does your site have to be structured in a certain way? Like for example, like all my content needs to be on one page or is it like it could apply to any site, just a regular site, you bring it in and it just works.

Martin: So, we'll confess, I haven't really had a chance to kick the tires a lot myself, but, but notionally the way it works is you do, you don't have to change anything about the way your site is structured. So a Drupal, modern Drupal site will know which parts of the cha which parts of the page are changing.

So, you know, using the various cache layers. And so based on that, it should be able to provide that application like experience without having to go to some kind of a more like, you know, dedicated code heavy front end.

John: So like if you have standard header, standard footer, standard sidebar elements, all those things are just gonna stay the way they are.

And everything that's different will, will change on the page. That's really cool.

Shawn: And Ambient Impact's been a active participant in our issue of view and in our channel. And the Turbo is what he inherited when he took over the module. But he is very intent on being able to change it over to HTMX after he is satisfied with this working well on triple.

John: Interesting. Nick, what were you gonna say?

Nic: I, I was just gonna comment that I love the logo that they have. It's, it's very retro retro feeling.

John: I did, I did code to the module page and I was like, Ooh, look at that. I'm like, oh, that's like, I feel like I want that on a t-shirt. It's pretty cool. I also like the structure, structure of their module page with like the, the very visual call outs and whatnot.

It is very, very well structured. So it's clear that, that somebody has, has developed this module, cares very much for it. So that's nice.

Martin: It's also worth mentioning that the project page has a link to Omni Npia, which is a site that has refresh list running in production. So if any listeners want to wait a second experience, what that, what that looks like, you can go there and click around.

I'm doing that right now.

Nic: So one, one question I did have, by the way though, is this project has been out for nine years and has two websites reporting using it. Do we know why it has had such a significant drop? Is it because it just moved because it looks like it had some older releases? Is it just that it's newly been picked up by somebody?

Because I've, I've seen this elsewhere. Somebody else mentioned this somewhere, so I think it might be an old module that somebody picked up and is refreshing for modern Drupal. Is that.

Martin: Yeah, that's a good question. I mean, as you say, going back, it looks like probably early after its release, it had over 150 site installs. Maybe a year or so later, it was up over a hundred again. And since then has sort of been in a, a gradual state of, of slipping off. But yeah, it's a good question.

It may be one of those things that was slow to get updated, let's say to Drupal nine. And then as the rest of the sites moved on, then people have gone to other alternatives. It's also possible that this is something that people were excited about before. The sort of headless excitement in Drupal sort of took off and, and you know, some people might see that as, you know, if you're going full headless anyway, then maybe there's less need to have something like this for your Drupal front end.

I, I can't really say for sure why people might've picked it up and then, and not continued on with it.

John: So, two, two questions Maybe. Can you select the transition that you have between like, between the pages? Like, so for example, with the the example site that they provide there, it basically just like fades out, fades in, right?

Can you, can you set your own kind of transition?

Martin: That's a great question. I, I did notice that it makes reference to some different techniques that you can use. When I was poking around the code base, I didn't really see any options or any places where you can sort of set configuration. Mm-hmm. So I have to imagine there probably is an ability to do that, but would maybe need to have some attributes in your template or something like that.

I'm, I'm not a hundred percent sure to be honest. Got

John: it. And then the last one, which you, you may not, may not know, but I'm gonna ask anyway. Any accessibility kind of issues or concerns with the fact that like, it doesn't appear to reload the page in

Martin: a standard way? That's a great question. They, I would think from an accessibility standpoint, the main concern would be that it respects the, you know, prefers reduced motion.

Attribute in the browser which I would hope, you know, sort of at the browser level that would be built in anyway. Mm-hmm. But I, I don't really know for sure, and maybe if one of our listeners has a better idea of, of how that interaction would work and you know, please update us in the channel.

John: Awesome. So I do wanna also state that this was an impeccable piece of advanced research by Martin to find a a very topical, topical module for our module of the week, as always. Martin, if folks wanted to connect with you, suggest a module of the week, talk about this module of the week, or just find you in general, how could they go about doing that?

Martin: We are always happy to have lively discussions about interesting modules, including candidates for a module of the week in the talking Drupal channel of Drupal Slack, where folks can reach out to me directly as man clue on all of the Drupal and social platforms.

John: Perfect. Thanks a lot, Martin. See you next week.

See you then. All right, listeners. The New England Drupal Camp is coming to Providence, Rhode Island, November 14th and 15th. This is a two day camp where day one features a higher ed summit. Trainings a contribution day, all capped off with a community social. Day two features sessions, a keynote, the infamous Drupal Coffee Exchange, and all capped off again with another party, an after party session.

Submissions are now open. We look forward to seeing you in New England in November. Find out more at Ned camp N-E-D-C-A-M p.org.

All right, everybody's back in their right spots. Nick has joined us again. So. Let's start with I don't know, it's probably a softball question for you guys, but you know, our listeners that are picking the show up, may, may have the question. And Carson, I'm gonna, I'm gonna point this one to you because you, you probably probably know it best.

Like, what, what is HTMX?

Carson: So HTMX is a is a front end library. So something I guess comparable in, not in size or scope, but comparable, I guess conceptually to something like when people think of React or maybe jQuery, although jQuery is a little bit lower level. So, it, it, and it's what I call a hypermedia oriented library.

So what it does fundamentally is it takes the ideas of Hypermedia and hypermedia just for your listeners for background, right? That's just like links and forms. Like if you're an old school web developer, and a lot of those people are old school web developers. Like you remember when the web was just links and forms and that was pretty much all you had.

Maybe iframes if you were fancy. And so, that idea of hypermedia links, you know, issuing a request and getting back what's called a hypermedia response or an HTML document HT MX takes that general, that that idea and then generalizes it. And so, it, it. I've written an academic paper on it that your listeners can look up.

It's a little, the language is a little funky, but what, you know, whatever. But the basic idea is this. Okay, what does a link do? A link, what happens is it shows up on a screen and when you click it, it issues an HTTP request and gets back some HTML and then that HTML replaces the current window. That's sort of like what a link does in the, in the standard case.

And so what HMX does is it takes that, that idea and breaks it into components and then makes them more general. So it says, okay. Let's make any element able to respond to an event. So any element can be what's called a hypermedia control. Now it can issue a request to the backend, and that's just the, you know, the way things work these days, dropdowns issue requests, and so on and so forth.

And then let's make it so that it can, that element can respond to any event that occurs in the doms. So, lots of events occur in the Dom Optin. You wanna respond to those events by doing something. And then finally, and this is I think probably the most important thing that HT MX gives you is let's take that request and then let's allow you to insert the return to content anywhere in the dom.

So rather than this full page refresh, we're gonna say, okay, we're gonna issue an HTB request, we're gonna get back some html. It might not be a full document, it might be an html. Gives you tools to select parts of a full document if that's the situation you have. But optin, it's not a full document.

And then you can tell HTMX when this content comes back, I want you to put it. Here in the dom, like, I want, I want you to put it in this div, or I want you to put it at the end of this list or whatever. There's a few different options or attributes that you have to control that stuff. And so it's all attribute driven.

You annotate your HTM l and so in that sense, it's very much like the hre attribute and standard htm html. But it gives you a more powerful, what I would call more complete hyper text. It makes HTML more complete as a hyper text. And so just takes those ideas of, of blanks and forms and generalizes it.

And it turns out there's an awful lot of pretty sophisticated UI patterns that you can build with that relatively simple generalization. So that's what HTMX is. What would you use it for? Stuff like infinite scroll becomes very easy, like three or four attributes in your, in your HTML. Things like active search.

So as someone's typing into a search box, bringing up the results as they type, things like that, that seem like they would require a fair amount of JavaScripts to implement, turn out to be pretty easy to implement using this sort of hypermedia mindset and this hypermedia oriented way of thinking.

Nic: And so since it's just attributes, it probably just works out of the box with things like native web components or custom web components, that kind of thing.

Right?

Carson: Yeah. We've had to do some work because native web components are really they, they, they sandbox, they're, they're dom really intensely from the, the surrounding dom we've had to do some work. And so it's not a perfect story but it's as good as we can make. We, it's as good as we can make it, given the constraints that have been placed on us by the API.

And so, a lot of people will use web components in conjunction with HT mx.

John: Okay. I, I will like to point out to our listeners, it only took about five minutes for Nick to bring up native web components on the, on the podcast today. Is that a score you keep regularly, John? So it's so great. You know, it's one of those reoccurring themes where we, you know, we know Nick really loves native web components, so I like, I like to just call it out when it happens.

Carson: , I'm trying to remember which it's called Facet. There's, so there's a, some HTM X adjacent technologies that have grown up sort of with this mindset of like, let's focus on hypermedia, let's use events and like the standard dom APIs, like form participation and stuff like that in order to build things.

Technologies that don't require a particular front. Like a lot of technologies today I think are to an extent making the same mistake that the jQuery plugins made, where they're like super tied to like one particular front end system. And so one sort of. Feeling and vibe that the HTM X community has.

It's like you shouldn't build something to work with HT mx. Instead you should build stuff to work with the web platform and then HTM X should integrate it with it using the web platform, which is, you know, form participation and events is the big way to do that. And so, sorry that's a little bit of a long spiel, but one of the technologies that's come up was one of the HT MX sort of community members built something called Facet, which is a way to sort of do declarative web components.

That's one area where like web components can be kind of weird because you have to have both JavaScript as well as HTML. And so this is a way to do that. So it might be something Nick, that you're interested in checking out.

Shawn: Take a look. Yeah. Okay. So just looking at H TMX as a technology itself one of the things that really caught my imagination is this declar two things that it completes or extends HTML and it's declarative nature.

And I've been a web developer for a long time, and I never really thought about this fact until Carson pointed it out in his book. Hypermedia Systems, which is linked in the show notes which goes into some of the theory behind all of this HTML and HTT P that go together, right? But HTTP has five verbs.

We use get and post all, all the time, but it also has put patch and delete, but HTML only, only encodes two of them. Yeah. A to a tags or links to get and forms to post, and that's it. But HTMX and now allows you to use the other five, other three. So in the long term, I'm intrigued about what might we do in Drupal, if we could use, other methods of HTTP in our requests, like, could you issue a delete request when you wanna delete something? Then there's the declarative nature of it. Browsers have gotten a lot better in their development tools. So you now can go in the inspector and hover over a, over an element, and then if there's an event listener attached to the element you most browsers, you get a little event bubble and you can go figure out what JavaScript is attached to it.

But that's a lot of clicking around, depending upon browser tooling. If it's, if we're using HTMX and there's, there's HTMX going on with that element, there are data attributes right on, right there on the page. So it's, it's all, it's all there. And I like that it respects HTML. I remember the first time I saw an Angular application like 15 years ago, and, and HTML was being messed with all over the place and all kinds of things were hidden and, and I, it was really difficult to figure out what was going on and was HTMX.

You can read the pa the source code of the page and you can see exactly what it's doing.

Carson: Yeah, that's, I think that's a really nice aspect of HTM X. And I wrote an essay. I've got a lot of essays on the HTM x.org/essays page. But there's an, an essay called Locality of Behavior that talks about exactly that feature of HTM X.

Where you, most of your developers, if they've, if they're old enough and they've done jQuery work, they've gotten into a situation where there's a button that does something and like, where does this behavior come from? And it's some selector in a JavaScript file somewhere else that's difficult to find.

And whereas with HT MX Shawn points out, like you, you put the attributes directly on the button so you can see, okay, this button issues a get to this URL and then it targets this other thing. And it's all just right there, you can see it. And so I wrote an essay called Locality Behavior that, that sort of tries to talk about what this idea is like the, the idea of putting.

The code on the thing, on the button. And it's a little bit in contrast with or in conflict with the idea of separation of concerns. Which, depending on how you think about it you know, if you're, again, if you're old enough, it used to be that we were told that we're gonna have our markup and we're gonna have our styling and we're gonna have our scripting.

And those are all separate concerns. We're gonna separate them. And there's something to that. But there's a trade off, which is you tend to lose that locality, that ability to look at a button and just know what it's doing right away sort of goes away. And so HTMX sort of goes the other direction with that.

There are other technologies that I think has sort of moved that direction, react, which is very much a different way of building web apps has a lot of locality where you, you just define a component and everything's right there in the component. So, but I do think it's an interesting idea worth thinking about for sure.

Nic: So it. I think we have an opportunity here because HTMX is kind of a, it's an open source library. It's fairly well known. I think it's getting more widely used every day. We're all on this call, we're all familiar with Drupal, which is a, a massive, you know, open source project, but it has kind of a huge system of contributors behind it.

I'm kind of curious what it's like on the day-to-day managing a library or system like HTMX. I mean, I know that you have other contributors, there's a lot of people in the community, but I'm curious about the difference between kind of the Drupal community and HTMX as a community.

Carson: Well, HTMX I think one thing about HTMX and I, I can't really contrast it with Drupal, the internals of Drupal but HT MX is is pretty like conceptually small.

And there are problems with that. So there's no magic with HTMX like you put in hx, get. On a button and it issues a get request to whatever URL you give that attribute. And that's pretty much it. And so it's, it's because of that conceptual simplicity. There's not like a ton of churn. So HTM X, just historically, it's sort of intercooler JS 2.0.

So JS was a library that I worked on back in thousand 13, and that was dependent on jQuery because everything was dependent on jQuery in thousand 13. And I HT MX happened I think five years or four years ago now, something like that. Okay. And that was a rewrite of h of Intercooler js without that jQuery dependency because JavaScript had gotten standard enough that it was possible to do.

And, and so because, and early on, or not early on, but maybe a couple years into Intercooler js, I realized that that conceptual idea of like, we're trying to generalize what are called hypermedia controls, so we're trying to generalize links and forms. Like take the ideas that are inherent in links forms, and just make them.

General. So any element can act like that. And that, that, that's been really good for me because it has, there's this philosophy, this philosophical idea that prevents me from wandering off and doing other things that are tempting. Like, oh, make it reactive, do this, do that. I've done, Ben done a pretty good job.

Not as good as I would like, but I've done a pretty good job of keeping HT MX pretty focused. And so, HT MX itself, the library just doesn't change that much. The API really hasn't changed significantly since it was in, you know, its first release. And that makes it, that makes it that makes it, you know, good in, that's good.

In some ways it's very stable and people can rely on the behavior. But it also can be tough because people wanna come in and contribute. Don't touch anything. I don't wanna break things. There's a lot of, you know, even with HDMX, a relatively small code base, like there's, there's a lot of implicit behaviors, and we're running into this right now.

Someone came in and he's trying to, and he's doing the right thing. He's trying to fix some sort of corner cases with semantics. But we put that out and then it breaks some other corner cases and it's, you know, you get into this Yeah. Point where it's like, okay, like let's just leave the corner cases, let's document them.

And we'll just live with 'em so that we don't break things for people. And there's an essay. There's an essay called The Future of HTM X, where I talk about that we haven't done as good a job as I'd like, but I really want to focus on backwards compatibility. And just not, just not moving stuff around.

I know that the problem that you run into with that from a project standpoint, and I'm sure Drupal runs into this as well, because people are like, this project's dead. You're like, no, it's not dead. It's just, it does its job pretty well. And so we don't need, we don't, you know, it doesn't, we don't need to have a keynote every year on this idea of hypermedia, like Yeah.

Systems. Like we, we know how they work and they do hear the pros and the cons to it, and so, you know, use it when it's appropriate.

Rich: Yeah, there's, there's a lot of complexities that you have to deal with in terms of managing the project. One thing I'm, I'm really curious about is, you know, you know, Shawn, if you could talk a little bit about, so we've been learning a lot about HT Max.

How is Drupal going to use it?

Shawn: Well the first, the biggest use case that we're targeting at the moment is to retire our existing Ajax API, which is built upon jQuery. So we're building a new subsystem to make Ajax requests and Ajax interactions that's built entirely upon Htm X's, the enabling JavaScript.

I'm sure we're gonna come up. We're gonna then use that to make all kinds of things better and our admin ui. But that's our first task, and it's big enough to, to bite off as a, as an initial thing. And we're in the course of that. We're gonna be giving all of our Drupal community developers a powerful toolkit, bring their activity you know, hasn't, hasn't been that many episodes ago that you had Pierre on talking about his, his his UX community.

They have a display builder that they're, that they're just released that's using HTM X. So I'm sure it's going to enable a lot of interesting and powerful features.

Nic: I, I just wanna point out too, that the Ajax system in Drupal. So Drupal has this thing where it innovates and does something that nobody else is doing, and then years before that happens, and then it kind of sticks with that solution for just a little bit too long.

In fact, the, the core Drupal Ajax system, if I remember correctly, it was built originally in 2007 on Aha, if anybody remembers that.

John: Mm-hmm.

Nic: Which was, oh, it's

John: old,

Nic: which predates Ajax, I think. And, and you know, there's been some modernization, but there hasn't been, as far as I'm aware, there hasn't been really a full scale rewrite since.

And so, aside from, I, I think this also helps with some of the, like, get rid of, you know, moving jQuery out of Drupal, which jQuery is great. I mean, everybody uses it, but native JavaScript can handle most of what jQuery was needed for in the past. You look at, and if you look at like library size, HMX is.

Compared to jQuery. So, you know, there's some performance benefits and things there too.

Shawn: Sure. And there are lots of times when Drupal loading jQuery just to do Ajax. So, as we steadily reduce the, the dependencies on jQuery we can reduce page load time because we're, we're lowing, we're loading less JavaScript, and that reduces the page weight.

It's also simpler the, the existing Ajax API we, we've configured classes that configured jQuery to do Ajax and just configuring J 40 to do Ajax is complicated. And so therefore the API is necessarily complicated. And so, that simplification makes things easier to maintain.

John: Yeah,

Shawn: we're gonna try to maintain some feature parody between what we used to do and what and what we're proposing to do, because I think what.

Done with the Ajax API was a good thing for most developers. A typical Drupal developer doesn't wanna know how the Ajax system, like what's happening under the hood to make it happen to thing on their page. They know that they have this content and they wanna replace it with something. And so in the Ajax API, we have a replace command.

And what we're proposing, we haven't built yet, but we're proposing for the, this initiative, for this process is to have an operation called Replace. But that goes along in the theme of the simplicity of HTMX. HTMX wants to know, well, what's the CSS selector for the thing that you want to take out of the request?

Like, what do you wanna grab? Give me a CSS selector. Where do you wanna put it? Give me a CSS selector. And so, our replace operation will be, give me the URL, give me the CSS selector of the thing you want to take out of the request. Give me the CSS selector of where you wanna put it and tell me how you wanna put it there.

Because really insert will do it for will, will make that swap strategy for you to make it simple. But under the hood, there's no difference between replace or insert. It's just what is your, what is your swapping strategy? But we wanna be able to, to developers to say, look, I wanna take this dynamic thing and I wanna replace something on the page and let the API take care of the rest of it for you.

So the, what's gonna make it the benefit for Drupal is the code's gonna be simpler. It's gonna be simpler to maintain. We're going to be able to get rid of a whole bunch of, of response processors and response creators that we're creating for, for the, the current Ajax API, and we won't be able to lose those things for a long time.

Help me out here, Nick, but I think that you, that the core team recently adopted a policy for disruptive deprecation. Are targeted for Drupal 13. Yep. So those classes are gonna be around for a couple versions of Drupal. But our objective is to stop using them in core and give con the contributed modules time to catch up.

Yep. And I just wanna highlight CSS selectors 'cause in the, in the Ajax API, it's all about Id DI

Nic: Oh

Shawn: yeah,

Nic: you're right.

Shawn: Isn't that right? Am I right Nick?

Nic: Yeah. Because that's all. Yeah. I think, I think you're, yeah.

Shawn: And so in the Ajax API, if you wanna replace something and it doesn't have an ID in the render system, you have to put a prefix in a suffix.

Like you have to wrap it in something to get and give it an ID so you can target it. Yep. Well, CSS has gotten so much more powerful in since what did you say? 2013? 2007? No

Nic: yeah, two seven.

Shawn: That was back to CSS one. Right. And now we're on C on css. Three. So you can target things really in a pretty sophisticated way with a CSS selector today.

John: Mm.

Shawn: And HT MX speaks modern, modern web language, so you can use any, if it, you can identify something with a CSS selector, it'll work. And, but the way CSS selectors work, if your CSS selector matches five targets on the page it's gonna get, am I right about this? Carson? It'll get inserted five times.

All the different selectors will get matched.

Carson: It depends on, it depends on the type of swap that you do. Okay. If it's a multis swap, then yes. If it's not a multi swap, it'll match the first one.

Nic: Okay. Which makes, which makes sense. And I imagine you just Yeah.

John: I mean. The, the simplification here is like a big, feels like a big win for me.

'cause like a lot of times, you know, people not only get confused, but also are get, get things get overly complicated between you know, jQuery, Ajax, you know, CSS, the HTML, all, all that stuff. So being able to you know, kind of push away some of that excess stuff and come in with HTMX and have it be so what sounds like more streamlined I think is gonna be is gonna be super, super powerful.

Super interesting. One question that I had in, in thinking about this is like, this sounds great, like, let's, let's, you know, let's do it, but, you know, Drupal's really has gotten much better in the last you know, we'll say five plus years, maybe 10 plus years at this point. I'm dating myself, but have has gotten much better about like, getting off the island, right?

Incorporating different technologies into, into Drupal core because they do, they do things better, they're maintained all of these things. I'm wondering though, I, I've never really thought about this or heard about this, but I'm wondering Carson like. How did you hear about this effort within the Drupal community and then like, how did you get involved to you know, kind of bring HT MX into Drupal?

Carson: I, I think someone either posted a link or I just randomly found a link to a discussion on the Drupal website about HTMX, and that's what I remember being the first thing. And I hadn't seen Drupal in, you know, a decade. And I was like, oh, cool. Like, you know, that's exactly one thing that HTM XI think does.

It takes those older web development fundamentals that a lot of people, to be frank, don't develop these days. Like a lot of people don't understand how a form can be used to submit data to a, to a site without react or whatever, without all this reactive stuff and a JS O-N-A-P-I and all the rest of it.

And so I saw that and was just like, Hey guys, you know, I glad to see, think about htm. Lemme know if I can be of, of help. And then I think I got an email, maybe Shawn, did you reach out to me? Yeah, I did. Shawn, Shawn reached out to me and was like, Hey, we're, we've got this effort going and here's a slack that you can join.

And so I, I really didn't do much except cheerlead. So, but they, they figured it all out. But that's interesting.

Shawn: But I like it so well, so far lemme say you did more than that, Carson, because for, for our listeners, Drupal has an official procedure for adding a dependency to the project. Like there's a set of standards that have to be met if we're going to adopt a new dependency.

And there's a checklist for what that, what that dependency has to have as part of its governance and infrastructure. And HTMX had everything except for a process for reporting a security problem privately.

John: Right.

Shawn: And it wasn't a big deal. It required writing a policy and enabling a few things on the GitHub repo so that there was a way for those to come in privately.

But in order for us to adopt HTM X'S dependency, I opened an issue in Carson's repo and proposed a draft policy. They massaged it a little bit. They approved the right GitHub things, and suddenly they had a secu security procedure, and then we were able to add them. But if Carson hadn't responded in a timely way, we'd still be waiting.

So thank you.

Carson: I accepted a, I accepted a pr. That was the extent, extent of my cut.

Nic: You also, you also modified it when I discovered that it didn't actually work and it had like 10 30 at night. So

John: let's go back, let's go back there for a second. So, initially a community member in your community, Carson, the HT MX community, said, Hey, look at this post on drupal.org, like Drupal has use HT mx.

And you were like, oh, Drupal, I thought that thing was dead.

Carson: I don't think anything's dead. We've got list users, man, we've got guys using, listen, we're, we're not

John: offended by that. Most most people think that think that Drupal doesn't exist anymore. We're, we're working to rectify that. Right. Interesting.

Carson: So, well. Go ahead and lemme just, let me just say like, that's one thing that I really like about HTMX. And you know, Shawn was saying earlier, and I, I, I missed a chance to sort of inter interject, but even though the model of HTMX is pretty simple, y your listeners, and I think Drupal developers will be surprised with the power to weight ratio, like what you can achieve by just swapping in bits of HTML.

From a UI perspective is it's, it's much, you can do a lot more than you suspect. So, you know, again, active search, like as someone's typing, bringing in search results is a great feature that a lot of websites don't have. That would be very easy to add with a technology like HTMX and Infinite scroll and like, you know, not losing your scroll state, like sort of like edit windows so you can edit things in a little box and not resold to the top and all that.

It's all very achievable with something like HT MX pretty simple mental model. And so yes, it's simple, but it's also pretty powerful and that's what I like about it. And another aspect that I like about it is that it takes technologies like Drupal, these technologies that sort of were grown during the, the hypermedia phase of the web.

Say pre pre 2010, right? Pre Google Maps. Google Maps came and blew everything up. But it takes the, the technologies that were honed on that earlier web on the, the hypermedia oriented web and makes them much more relevant. Like you can do a lot more with them. And so, you know, just another community that really likes HTMX is Django and Django also has this reputation of being sort of an older technology, but it's really good at producing HTML and I, you know, similarly, Drupal is really good at producing the HTML that you want.

And if you take something like HT HTMX and add it to that, it allows people to, to use those tools in a new and interesting way to add, to add functionality that previously was very difficult or required a lot of JavaScript or something like that. So, so,

John: Just outta curiosity there, like, so I'm wondering.

Going back to like, okay, somebody in your community told you there's an issue on drupal.org, so on so forth, right? Like, I think like everything you just said makes a lot of sense as to why HTMX should be included in Drupal. I'm wondering like overall though coming into the Drupal community what, what's your experience been like?

I'm assuming positive 'cause you're here on a podcast, but maybe, maybe not.

Carson: No, it's been good. You know, I really, so I, my experience with the community has mainly been the Discord server that Shawn invited me to join. And the first thing that I noticed is that they have a flying toaster or slack, excuse me, not discord.

The Slack. I was like, wait, there's a Discord server, not a Discord, my bad. H Jesus discord. That's, that's an easiest thing to make. Yeah. But I was on the, on the slack and I noticed there was a flying toaster's reaction. And to me that's like. Whatever anyone says about anything, it doesn't matter.

They've got a flying toaster reaction, which is from a very old screensaver on the Mac called after dark. And so, but everyone's been super friendly and you know, they're they, from what I've seen, the, the reception has been, has been good, not you. One thing I've seen in some other, particularly JavaScript oriented or heavy communities is they'll, they'll take a look at HTMX and the first time it doesn't fit with what they want.

They kind of like, ah, HTMX sucks, and they like move on. And I haven't gotten that sense at all from the Drupal community, it seems like. I don't wanna maybe a little bit more mature, but just the, like, okay, everything's got its pros and cons and ways of doing things and a willingness to, to figure it out.

I've seen that in the Drupal community, which I really like because it's like, yeah, HGM X does things this way, and, you know, so I,

John: we won you over with Flying Toasters, but Flying

Carson: Toasters. Yeah, for sure. That's the, that was the, that was the key. There we go.

Nic: So, I, I, I do wanna say though, there, so far Shawn has put in an incredible amount of work integrating even just big pipe and, and getting kind of things set up.

But, you know, Drupal, I would expect as things to move on, we'll have some, you, you should prepare yourself for some pretty complex questions because Drupal, one thing Drupal does is Drupal does things at scale, right? And at levels that you don't expect. So for example, there, there's a core issue we're working right now where.

And this is kind of to John's comment, getting off the island in where sometimes it gets us in trouble. Right there, there was a change in 10.3 that just switched to just using symphony's event dispatcher period. And it turns out most symphony sites have dozens of event events. And with the op hook conversion, we now have thousands of events and, and it just doesn't scale.

And so there's an issue to kind of pull that back and it, it fixes some performance regressions that we have. But, so I would just say like, we're still kind of just laying the groundwork. Prepare yourself, cursing. We're gonna have, we're gonna have some questions that you can hundred

Shawn: percent

Nic: just be prepared.

Shawn: What are there about 24 30 different Ajax API command classes? Nick? Something like that.

Nic: I don't even know. There's a, there's a lot. My specialty.

Shawn: Yeah. There's a list on, on the issue. For each of those Carson, we're prob we, we go to build a replacement. It's like, okay, there's this complicated thing that this was doing with jQuery, Ajax and replacement and so on and so forth.

How would you do that in, in H TM X? Now, we could figure it out right in, you know, in a, in a, in a few days or, or a week. But we figured that if we at least asked you first, you might be able to say, oh yeah, we need these four attributes. You need to do this and you'll, you'll be good.

Carson: Yeah, I, and I'm fine with that.

Like, again, HTMX is stable and it's just, it is what it is. It does what it does. And so I think that's where my effort is best placed is like, how can I help other people use HTMX as infrastructure? You know, HTMX itself is pretty low level. Like, it's very, it's like at the link and form level, you know, you're saying, okay, when this dropdown changes, I want you to issue request to this URL and replace this thing.

And so that's pretty down in the weeds. But the one, the good thing about that, it's not, there's not a lot of magic to it, I guess. And so that's good and bad. But one good thing about that is that the attributes tend to compose pretty well. And so that's where you get your power from is like the combination of, of attributes.

And so my hope is that when you know these situations come up, we're looking to replace something, it's like, okay, we're gonna have a couple elements that are gonna be powered by events, dom events that are being triggered by whatever. And. We're gonna replace this area on the screen and let's figure it out to make it work.

And I'm happy to, happy to help with that kind of stuff. So it's fun. It's, that's great. One thing about, one thing about programming with HT MX in my experience is it, there's almost a Lego like feeling with it, like you're plugging things together. And that it's, it's sort of like the old HTML world.

Like, it's like Tinker Toy, like, you know, plug these things together and like, I wanted to do that. And and so, in general, I found it to be pretty satisfying as far as like the solutions you can come up with. Sometimes you need to fall back to some more sophisticated scripting and, you know, we had to do that a little bit.

And just the first go of it with big pipes. But but I think in general, you know, it it, it again composes pretty well. And so the solutions aren't, they, they're, they're more attributes, but less work than you would expect.

Shawn: Yeah. And that de that stability makes H-T-M-X-A really good choice for us for a dependency.

Right. So we actually don't, we don't want a dependency that has a lot of churn that would create more problems for us. Yeah. Yeah.

Carson: Stability is a feature too. No new features is a feature, honestly, is

Rich: So, Shawn going back to, you know, you had talked about adding it, you know, how HT MX has been added as a dependency, and we've been talking about how HX could get replaced with HT M Max.

So one of the questions that I wanted to ask you about for our listeners is, is there an official initiative surrounding this and, and what does that look like?

Shawn: There is an initiative for, for our listeners, there's, my understanding is there's two kinds of initiatives in Drupal. I don't know about the word official.

There are, there are strategic initiatives. Which are initiatives that are anointed and started and or started by our project Lee Dre. And then there are community initiatives which come out, which bubble up out of the community. And we are a community initiative. If you go to drupal.org/community-initiatives we'll see all of them.

We're we're on that list for down under replace HX API was HTMX. And we have a pound HTMX channel in triple slack. And we have a meta issue, which I think is the issue that Carson found, where we have sort of a, a 40,000 foot plan. Well first where we talked about the idea it, it started with Alex Bronstein posting this idea.

A couple years ago of, well, what if we, what if we did this for our HX API, which I think is how I, somebody posted a link to that same link that Carson bumped into in triple Slack. That's how I found out about it. So we do have an initiative. We have two of our front end framework managers Pierre and Theor involved have the famous Nathaniel Kapo.

And and so, we have good support. And there hasn't been a lot of opportunity for outside contribution, like for multiple contributors yet. 'cause last year I built a proof of concept nod on slack and dribble org said, let's build a proof of concept. And so we did that. And so we had a working example and.

Now we're taking that working software piece by piece and bringing it over pieces at a time so we can focus intentionally on the co, on the code and the implementation and how it meshes with the rest of the system and improve it as much as possible. And then we, we, and so we're stacking it up once we have a working subsystem, then we're gonna be building out all of these operations to make it as easy as possible for your typical Drupal developer.

And all of those can happen in parallel. And so, we'll, we'll open like 25 issues, one for each, one all at once. And and there'll be room for lots of people to contribute. At the moment. We need a reviews.

Nic: Yeah. To, to jump in, because I, I think I first heard about this from that proof of concept issue, and I think I helped test it.

And, and the proof of concept, if I remember correctly, was replacing the Ajax on the. Single file import for config, import in Drupal. I don't know that I've used that feel, that option, but it was fairly, I think it was fairly isolated. Which is why you chose it? I

Shawn: chose it 'cause it was isolated and it was simple.

Nic: Yeah.

Shawn: And lots of dral developers have gone there and exported a config or imported a config, so it might feel familiar. Yep. For, for listeners less familiar, this is in the development config sync section of con of the configuration menu in the back end. Yep. There's an export tab and then there's single, and it lets you choose one, one piece of configuration and it outputs it on the screen.

Nic: Yeah. And so, so I, I, I helped test that. And then I think we've been just slowly setting up the, I I like to think of it as a foundation. You've been slowly setting up the foundation for. Replacing a lot of the implementations, right? A proof of concept is one thing, but when you actually start replacing kind of core features of Drupal, you kind have to have a good developer experience.

You have to have, think about maybe you don't solve them all yet, but you kind of have to map out all the different complexities. Right. And, and I know you you've been having some conversations with Checks who was on the show recently about some Form API stuff recently too. There, there's a lot of complexity.

I mean, you, it's a, it's a tall task. This initiative is gonna be around for a while.

Shawn: Yes. It, it is although it's an 11, a full featured subsystem is a Drupal 11.3 feature target. And I think that achieving that target is dependent upon continuing to get reviews to improve these merge requests when they're open.

So because they're sequential. You know, they're, they build, they built up. Yeah,

John: so I, I, I'm thinking back to something Carson said earlier with the he didn't, not his words mine, but stodgy JavaScript developer that's like, Hey, this doesn't do this one thing. It's a, you know, piece of crap or whatever.

And looking in the issue queue I, I, for our listeners, there's a link to the meta issue that Shawn referred to in the show notes for you, for you to click on and look through. But looking through there there was one comment that talked about HTMX only returning one element, whereas the current age, a system allows for multiple responses.

There's also a response to that comment in there with other libraries and whatnot. But I just wonder, Shawn, what's the, what's the you know, what's the, what's the argument I guess for people that might think the current Ajax system has its benefits?

Shawn: I'm sure it has its benefits, it's served.

Somebody commented that it has served us well for 15 years. But I've also had developers tell me, oh yeah, triple Ajax. I really try not to use that. Hmm. 'cause it confuses me and it's really hard to use. And I think the evidence of that in 2025 is how little our standard admin interface is, is dynamic.

John: Yeah.

Shawn: It's a reasonable amount of work to make something dynamic with the current Ajax system.

That's true. And I don't know exactly what use case, the co the, and I didn't go back and look at, I, I haven't seen that question recently. I may, I've read that whole issue before, but it's not, it doesn't, that doesn't match my experience.

Mm-hmm. Let's talk about the form and the proof of concept, the single export form. So for people who haven't used this form, it has two selectors. The first selector you choose the kind of configuration you're interested in. And the second selector dynamically updates to be a list of everything that's in that category.

John: Mm-hmm.

Shawn: And then when you choose something in that category, there's a text area that dynamically updates with the YAML for that. And so his small task, if I go back to the first selector and I change it to a different category, a different kind of con of configuration, we need to empty the text field.

Yeah. And we also need to update, update the selector that chooses which thing in that category you're gonna pick. So I have to do two things. When you change the, the, the category selector and HTMX does that HTMX has a concept of what they call an out of band swap. So, I'm, I'm giving you back the request you asked for, and I know you're gonna want this other thing, so I'm gonna mark it in the request as an additional thing to come in.

Then it has an entirely another set of control, control services that I haven't even got, I haven't had to use yet with headers on the response.

John: Mm-hmm. Or

Shawn: you can, you can actually in the response change the, change the swap and select behaviors and the target behaviors,

Other than what the person asked for.

I don't, I don't have an answer for why I would wanna do that, but having more control services. Tells me that we can con, we can do some pretty sophisticated things, but just that out of band ability. So in that, like that simple form, you change categories. We, we intentionally target the select element updated options list.

Mm-hmm. But then we send an empty text area as an out of band to, to update and just to

John: make it update. Just to go on the record there, you know, I'm not, I'm not trying to be devil's advocate here. I am fully, fully a fan of improving, improving systems and making things simpler for developers to use.

I was just curious to somebody that might have that.

Carson: Well, let me, if, if I can just, I, I, I would speak up for, and like, in support of that person. I think you guys, you know, as you're integrating HTMX, you should go slow and you should, you know, really try to match the old behavior, you know, bug for bug as best you can.

And the there's, again, there's something to be said for that stability. So I'm very sympathetic to that person's perspective on things like I, I would like to see HT mx, I view HTMX as a sort of Swiss Army knife for Hypermedia. And the way that Swiss Army knife is going to be used is going to be different for every backend system because every backend system has a way that it does things and is, and so, you know, maybe you get into using the headers.

There's another header that I think is really powerful, which is HX Trigger, which triggers an event on an element, and then you can listen for that on the client side and update things. I use that for like flashing post messages, for example. And HTM X web web apps. So, there's a lot of tools in there, but figuring out how to make those tools, you know, hopefully there's enough tool tooling and flexibility that you can adapt it to provide a, a very backwards compatible implementation.

And then also move towards this simpler sort of. Hyper media control based mechanism that I think HT MX prioritizes. So,

John: and, and, and the best part is that I hear the maintainer is pretty amenable to like feature requests and whatnot. So like, if we ever come across something and we're like, ah, it'd be good if it did this.

I'm sure we can drop something in an issue queue somewhere.

Carson: Yeah, you're gonna, you're probably gonna get a an extension script from me. I'll be like, okay, we can do that. But we're doing it as an extension. It's not going in core. Because one of the things when I built HTMX, one thing that I think I did right, there's things I did wrong, whatever.

But there's a, one of the things that I did do right, is there's a huge number of event hooks in the lifecycle and all this stuff. And so you can pretty much grab a hold of HTMX at any point and make it do whatever you want. And so that there's an extension, there's an extensions, an explicit extensions mechanism, but also the events are are pretty good and pretty powerful.

And let you, you know, reorganize your requests and all the rest of

John: it. Wait, wait a second. So we're, we're gonna, we're gonna dig into that a little bit more. We, before we continue, 'cause I'm interested now. So like in theory, Drupal, and maybe we are already doing this and you guys have already figured this out 'cause you're way smarter than me, but, hey, I'm gonna, I'm gonna say it anyway and you can tell me where I, where I, where I am here.

But like, in theory, Drupal could build its own kind of like extension library that's like, HTMX extension that basically just does all the Drupal stuff that we needed to do.

Carson: Yeah, just so for example, like if there there are values that get added to a request by Drupal on every request. I don't know if that's a thing or not, but that's a thing that does come up with some infrastructure.

Absolutely. There's an HT MX colon config event that you could listen to on the body, and then every request before it's made is gonna call that with the data, including the form data that it's planning on submitting to the server, you can add or remove things or whatever you need to do. Hmm. So that's a really simple example of a way that you might use events to configure HTMX to work better with a particular backend system.

It's got this sort of, and we're

Shawn: exactly doing that in our initial implementation with the dependency. Yeah. In 11.2 there's the library and there's asset processing. So Drupal already had an Ajax page state parameter that it, that encodes what CSS JavaScript libraries are deployed. And it uses that to create a diff on its response to only give you the new stuff.

John: Yeah.

Shawn: And and that wasn't tied. That happens even on HTML responses, which is what we're making. So we actually did that, John, we, we, we tell Drupal, here's the Ajas page state, we configure a couple other things and then we're able to return only the things that you need.

John: Yeah. Now it

Shawn: was already built into dral.

Drupal was built, anticipating that it might use something else someday in the HTML response subscriber.

Nic: Hmm. And, and what does the upgrade path look like for people writing their own forms? Like, are, are we planning to use the same form render keys and that kind of stuff? Or is it gonna be like, Hey, when you're ready to move it, you gotta implement something new?

Shawn: Well, we haven't. We have that issue proposed. Nothing's done. So I'll tell you what we're proposing and we'll see what the, what the core committer developer community comes up with. I'm, we currently, if you're gone and put Ajax on something in a render array, we have a pound Ajax key and you'll put in various things.

I'm proposing a pound HTMX key. That points at an HTMX object, an an instance of a class that implements the facade pattern to be technical for a moment. That hides the complexity of the, of how everything gets configured under the hood so that a typical Drupal developer would do something like PAL HTMX and point to an HTMX object into which they drop some of these operation classes where they're, where they're saying what they wanna, I wanna to replace I wanna do this, I wanna do that.

And those things get. Those things will configure things behind the scene for you. So this, I don't know, I I wouldn't call it an upgrade path. It's gonna be a parallel system.

John: Okay.

Shawn: I haven't done any work I haven't done anything like the work you've done Nick with rector conversions for all of the hook stuff that you just did.

And you know, in Ajax you have to have your, your outputs getting created in a callback function. It's not getting created in the, in the standard render process, HTMX, speech, HTML. So you should just be rebuilding or, or calling a route that's building HTML. And so, I don't know I don't know how to, how to automate the conversion.

I suspect it's gonna have to be just refactored, but maybe there's a way to do this. With the Rector tool, and you and I can sit and talk about that sometime, but at the moment I'm just building a parallel system and then we'll figure out if we can automate the, the replacement of it or if it has to be handled

Carson: one, one.

Can I Sure. Space interject. I one one definitely of, of vibe of HCMX is. Use a little bit of HT MX first. So I think if you could make it such that users can sprinkle, like that's a, I don't know why that verb keeps coming up, but sprinkle a little bit of HT mx on their gen or excuse me, on their group of websites and get some dynamic behavior out of it.

I like that because it de-risks everything so much and you can often get. Big wins for relatively small amounts of code. And to me that's often, that's the trade. Like that's the best trade off. Like we don't need to make everything HT mx, we have two or three aspects of our website that need like, you know, like wouldn't it be cool if this was active search?

Like this is the search on our website. Okay, let's make it active search. And that's like three or four attributes or whatever. And then something that's a big UX win for very little complexity. And I think a lot of people can just stop there, like, don't make everything HT MX just 'cause HTM X has like a funny meme account on Twitter or whatever.

Like, it's like, it's all good and fun and I, I, you know, obviously I like HT mx, but I also think that there's an 80 20 rule for lot of this stuff. And so as much as it can be set up that people. And Drupal community can sprinkle it and try it out. You know, I often say try it out on like a backend page or on a page that's maybe not as important to your users and see how it goes.

And then, okay, now maybe you can dive into a little bit more and then maybe only use it for the really important interactions. You can keep the old web 1.0 interactions for the stuff that just isn't as important, and you don't need that complexity. Like, it's, it's, you gotta

Shawn: That's a great idea, Carson.

And I'll say if you're, if you're running triple 11.2, you can do that today.

John: Okay.

Shawn: I'll say that again. You can do that today. Perfect. 'cause 11.2 ships with HTMX and H-H-T-M-X speaks attributes. So if you're a Drupal developer who knows how to put attributes by hand, either into your render array or into your twig template we have the asset processing of loading the CSS and JavaScript that you need from the request.

That also shipped to 11.2. So you could go hand write HTMX attributes, you have to go look at the HT MX website, at the documentation, also linked to your show notes and figure out how, how to do what you need to do. But we're trying to add in as a subsystem is for people who don't wanna do that, they just wanna, they just wanna replace a thing.

John: Right.

Shawn: But you could frankle to use your words in the

Nic: current version of

Shawn: Drupal.

Nic: So, cool. I I just wanna chime in though. That's something I'm real, I was realizing a few minutes ago when I was asking about the developer experience is that that's very different than the current Ajax system, right? The current Ajax system requires you to do something in PHP necess.

Like there's no way to like interact with Drupal Ajax without writing PHP somewhere, but with HT MX, even if you like, yeah, you probably need some sort of route or something to return the HTMLs, which requires. But I mean, you, you need to have something returning to HTML that you wanna return. Right? Right.

But a front end developer, as long as that stuff exists, a front end developer today can now just hand put, and this isn't the best practice. Right? Caveat, caveat, caveat. You can, you can just hand put it in the twig and it will work. And so they can test something. You know, they don't have to, they don't have to learn how to get into a form render array and figure out what the special key is and how to get the call back in there.

Like they can just put an attribute somewhere and it will work. And if they have experience, one of the things I really like about this too is if they have the experience that the HT MX elsewhere, that experience will translate here too.

Shawn: Yes. Now I'll step out of my core hat. If you wanna play other way to play with HT mx and today is the h TMX contrib module that I also maintain.

Got add the library. It has an attribute builder similar to what. The core implementation's inspired for all of our experience in that trip module. Working on two things at once, it's hard to hold in my head. We we're, we do have an attribute, a twig function and the MR we're working on right now.

And as I recall, I already have that twig function in the, in a contrib module. It's a twig. It's a twig function. So if you're just working in twig template, you could build attributes using that. Yep. And then call merge on your, on your original attribute object. So there's two ways to play with HTMX and now Yep.

Rich: Okay. So, I, I had a question. So Carson, earlier you had mentioned that big Pipe has a adopted HTMX. So you kind of referred that to that briefly, and I wanted to dig into that a little bit and find out more about, like, did that have anything to do with this move, like this bigger move of, you know, replacing the Ajax system with HTMX?

Carson: My understanding, and again, as an outsider is that it was a first step. It was an area that would be a clean place to integrate it. And so I would ask, actually, I think Shawn, you did the work on this. Correct. And so I,

Shawn: well, I did it in concert with triple users catch and not underscore.

Yeah. I think, I think the purpose of that work at this point, rich, was to answer the question, can we deprecate the Ajax API?

John: Mm.

Shawn: I knew. All I knew before about Big Pipe before we worked on this issue was that it worked. And I thought, I thought it was based on Ajax and it's not. In terms of its request architecture, it, it, it piggybacks on the main requests before the request closes, but it, it uses the Ajax API that we have to structure what it's sending to the, the client.

And then it uses the Ajax API's, JavaScript to get things into the right place. And big pipe is used way more than just regular Ajax and Drupal. It's used everywhere. So if we can't make that work, we can't duplicate the Ajax API.

Nic: And you made it work.

Shawn: We made it work halfway,

Nic: halfway.

Shawn: We worked on the front end to get rid of the Drupal Ajax JavaScript.

Yeah. I mean, and halfway is better than No Way, right? Oh yeah. But we have a second issue. It was just too much to do on one pr.

John: Mm-hmm. Bottom.

Shawn: We had a working example that was all, all HTMX and all HTML, but it ran, it tripped over what happens with messages. I can talk, I can talk about that in a moment.

But so what we implemented was a small set of JavaScript that only did the things from the Ajax API, that big pipe needs. There's only three, and it did it with a, which with the small API that HTMX provides. So you normally deal with HTMX and attributes. We've talked about that a lot, but there are, but the HTMX JavaScript object does exist when it's loaded and it has a few methods including swap, to move something from one point to another.

So what we did, so what we did in this issue was we, we changed this will warm your heart card. So we stopped sending JSON and we, and we switched to sending, sending HTML.

John: Yeah

Shawn: We, we take the rendered output from Drupal and we wrap it in a template tag. And, and that gets added and that gets added onto the end of the dom.

And we tried playing with the with the event system and, and just reacting to to an on load event too. Slow big pipe today uses a mutation observer, which we kept at, and it, so it notices the mutation. It's tech, it, it gets this template, it gets it N-H-T-M-L, and then it says to HTMX, here's this N-H-T-M-L, here's where it's supposed to go.

And we don't have to write any of that code. 'Cause the swapping is already built in. So that's what we did and it decoupled the front end from Ajax API. We have a second issue to get rid of the Ajax API classes on the PHP end. 'cause we're still using that to structure. The, the data. Lemme say that I'll, I'm gonna say that slightly different way.

Your, oh, Nick, the template wrapping html.

John: Yeah,

Shawn: that's gonna come an issue number two. We, we got that far. We got it working, but what we shifted was just, we, we left the PHP class alone for the most part. We're still staying the js ON today. But we're de, we're decoding it with our small bit of JavaScript, and then we're using HTMX for the swab.

And then the future issue, there'll be template tags, wrapping HTML moving it into place. But we have to fix some things with messages first. So.

John: It's, it, it sounds very workable. It sounds very, very possible. Man, this next question, I am definitely gonna sound like a naysayer again, so I apologize. But symphony, which Drupal uses pretty, pretty heavily, right?

Implemented the hot wire turbo library, which sounds both frightening and very, very cool. I don't know why. Instead of HTMX as part of their kind of UX initiative, right? Is there a reason to be concerned about the difference in approach? Carson, I'm gonna direct this question to you first as to why you think they may have, may have made that choice.

And then Shawn, I, I'll look for you to kind of, from the Drupal side of things answer whether we should be concerned.

Carson: You know, I, I'm not, I'm not gonna say anything bad about Hotwire. I think it's a great library. I think it's a little more. High level, there's a little bit more magic to it than HTMX.

HTMX is very low level. Like, you know, again, it focuses really on this idea of generalizing hypermedia controls. So an event causes a request, produces HTML, and I stick it somewhere in the DOM and all that stuff's right there and in your face you with HTMX. So, but I think Hotwire is a great library.

And so I, you know, I understand why people might pick one versus another. 37 signals. The Ruby on Rails company has a lot of resources. They have very polished software, so I don't begrudge anyone picking them over H TM X. I think the ideas, I've said this before, I think the ideas of HTMX are more important than HTMX itself.

The idea that hypermedia and that tools that produce hypermedia, like Drupal, like rails, like Django, like they can be, they can produce very interactive. Web experiences using the Hypermedia model. And so, you know, I, I think some people like the HT MX sort of low level stuff, I think it can be better.

There's a little bit more of a combinatorial power to be gained by that low level. But the

John: simplicity, I mean the simplicity of HT MX makes a lot of sense to me. Right. Right. Like, we don't, we don't need to, we don't need to come in with a sledgehammer when an a hammer will do. Right. Right. And I think, and I think for like, you know, we, we, in the, you know, we, we talk about in the dral community, smaller core, right.

And I feel like, you know, Ajax is great. I love it. But like we could get to a smaller core with HTMX and still have the same amount of whizzbang sort of stuff that we have today.

Carson: Right. Yeah, and I just, again, I think, you know, when people ask me to contrast the two, I just think HTM X is lower level, it's very focused on this idea.

Yeah. Of generalizing ht ML and less on providing sort of a framework. And so there are advantages and disadvantages to that. Like you have to do a lot more, or not, maybe not a lot more, but you have to do more when you use HTM X because it's just lower level. You have to be more explicit about stuff.

Nic: Yeah. Mm-hmm. Also, just really briefly, 'cause we gotta, we gotta move to close, but really briefly, it's a bundle which means that you're really kind of expected to use the full symphony framework, which, which we don't do in Dral. To be clear. We use different components here and there. We use different pieces, but Drupal is not a symphony project.

Drupal leverages pieces of Symphony and so Turbo kind of expects you're using kind of the full symphony package, I think under the hood.

Carson: That's a, a philosophy of HTMX is that it's very standalone. So it's, it's a, it's a single file. You can drop it in, you can use it for as little or as much as you like.

It's gonna make no demands on you. Beyond that, you produce HTML in responses and beyond that, you know, it uses events so you're not wiring, hopefully in most cases, you're not wiring, wiring directly into the HTM X object. You're using events. And so you're, it's decoupled in that sense. It tries to just, you know, play with the web platform the way it was sort of designed to work and be as independent, but as useful as possible.

So that's my sales pitch, I guess, for you.

Nic: So Shawn I appreciate that by the way, Kirsten, and I mean, I think that's one of the reasons why, why the, the request to put it into core was accepted. But Shawn, really briefly, the million dollar question, how can people get involved if they're interested in this?

Shawn: That's a great question. Thank you for that. Opening Nick there's an issue on drupal.org linked in the show notes. You can come to Drupal Slack and join the HTMX channel. You can go to the Drupal issue queue and search for HTMX initiative and you'll find all of our tag issues whatever, whatever door you wanna come in by to join the effort.

Just come, come help at the moment because we're moving, working, essentially working software through a path of improvement for core from the POC or the module. What we really need are testing and code reviews. And and so when you see an issue that's needs review if you have time, please do that because almost every issue we have that needs review right now is a blocking issue.

We can't continue to build a subsystem till that's committed 'cause we're gonna build something that uses it. We have biweekly coordination meetings in our Slack channel. And when we get to operations we're gonna have a lot of parallel work and please jump in and make an operation and make a polar cost.

John: Awesome. Well, Shawn, thank you for joining us and Carson, earlier you said you were an outsider, but you've just completed your first Drupal podcast. So I would say, you know, welcome to the island and we're happy, we're happy to have you. Thank you. Thanks for joining us today.

Carson: Sure, absolutely.

Happy to talk to anybody. Always happy to talk about HG Mx and help as much as I can.

John: Perfect.

Nic: Do you have questions or feedback? You can reach out to talking Drupal on the socials with the Handle Pack and Drupal, or by email or [email protected]. You can connect with our host and other listeners on the Drupal Slack in the Talking Drupal channel,

John: just like the New England Drupal Camp did today.

You can promote your Drupal community event on talking Drupal. Learn [email protected] slash td promo.

Nic: And you can get the Talking Drupal newsletter to learn more about our guest host, show news, upcoming shows, and much more, sign up for the [email protected] slash newsletter.

John: Thank you patrons for supporting talking Drupal.

Your support is greatly appreciated. You can learn more about becoming a [email protected] and choosing to become a patron button in the sidebar. All right, everyone, we've reached that point in our show where you can shamelessly self-promote yourself, talk about how folks can contact you and, and really anything else.

Shawn, if folks wanted to get ahold of you, how could they go best about doing that?

Shawn: Well, my contact forms open on triple.org and then triple slack. I'm Father Shawn on both places. I am on Mastodon, although I don't tune in all that often. But I'm also in Drupal community. There. There you go. Carson,

John: what about you?

Carson: Well, I got a book called Hypermedia Systems that you can [email protected]. It's it's written in Python, so I apologize for that, but I thought that was the widest, most widely known programming language. But it talks the first, it's a, it's split into thirds. And the first third in particular might be interesting for listeners because it's sort of a historical look at how the web worked and like, sort of what a web 1.0 application looked like and so forth.

And then the middle chunk is sort of how to use HTMX and sprinkle it and improve that web app. So that might be useful for people. I also wrote a funny website called Drug brainin.dev which is a funny read for your listeners. There's a, there's a book, a hard copy book version of it. They really like it.

And then finally, I regret to say I'm still on X or Twitter as it should be called twitter.com. At twitter do com slash htmx.org. And I post a lot of silly content there. I'm a very boring person, but my Twitter account makes me seem very very exciting. So

John: I feel like our listeners would disagree with that, but we can, we can create that on an, on another show.

Sure. Rich, if folks wanted to get ahold of you, how could they go about doing that?

Rich: Yeah. I'm RK Lawson on Drupal Slack. You can also reach out to me on LinkedIn and or go to Rich lawson.co. And to learn more about Evolving Web, you can go to evolving web.com.

John: Wonderful. Nick, what about you?

Nic: You can find me pretty much everywhere at Nick's van, N-I-C-X-V-A-N,

John: and I'm John Picozzi.

You can find me [email protected]. You can find me on drupal.org in the socials at John Zi, and you can find out about EPAM at epam.com.

Nic: If you've enjoyed listening, we've enjoyed talking. See you

John: have a good one, everyone.