Building a framework on top of htmx (Sprig) - with htmx contributor Ben Croker
Before we get into it, do you I know I I love listening to 2 of your episodes. Do you have anything like specific that you want to direction that you want to go into or is it open?
Lazarus:You're right. I mean, you know, so it's all sort of I'm trying to keep it focused in general around h t m x and kind of hypermedia stuff, but, you know, with you specifically, I wrote down a couple notes of just, you know, you you work on the Sprig plugin, and mainly, sort of contributing to HTMX. You mentioned that you you've, you know, worked on contributed to the actual repo. Mhmm. So I just think that's interesting and, like, you know, there's probably people out there who would be curious how that works and, like, that kind of stuff.
Lazarus:So I mean, that's, you know but really it's like pretty free form. This is, you know, I'm doing this season on sort of conversations. So it's kind of up to you, you know, if you if there's certain things, like, you wanna talk about, you know, I'd like, you know, generally keep it somewhat in the HTMLX realm, but you heard the other stuff, not necessarily. So.
Ben:Yeah. No. For sure. I'm aware that we're here to talk about HTMLX. I think there's some things in terms of Sprigg that are interesting that I don't think you've talked about before which is that, we'll get into it but just briefly, that Sprig sees like Sprig is a framework that builds on top of HTML.
Ben:So it sees HTML as a library that facilitates a lot of its functionality and features which is really cool. And my contributions tend to be in the direction of how we how can we make HDMX a better library in that sense rather than trying to add kind of developer facing bells and whistles even though I'm using it as a developer, but I think you know what I mean.
Lazarus:Yeah. So okay.
Ben:We can get into all of that. But, yes, I definitely plan on keeping it HDMX focused.
Lazarus:Alright. So, I am joined today, by Ben Croker. And we we've sort of been talking about people who are working with h t m x on a on a regular basis and who are building tools around it. So first of all, just welcome, Ben. And thank thank you very much for joining.
Lazarus:Thanks for making the time.
Ben:Sure thing. Thank you, Lazarus.
Lazarus:Yeah. So so, you know, one of the main projects that you've been working on and and kind of using h t m x is, you mentioned it was something called sprig which is for craft c m s. Right? This is a plugin?
Ben:This is a plugin for craft c m s which is a content management system, built on top of PHP. It's a self hosted management system. And Sprig is an open source free plugin that you can use, that adds front end functionality.
Lazarus:Yep. Okay. So so maybe I'll back up a little bit. So are you a PHP developer in general? Like what's your sort of development history a little bit?
Ben:I did a BSC in Computer Science, but very quickly realized that, you know, working on the web is what I want to do. So very quickly pivoted into PHP and, you know, everything that comes along with front end as well, including JavaScript. But, from the very beginning, PHP appeal to me simply because it's widespread adoption and use and how easy it was to get set up and and running, you know, back in the day. And the language has evolved a lot, but, yeah, I I pretty much consider myself a back end developer primarily.
Lazarus:Right. It seems like there's been an appeal in general for, people who are using HTMLX kind of starting from the back end and and kind of expanding their powers out from that direction. That kinda makes sense.
Ben:I still see JavaScript very much as a scripting language even though it has evolved into a proper program language. I came from that era of, you know, PHP was a programming language and JavaScript is just some scripting that you can add to the front end to make things more interactive. That's still kind of the approach I I tend to take.
Lazarus:Yeah. I mean, it's a mental model that is pretty straightforward and I think, you know, when you start getting into, some of the other like sort of a general SPA mental model, it's pretty different from that. And so maybe this is kind of a big, you know, people are kind of coming at it from very different angles. But I'm sort of in the same boat, you know. It's like when you're starting from the server side, and just kind of at first you just do things in a really basic way and then, you know, JavaScript helps you kind of build on that and, you know, add stuff to your basic things.
Lazarus:And and I've kinda gone the other direction as well where I started doing a bunch of JavaScript, and now I'm going back to starting from the back end again, but doing much more powerful things because there's better tools now.
Ben:Yeah. And this is probably I'm sure you're familiar with, you know, progressive enhancement where the ideas that you start off with the most basic tools of the web which is HTML and then CSS, and you add JavaScript incrementally rather than, you know, basing your whole application around JavaScript. And while I feel like the web has moved on and technology has moved on in many ways so that JavaScript is completely ubiquitous. I don't expect people to be browsing the web without JavaScript enabled. I still think of it as an additive technology on top of the the basics that we lay down being HTML and, Markup.
Lazarus:Yeah. I remember one time I was, you know, looking into Richard Stallman. Have you have you have you Mhmm. Sort of come across him along the ways and, you know, it was he's like this very sort of like bare bones, you know, the website basically should work without JavaScript at all. And it's like nowadays that just does seem a little ridiculous.
Lazarus:But at the time I was like, oh, very you know, this is very interesting. I wonder if this could work. And, you know, it just so happened he lived in the same city that I did. And I looked him up, I emailed him, and he was like, I'm working downtown. I worked downtown at the time in the same city.
Lazarus:So we met up for lunch and I was like, and he was talking about, these websites and, you know, his thing was like, you shouldn't have to run anything on. It was like so far beyond my level of like extreme on like JavaScript. It was like your computer should never run JavaScript, like it shouldn't run anything that's not, you know, something you own on your computer. And I was like, oh, this guy's super smart but he's way he's like a a developer extremist in a way that I may never be. So Yeah.
Lazarus:But now I can't, you know, I I think, the progressive web stuff, like, you know, I think of that in terms of just building stuff especially with forms and submissions, like, if you can just do it in a really straightforward way, why not start there and then, you know, make it better and better kind of thing? So so you started, you know, generally with PHP and, is you do you work for a company now or do you sort of do your own your own work?
Ben:No. I have my own business. I produce, both commercial and free plugins for Craft CMS. That's my main thing. And I also provide training for developers and teams of developers.
Ben:And Sprig is an open source free project, but I do provide training on the side for that as well. Like, I've I've tried to make it so that all of the learning resources are free and, up to date and current and, you know, just freely available to everybody. I feel kinda like h t m x. I feel like, docs are so important, but maybe even more important than the docs or just as important as the docs are showing people how to use it. So I have, like, a section for, like a cookbook recipes thing, similar to how h t m x has it with different examples that are perhaps more applicable to Craft CMS.
Ben:But I think giving people examples like and not abstract examples like real world examples of, like, you could copy paste this into your application, style it a little bit, and you're good to go or in this case into your craft website.
Lazarus:Yeah.
Ben:But I do provide training for that as well which brings in some income and helps fund, you know, well, partially helps fund the the whole thing. It's pretty much an open source product project that is funded by the commercial side of my business.
Lazarus:Gotcha. Now I think that's a really I mean, I that model for learning of just showing examples and, you know, if you're looking to get more people into it, having it be free to, you know, to at least to learn and like, I don't know, you always, you you kind of hope that someone can make that business model work and I've definitely seen it work. So I think it's good, like, to, you know, adding on the support and the personal touch where you can go and train them yourself. Like, that's just like a win win, I feel like, for everybody. Or it's like they can get, you know, as far as they need to, through the examples, but then, you know, if they if they want that help, they can get that extra help.
Lazarus:I like that model a lot.
Ben:Yeah. I've seen over the years lots of wonderful open source projects just really struggle because there's no financial backing. And the more popular they get, the more support requirements are needed, or just maintenance in general. And how do you fill that need if there's, like, you know, people's time is precious and, you know, they have to they have to, you know, make a living somehow. So how so there's always gonna be that battle between, you know, wanting to work on this open source project versus having to actually do paid work.
Ben:So, yeah. I feel like I've managed to strike a good balance here where there is the commercial side of the business, that funds the open source stuff which also brings interest into, you know, the other products that I create as well. And it's it's worked out really well.
Lazarus:Yeah. Nice. And ultimately it's help, you know, it's important that the open source slash, you know, your educational stuff around it makes money eventually for somebody. You know, it's like that's important for the community, like, because that's what gets it to that next level of, like, you know, then you can invest more time or, you know, whoever's doing it. So, you know, I don't know how much money is made on HTMX right now, but I think in the future it will be important for somebody to be making money on it for it to, like, go to the next level.
Lazarus:You know what I mean?
Ben:Yeah.
Lazarus:Well, okay. So you let let me just, you mentioned in just kind of talking about about your craft CMS plugin, you know, about Sprague, that it was you sort of considered it like a Livewire type experience, you know, but specific to Craft CMS. Does that how do you how do you sort of think of it like Livewire?
Ben:Yeah. Very much inspired by Livewire and also, an older project Phoenix Liveview, which is a little bit different but same idea. And I saw websites like GitHub that still use this pattern, right, of, I think they were using pjax. I'm not sure what they're using now, but still following that same pattern pattern of sending HTML over the wire. And I thought, wouldn't this be wonderful to have in craft because I was building a lot of, well, I guess the idea for Sprague was I guess there are 2 parts to it.
Ben:One was I was seeing these other reactive frameworks and there was kind of a a movement towards Vue JS at the time which was getting popular and I used it a few times. And I I thought this looks interesting, but I just wasn't such a fan of it. And I thought, wouldn't this be great if you could if you could get the benefits of or some of the benefits that Vue JS and React offer, but be able to stay in your kind of, templating language of choice. And for Laravel Livewire, it's blade templates which I think you can which I think is PHP with a few special tags. And for craft CMS, we use Twig which is a templating language.
Ben:So, made by Symphony.
Lazarus:Hence Sprig. Okay.
Ben:Hence Sprig. Yes.
Lazarus:Yeah. Yeah.
Ben:I have Andrew Welsh to thank my friend, for the wonderful name. But, Twig is the templating language. So it's a so Sprague is a kin to LiveWire in that it sits between, the framework which in the case of LiveWire would be Laravel and the front end. Now what's a little bit different between, besides the obvious, between Spring and Livewire is that from the onset I decided I want to my experience and my joy comes from working on the back end. So I wanted to create a plugin that would handle the kind of back end side of things or you could even say the middle where I guess it's a mental model between craft and the front end.
Ben:And hence, I needed something on the front end. I didn't want to build that part out whereas Livewire covers that entire spectrum of front end to back end. So there's like this JavaScript component to to to use that term. There's the the JavaScript aspect of LiveWire and then there's the the PHP aspect of it. And it kind of, you know, comes together in this one package.
Ben:Whereas with Sprig, Sprig is purely the PHP side of things. So I was, I was exploring libraries at the time. This is like 4 years ago or so maybe, yeah, probably close to 5. I was exploring front end libraries that I could use together with this idea I had which was to be named Sprague, but at the time didn't really have a name. I saw OnPoly, which you may have heard of.
Ben:It's similar ish to to h t m x. I came across cross h t m x as well and it was at version 0.03. And I took one look at that version number and I was like, no, no, no, I'm staying away like especially like any anything JavaScript like, things just come and go so fast. I was like, if this is just, you know, this has just been some madman's idea.
Lazarus:Which is not to say that it's not, but anyway. Yeah.
Ben:It's not too far from the truth as it turns out. But, but at the time I just looked at that version number and I said, no way. I'm not gonna put anything in production that has a dependency on the JavaScript libraries that said version 0.03.
Lazarus:Yeah.
Ben:I got I'm used to, you know, you put into production at version 1 and then at version 2, it's like, it's actually stable kinda thing.
Lazarus:Right.
Ben:So, I just skipped past it, and I just kept looking and I don't know, a couple of weeks, maybe a month or 2 later, somebody mentioned it to me because I was talking to some people and I said that I was looking for this thing. Someone mentioned HTMLX. So I went back and looked at it, and then I realized at that point that it was the successor of Intercooler and I had been familiar with Intercooler. I just hadn't realized that it was kind of an intercooler version 2. So that point I looked at it seriously and started playing around with it.
Ben:And the first thing I did was I created a h t m x plugin for Craft CMS and I thought it would be that. I thought the plugin that I wanted was just going to be an interface between HTMx, the library and Craft CMS. And then I realized that's not really that helpful because why do you need a plugin for that? I realized that what I actually wanted was something different. I wanted a way to have reactive components like you do in languages or frameworks like React and Vue JS.
Ben:So I wanted this component system that you can easily make reactive. And so I created this other type of plugin that enables that using the Twig templating language which is what Craft CMS uses. And then, I built the plugin on top of the features that HTMLX provides. So to get a little bit technical
Lazarus:Interesting. Perhaps. Oh, definitely. I I I'm very curious actually the the details of of how this is working.
Ben:So normally speaking, when you're using HTMLX directly, you will say h x get equals and you will pass in the URL. And then when you interact with, let's say a button or whatever it is on the page, HTMLX will reach out to that URL. Fetch the response which is HTML and swap it into the DOM. And of course, you can configure the swapping behavior. What Sprig does is it actually always uses its own endpoint.
Ben:So you will never actually hit a URL that is, like that is a template or that is something that is gonna that is the points to a file. You're always gonna hit the Sprig controller action, and instead, you pass in well, Sprig will already parse these, your templates for you and Sprig will insert the hx get and pass in its own controller endpoint. So you hit Sprig, h t m x, you know, sends that Ajax request off to Sprig and says, this is the template I want. And then Sprig will parse the template which is a Twig template on the back end, and send the result, the HTML back to, h t m x which swaps the result in. And the powerful thing here is that I was able to base components around Twig templates.
Ben:So rather than just, swapping out the value of a button which you almost never do, right? You swap out, you set the target to something else, right? Let's say you have a load more button. You don't just, you know, return a bunch of articles and swap those into load more button. I mean, you can do that too but generally like I think it does by default.
Ben:It does by default.
Lazarus:If you don't want them.
Ben:You end up having to do a lot of configuration. With Sprig, you essentially have a tweak template and that's your component. It's like a self contained reactive component that is then rendered on the front end and the entire component gets swapped out each time you interact with that page. And of course, you can configure the target and what you want to select and all of those things. So in terms of the front end and I made a point of this, because I was tempted many times to write a h t m x extension, you know, that would be that Sprig would use because h t m x is extensible out of the box.
Ben:It's wonderful in that sense. But I was like, let's see how far I can get just using HTML as a library. So I always thought of it as okay, Sprig has one dependency. Well, besides the obvious Craft CMS, but it has like one dependency of its own which is HTML. And let's see how far I can get using HTML out of the box without, without modifying it or without adding an extension.
Ben:And it's 4 years later, Sprig is at version 3, the major version, and I haven't had to ever write an extension. Now, I have contributed some features to HTMLs, that I I would like to think have made it better, but they certainly have made it easier for me to to achieve that using Sprig. So I've been contributing to since version 0.03 from the very beginning and I've had, many conversations with Carson. We actually had Carson on a a podcast. I think it was one of the first ones he was on to talk about HDMX.
Ben:Devmode.fm, if anyone's interested. And that's kind of a craft CMS focused website, but it's it's well, I think it calls itself, web development or modern web development podcast, but, many of the topics are craft CMS.
Lazarus:Yeah.
Ben:So we talked about HDMx way back then. And I've been contributing ever since, I would say like I I think I'm one of the top contributors after Carson. Most of my contributions are small like like I do a lot of typo fixing and explaining things better in the docs, but also small features to just, remove some of the friction and make make HTMLX in the way that I use it for Sprague much easier which is that I think of HTMLX as the library and I build the frame framework on top of that. So that people who use Sprig are aware that they're using HTMLX because I'm very clear about that. And, you know, if you want to get into the more advanced techniques of using Sprig, I send people to the h t m x docs.
Ben:And so I don't want to just replicate those. But at the same time, I'm able to give sprig users a much more familiar API to use rather than the kind of what I would consider the lower level, API that HDMX provides in terms of the attributes and responses and all of that.
Lazarus:Yeah. So so actually I I do wanna get into the, contributing, but, in a little bit. But first I I'm just like I'm fascinated by this, like, this really does sound like Livewire to me. You know, I, I, so I use Livewire is kind of what I started with. I just, I was using Laravel and I was using Vue JS also and I just was so unhappy with Vue JS.
Lazarus:Over the long term. I started off fine and excited about it. You know, this is great and wonderful. I can do these front end things. Now when I have to go back and support some of the apps that I built with Vue JS, I'm just like, I'm just mad at myself about it.
Ben:You're probably like 3 versions behind and you can't do anything until
Lazarus:you update. Well, I don't even bother to update anymore because I've I I updated 1 and I was just like, okay, I'm never doing that again because Vue has changed so much. So now I just work with whatever view was at the time and I try to make it work. And so anyway, but I really don't. I'm trying to move away from view wherever possible and rewriting things actually in htmx.
Lazarus:But I moved to Livewire and that was kind of my first big kind of, you know, hypermedia style passing html. And and I love Livewire still, you know. I think it's it's there's some it's just great, like, it's such a interesting way. And and I think right now the two big things when I when I decide between an h t m x, building an h t m x and building in Livewire right now, One of the things that will stop me from using h t m x is, you know, depends, especially if it's if it's a just a component, if it feels like a single, I don't know, you used to call them widgets or something. If it feels like a single component within a bigger site, I might go for livewire, because when I think about using h tmx, I I know that there's gonna be a bunch of routes, and I'm gonna be building routes, and I'm gonna be having, you know, routes for different things, and then there's gonna be a controller, you know, there's this is very standard, very, you know, I'm fine with all these things, but I do have to kind of, put code in a lot of different places on the back end.
Lazarus:You know, it has nothing to do with h t m x. The h t m x stuff is fine. It's it goes right in, you know, the templates. That's easy. But for each endpoint you have to create that endpoint, you have to then route it to the right place.
Lazarus:So when I use Livewire, you know, it does what sounds like what you're talking about, you know, with Sprig, where it creates, you know, you add the Livewire plugin, pull in the repo, it creates a on the back end a single point of entry for all of your end points. So you just you're making a Livewire request, you're not creating a new route for how that request is handled, livewire is already sort of taking that, it has a centralized component for each, you know, each livewire component has its own kind of, you know, starting div tag, ending div tag, everything that happens within that is gonna be sent to that Livewire central area, and so you don't have to think about, you know, where your routes are going and which snippets are being returned by which routes and all this kind of thing. So, you know, I does that does that I mean, it sounds really like you have and LiveWire is a complex project and I've been following, you know, Caleb Porzio who's been creating it for years watching him build it in kind of amazement. So it's not but it does sound I mean, this sounds pretty similar, right, to to the way that Sprig is functioning?
Ben:Sprig is very similar in terms of the high level mechanics to LiveWire. And I I follow Caleb Porzo as well. I listen to his podcast, or several of them. And I enjoy I enjoy partaking in his journey. It's it's really fun that he podcasts and shares so much in public.
Ben:So yes, like I think if you came if you have a background in LiveWire and you came to Sprig, it would feel very familiar to you because the way the things are working are very similar. One significant difference I would say is that, well, thing things have changed a bit in LiveWire land I believe. They they seem to every every LiveWire version seems to be a complete rewrite. So no wonder Caleb is so busy, but in LiveWire you have when you create a new component, it used to be at least that you would have a PHP file that represents that component and then you would also have a blade, template that represents that components. You'd have 2 aspects to it.
Ben:I know that now there's I think they call it Laravel Vault or something that allows you to put those two things into one blade template, and kinda mix and match PHP with blade. But, so one difference between that between Livewire and Sprig is that with Sprig, you can do it all with your Twig templates. So you can just say this Twig template is a component, a sprig component and that template immediately just becomes reactive, based on the tags that you put in it. That PHP component to it is not required but it is also available. So it is possible to have a sprig component be either based on a pure Twig template or on a PHP class, which may or may not have a Twig template associated with it.
Ben:And the reason I thought that was important to to to offer from the very beginning is that people working with Craft CMS, well, they they vary widely. But because it's a content management system, many people have more of a kind of designer developer background where they're less familiar with programming and they're kinda more familiar with putting the pieces together and building a content model and, you know, investing in the design and the front end and connecting that to the CMS itself. But perhaps, shy when it comes to actual coding in PHP. So while it's there and it's, available to you, there's no necessity to even touch PHP when you're working with Sprit. And that's one distinguishing factor I would say between it and Livewire.
Ben:And that's fine because Livewire is like when you're working with Livewire, then you're working with Laravel. So you're working directly with the PHP framework that is Laravel. Whereas with Craft CMS, it is optional whether you're actually opening up PHP files and modifying them. You really only need to do that when you're doing configuration or when you're building custom plugins for Craft itself.
Lazarus:Yep. So do you feel like I mean this this like sort of it feels almost like it could be outside of Craft CMS also. Like, you know, maybe maybe because it's already because there's already a Livewire this doesn't make sense. But I mean just like what you're talking about, a kind of templating language that is built on top of h t m x and kind of wraps it, I mean is this something that could be out of Craft CMS or is this something that is kind of you feel like it's so tied to it that that's where you always want it and the plugin is kind of the home for it?
Ben:Well, since I released Sprig, there has been a project It's called I think it's called Symphony UX Live Components. I'm just I just searched for it and there's a few different results. And the goal of that project is to create a framework similar to Livewire or Sprague but it it it is a middleware perhaps between Twig and Symphony. So Or is it just Twig, I'm not even sure exactly. I looked at it, I think it's still in beta and it has been for a while.
Ben:So it's a similar project and it's kind of something like HTMLX with the ability to talk to Twig. So in some ways, I guess it's sort it's akin to LiveWire. And that would have been an option had it been stable back then and I don't know if it's stable yet. I haven't looked at it in a while. But even if you had that, even if you had something that was able to kind of be an interface between the front end and whatever your templating languages on the back end, Sprig Sprig goes a step further and Sprig actually adds a bunch of conveniences directly for Craft CMS.
Ben:So there are things, I think in Laravel you have, CSRF tokens. Right? Like tokens to help protect against, cross site scripting. No. CS.
Ben:Cross site request forgery. Is that it?
Lazarus:They always do the same thing. I'm like, what's the order? Okay. There we go.
Ben:Yeah. So, because Sprig is tightly integrated with Craft CMS, you know, I'm like, I'm able to figure out when is a CSRF token and it required and rather than forcing the developer to add their own to their form before submitting it and be able to just inject it directly. And there's a bunch of convenience methods as well that simply reduce the friction. So that when you start using Sprig, it feels like you're just using Craft and you're just using Twig and nothing has really changed but you get this reactive behavior and it tends to be a very smooth experience. One of the things I would say one of the other things that differentiates Sprig from Livewire is that I I try my very best to keep any magic out of, my plugins including Sprigs.
Ben:So I do sometimes get the feel the the feedback from people that this is this feels magical. But I'm always like, no no no no. There's no magic there. It's very simple. It's just HTMLX on the front end, it's just sending Ajax requests, just re rendering your template.
Ben:But your template can be rendered in one of multiple states, depending on the state that was passed over to the back end. There's no magic here. It's very easy to open up the network tab and I encourage people to do this all the time. Open up the network tab, view requests going to the server, see what parameters were sent. View the response coming back and just see that being swapped into the DOM.
Ben:So I resist anything that is too magical. Like I just tried to add some convenience methods that are big wins without covering up too much, low level, I don't know, implementation or whatever. But, at the same time, like, I I try to be as hands off as possible. And I say, like, if you need if you need more low level control, just enter go into h t m x land and start using h t m x and read the docs. And, and that will take you the rest of the way there because, because that means that I can achieve this kind of goal of mine which is like I'm hands off HTMLX.
Ben:Like I still contribute, but I'm not responsible for the JavaScript aspect of this project, which is wonderful. It means I can focus fully on the PHP side of things.
Lazarus:Yeah. And I I think there's something really huge about, you know, using a low level tool and instead of hiding it completely, giving people access to further like that's that's sounds sort of maybe like straightforward the way that you said it, but like I know having done the opposite before how difficult it is to keep, you know, keep it possible, like to build something on top but keep it possible to still access everything underneath. And and I think that's, like, really important too. And and I think there's something Livewire achieved with Laravel where it's, like, you can still use all the Livewire or Laravel blade stuff, you know, if they had made it so that, well, once you're in Livewire land, you lose all the other things. And I think, you know, it's hard to do that but that's like a really powerful kind of goal.
Lazarus:And and, you know, one of the reasons I like so I mean what you're talking about just gives me all kinds of questions. So I'm like first of all like if you were to try to build Livewire, could you do that in h t m x? And I I think based on what you're saying, like, the answer is pretty much yes. And you sort of have. And, you know, I don't use craft c m s so I honestly don't know that much about it.
Lazarus:You know, so it's so those people in the world of Craft CMS sort of have access to something, which is super cool, which, like, you know, Livewire is this big thing, all these tools, Phoenix Live View, you know, they're sort of these huge things. But it sounds like using HTMX, you've been able to, like, recreate that full experience for somebody, you know, who's using Craft CMS, which is actually which is pretty amazing, I think.
Ben:The the way I see it is that, LiveWire is essentially doing what h t m x plus sprig combined is doing. The difference being that one person is meaning in the case of LiveWire, the same person or the same developer is maintaining both of those projects even though it's considered one project. And then, of course, Alpine JS kind of spun off from that. So there's that second project and I believe Caleb is full time on those two projects. Whereas Sprig takes up, I I won't say it takes up none of my time, it takes up a significant amount of time.
Ben:But it's it's still a fraction of my time, rather than, you know, being a full time project. And I attribute that to the fact that h t m x, handles so much of, you know, the the mechanism that Sprig relies on. And
Lazarus:Yeah.
Ben:H t m x is an active project. It's, got plenty of maintainers. And the other thing which I really enjoy is that it's slow moving, right, because you really want if you build a framework on top of any other technology, you want that tech technology to as as you said earlier with Vue JS can continually like pushing out major versions with breaking changes, you want a stable slow moving foundation for your Azure dependency. And that's that's been the case for h t m x. H t m x is kind of been the way I see it has been feature complete since version 1.0.
Ben:And I would like to think that Sprig has also been version complete, since version 1.0 and the only things that I've been adding really have been additive kind of convenience methods to make that, to make it easier to get started with. Like you said with Livewire, you can continue using Laravel blade templates as you normally would. So it's it's it should be I think an additive technology, that you can add on top of what you're already doing and and on top of your way of working with whatever the technology is.
Lazarus:Yeah. And and I think like, you know, I've been a little bit resistant I think to the idea of of something like like Sprigg actually, and and like trying to build a Livewire out of HTMX, because, you know, part of the my part of the appeal to HTMX, having worked in Livewire a lot and and this kind of thing, part of the appeal to me of HTMX is that low level access, where, you know, I I don't and and, you know, I don't want things to change very often, because I'm responsible for maintaining. And, you know, right now it's like I don't know how many sites, like, how many different projects for different people. Since I've started using h tmx I just have this, like, there's a bit of a weight off of me in terms of, like, oh man, like, next year I'm gonna have to, like, update everybody's version, you know. And, like, these kind of they they don't the the client, the person running the website, they don't care about the versions.
Lazarus:They don't want to know about it, but they have so much work involved. So I either have to explain it to them and have them pay me or, you know, I it's just a lot of work. And for my own projects that I do, you know, I don't want to have to think about the version so much. So having a low level tool that kind of maybe you have to sort of, get in there a little bit and and, you know, give more detail while you're working with it at each point. There's an appeal to me of that because I feel like, you know, it's gonna be around, it's not gonna change, and so so I I have, you know, when I was thinking about a framework built with h t m x, you know, what I'm hearing now is actually, like, you it's powerful for stuff like that.
Lazarus:And you could build something like Livewire, which I hadn't really thought of as, like, you know, building something out of that. But I will say like I have been resistant to it because of that because it's hard to lose that low level feeling. That's one of the big appeals for me.
Ben:Yeah. I get that. And I think it's gonna be different for different developers, right, like depending on also depending on how well you understand, like how how well you can grasp that mental model of sending HTML over the wire and back. For some people, it's very intuitive and I've even seen people in the craft community reach for HTML directly and not use Sprague even though it's available. But I think the majority of people I've seen kind of struggle at first with the mental model of, templates being re rendered on the back end and being sent back to the front end.
Ben:It seems straightforward for me, but I've been so deep in the weeds for many years. But the the appeal I think of Sprague is that you can just start using and you don't need to understand the mechanics of it. It's always gonna help. But if but if that comes intuitively to you and if it's obvious and clear, then, yeah, you make a good point. Why not use HDMX directly?
Ben:Like, why pick a higher level tool when you're just as comfortable and feel like you have more power at your disposal, with that lower level tool.
Lazarus:Well, I mean, yeah. So like the other side of that though is I think you would reach for that. And it's like the same reason I was saying I do reach for Livewire still sometimes is like I don't always wanna add a bunch of routes. I don't wanna add a bunch of different templates. Like the mental model of like here's a single file with a single component.
Lazarus:Like I love that. And so what you're talking about with Sprig, like I feel like it's a little it's, it's opening my mind up a little bit to a layer on top of h t m x. And, you know, it's like I don't want to add too much complication, but if you still have access to the lower level stuff when you need it, I don't mind a layer that lets me not write all those routes. And that, like, gives me a little bit of magic and I can figure out what the magic is if I want to. So I don't know.
Lazarus:Like, I think that's actually like a really solid model, and it kind of makes me, like, you know, it makes me wonder, like, outside of craft a CMS, like, could that model be applied to, you know, there's a lot of people doing, like, what is it, temple and go, like, sort of, you know, these other I know there's a bunch of other templating languages, you know, is that a model that applies to almost any templating language? You can add something to the framework and all of a sudden you've got this, you know, I don't know the answer to that. Does that make any sense to
Ben:you? Well there is Yeah, it does. Absolutely. And there is, I think I think Sprig has proven this, and then there have been other frameworks, that came after Sprig. I don't remember the name of it, but I should have maybe looked it up.
Lazarus:Was that maybe the fast HTML? I just saw that on Twitter recently. Fast HTML. People have been mentioning it. It feels like it's built on HTMLX, but I actually don't know anything about it, so
Ben:I looked at that too, but these these JS frameworks and libraries come and go so fast that I don't pay too much attention to them. Yeah. I don't think it's built on HTMLX. I think it has shared some aspects of HTML over the wire. But now the one I was mentioning was, something similar to Sprig, but it's not tied to a particular CMS or framework.
Ben:It was like a PHP framework agnostic version of Sprague. In other words, you can, it handles routing and, connecting HTMLX to your to your endpoints in your PHP application. So that's just another example of, like, doing this. And I know people are doing a lot with Django and HTMLX and and Go as well. So really, like, all you need like if if I was to strip away everything that Sprig does, it just provides this single endpoint which h t m x communicates with.
Ben:And it routes the request to whatever template or whatever piece of logic has to do the rendering of the HTML and it sends the response back as raw h t, raw HTML. And that's essentially all it needs to do. And that's something that you can, I'm sure imagine building. I don't suggest, like, it sounds like you're maybe considering building something like Sprig for for Laravel. I don't suggest you do it only because the Livewire is there and there's a dedicated maintainer.
Lazarus:The space is taken, but I I like the idea of generalizing what your concept just curious, like, in a as a mental exercise does it work?
Ben:I I think if you took, like, a day or, like, a good part of a day, doesn't even have to be a full day, you could probably build, like, that middleware piece. Like that that thing, that version of Sprig that I said with everything else stripped away. It just handles the routing for you. I I think that would actually be a fun exercise to do, in Laravelve. And then you'd, I don't know if you would want to use that in production because then you're gonna have to maintain it.
Ben:But it'll be really good exercise to understand how h t m x can interact with the back end in any componentized way could be, could be good to do. The other thing that that Sprig does because it was important for me to always make HTMLX available is that, I already mentioned that Sprig doesn't add any of its own JavaScript. But, it Sprig kinda parses your templates. And all it does is it looks for Sprig attributes which are essentially mapped to h t m x attributes. So you can use s dash trigger which is like the sprig trigger equivalent.
Ben:And sprig will parse that and actually add, like, mirror that and add another attribute h x dash. Did I say trigger? Yeah. Trigger, target, whatever it said.
Lazarus:Yeah. Trigger.
Ben:So a a big part of what Sprig does is simply parses your your markup and just make sure that HTMLX understands what's going on and h n s sorry. HTMLX handles, all of the interaction stuff on the front end but that's not necessary. You can just use HTML attributes directly because, well, that's how HTML works, right? Just on page load, it essentially parses your HTML document and looks for anything that has HX Get or Post or Delete or whatever. Any of those, HTTP methods or verbs and decides what to do with those elements and you know, places listeners on those elements.
Ben:So because HTML is just doing all of that so eloquently and so seamlessly, all you have to do is just send back the HTML and let HTML take care of the rest. So much of it is handled for you that you can really just focus on like just just building an endpoint essentially. You're building like an API endpoint that just takes in requests and decides what to do with them and sends back HTML responses. And you can do that in any number of ways.
Lazarus:Right. Yeah. And then and then the end result of something like this, you know, I'm still thinking in terms of Laravel blade and and, you know, but it's like these kind of if statements and different HTML is being rendered by these if statements, and the, you know, whether something is true or not that can happen on the front end or the back end, you know, and it's like this kind of mixing of the 2. And so your end results, I mean, the way a livewire component reads, I just I love it. And, you know, like, I have not seen the sprig code, but it sounds like you're gonna have a similar developer experience where you're you're looking at your component, and whether something is happening on the front end or the back end doesn't really matter.
Lazarus:You've got this logical way of showing things and displaying things and, you know, hiding things. And and that developer experience I think is really hard to beat in my, you know, from my experience.
Ben:I would love to show some code, but, there I'm aware that there are people who are gonna be listening, via audio, so I can't. But I think if you were to look I I can send you like or or maybe you have links. I don't know. I can send some code, just to see what a spray component looks like. And I think when you see it, you'll you'll just find it right away.
Lazarus:If you wanna show if you wanna show some if you have some code open on your computer, we can give it a shot. And I I'm okay with I think, we can describe it for the listener. Alright. Because we we looked at a little bit of code with Anthony Alaribe. You know, he's he spoke at the, Big Sky Dev Con and and he was talking about some of the browser stuff but he he showed me some hyper script stuff, that just kind of blew my mind that was like, you know, I've never really used hyper script but it was so good.
Lazarus:And I've never seen it. Once you see the code, it makes a big difference.
Ben:Okay. So we'll give this a go. You can you can be the translator for our, non video listeners.
Lazarus:Alright. Yep. So we got we got the Sprig cookbook open. We're on we're on the Sprig, site which I'll include a link to. Ready made component recipes.
Ben:Yeah. So the idea here is similar to the HDMx recipes that you have a bunch of kind of real world components that you might want. The first one being a live search. So you just start typing and on key down results come up. So if you're familiar with HDMx, this will be like second nature to you.
Lazarus:And And these are all functional demos just to say there's a code snippet and then like a functional search demo right there. It's a very nice nice little setup.
Ben:Right. So here, this is Twig code. So Twig code uses, double curly braces, for outputting things, similar to many other templating languages.
Lazarus:Yep. Same as
Ben:And you can imagine that you're in your Twig template here and you want your search component. So we use Sprig, as a function and then I pass in the path to the template, which will end up being the spring component. So it's just that one line of code there. And then I have a separate Twig file which actually represents my component. And so this is the output tags.
Ben:Sorry. I should describe what I'm, pointing out, but this is double curly braces is for the output tag. A curly brace and this percentage sign is if you're declaring things. So, or if you're like running commands or doing any logic, so I'm setting a query to, whatever query is already defined as. And this will be, the default back to an empty string.
Ben:In other words, when I enter some text that is going to be the query and the value will be set to that.
Lazarus:And just for some big picture, so that basically there's a at the top of the page an include that is their component search. Just saying like here's this Sprague component that I'm gonna include search, and then there's the code for the search which has, you know, language in it for if if else setting variables and then some HTML to go along with it.
Ben:So remember I said that, one of the differences between Sprig and Livewire is that you don't have a PHP component. Here, I just have a Twig component and there's no PHP required whatsoever. Everything actually happens here. So I have a an input field which is my search field. I've added the sprig attribute and that is kind of like saying h x get.
Ben:It tells h t m x that, this input field should be reactive to whatever the trigger that I define is. And so that's kind of a convenience. And like I said, Sprague will actually parse the HTML or the the template for these attributes and then convert them over to HTML. So I'll show that in a moment. And then I'm saying s dash trigger which maps to h x dash trigger, and this will be familiar to you.
Ben:I'm saying key up when it's when the value is changed with the delay. So, about, debounce of 200 milliseconds. And then I'm saying what to replace. Although that's optional. And then down below, I'm just running some, twig logics.
Ben:I'm saying if the query is defined, then fetch the entries using that search query. This will maybe unfamiliar to you, but I think if you just read through it, it's pretty obvious what's going on here. If the entries has a length that is, gonna be greater than 0, then we loop through those entries and just output the results. Else, we have the no results. I'm sorry for the people not viewing this, it's very difficult to describe.
Lazarus:Yeah. So I mean just like, you know, basically we got the search and it's showing the results. And if you could think of this as like, in my mind, and this is how I feel with some of the h t m x stuff, you know, it's it's very similar to how you may do it with h t m x, where you're you're sort of showing all the all the entries. And for some for a tool like this, code like this feels like kind of the platonic ideal of what, like, if you were to translate in your in your head what needs to happen, there's no extra stuff happening. Like you have to, you know, you have to show an input text box.
Lazarus:You have to say what happens, the key up changed, and then you have to show the results down below. And that's exactly sort of what the snippets doing and, you know. Yeah. I don't know how you would make something like this shorter without Right. Hiding something important, I guess I would say.
Ben:Yeah. And the other thing you can see here is that because we were talking about using HDMX directly and when you do that you have to expose your endpoints. Right? Yeah. Whereas here we're not exposing our endpoint.
Ben:We're telling Sprig this is the component that we want you to generate, but h t m x doesn't really know anything about this. So h t m x is always going to hit that same Sprig endpoint, but nothing is being actually exposed, right? Because if this was an endpoint that we're hitting directly then, you know, anyone can hit that and start exposing parts of your like partial, responses and you may or may not want that. One thing I just wanna show you in addition to this is if I inspect the search input field. I just wanna show you what, this is getting a bit technical, but what is actually happening under the hood.
Ben:And just to give you an idea, so we have the s trigger tag which we saw. And Sprig has parsed this template and it has set its own well, there's data h x get and there's our end, our endpoint which is that sprig components render endpoint or action controller. And there is a data h x trigger. So it's kind of just taken what we put in s trigger and copy that over to n h x trigger. So that means that any attributes that exist in HDMX are available to you in Sprig as well.
Ben:And
Lazarus:Yep.
Ben:I'm not like changing the mechanics of how requests go off. All I've done is I've set the h x get endpoint to be the Sprig endpoint and I've, like, converted or translated all of these other attributes to h t m x native attributes. And that's pretty much all that's going on.
Lazarus:Yeah. I mean, that's nice. That's a nice, you know, because you can think of it in terms of a component. So having to sort of make a bunch of different, you know, you think of it as a single thing, and you get kind of the benefits of that, not needing to think about all the other parts that might need to go into that request and the different sections that you would build out. That's sort of contained within your template with your if else statements.
Ben:Yeah. And if if somebody's if somebody's used to working with Twig and Craft CMS, you can imagine like all of this code looks very familiar. The only thing that's new is the ability to put these sprig attributes on an input field and it magically, just become reactive. But everything else like all of this would continue to work, if this was just a regular form and, you know, hitting search, like maybe there's a search button and you hit hit that button, you get a page refresh and you would still output the results in the same exact way. So this really is additive.
Ben:I don't have my input field wrapped in a form, but of course you could do that, very easily. And then this would be true progressive enhancement in the sense that disabling JavaScript, you would still be able to search for things. It would just result in a page refresh as opposed to, it, you know, being the results coming back, over in Ajax request.
Lazarus:Interesting. Yeah. That's cool. That's cool. Yeah.
Lazarus:No. This is nice looking code.
Ben:We did it. We showed a code sample on our podcast.
Lazarus:Yep. You gotta trust me on this one. There's a nice nice bit of code here. Yeah. Okay.
Lazarus:So so let me so I know we're we're, you know, we're about an hour in, so I I want to respect your time here, but I do want to do you have a few more minutes? Mhmm. To so I do want to ask you about, you know, contributing to HTMX. And I know for some people, I think, contributing to open source is just kind of part of life, and it's something that a lot of developers do and, you know, talk about, and it's I it's amazing. I will say it's just something I have never done.
Lazarus:I have my own projects, but it's something that, I I don't quite know how to get started. So so when you looked at h t m x, like, how did you get started thinking, like, rather than thinking, like, oh, okay. I'll figure out how to use this tool. Like, getting to that point where, like, you know what? I might modify this tool.
Lazarus:And, like, did you talk to somebody first? Did you just submit a PR? Did you, like, pull the repo down and toy with it? Like, what's your what's your process for open source?
Ben:I would have to go look at my original pull request. I don't remember what they were. But like I said, in the beginning, I was like, I was trying to get a feel for HMX and just get a feel for is this a piece of software that in my case that I wanted to my software to to depend on. But in the more general case, it would be like, you know, do I really want to use this piece of software? So it was like a lot of, reading the docs and testing things out.
Ben:And I found like lots of rough edges. And as I found those rough edges, I was like, well, you know, this this could be smoothed out or maybe this is an obvious bug that just needs fixing. In the case of h t m x, you you probably know this. H t m x is one big JavaScript file, like that's it. So and and back then, it was, up until recently, h t m x was written to be compatible with Internet Explorer.
Ben:So the code wasn't using very modern JavaScript. It made it quite easy to read. It still is easy to read, I would say for the most part. It's become a little bit more complex perhaps, but even now, I think if you go look at the HTMLX source code, it's pretty straightforward what's going on. So as I was exploring the tool, I was finding these rough edges.
Ben:And I'm not afraid of going looking at the source code and, like, tracking down where where, you know, what is causing this. Like I said, a lot of my con contributions were like just 2 or 3 lines at a time or maybe like just fixing something that like you can imagine a situation where what's an example, like you know how you can pass multiple triggers into hx trigger attribute, and they're comma separated, right? So maybe you can imagine a situation where you add 'clicked' and then 'comma' and then you add a space and then, what's another key up or something. And maybe like that doesn't work because you've added a space and h tmx is like just expecting it to become a separated without spaces. This is just a random example, but it could have been something
Lazarus:like that. Yeah. No. It's the kind of thing that can happen and you would have no idea why it's happening.
Ben:Right. But you might discover it and you might see, oh, that space is causing the issue. And at that point I can I can file an issue and I can hope that somebody looks at it and, you know, at some point, tracks down the code? Being an open source framework and back then there was only one maintainer which was Carson himself. I was like, well, you know, let me help the guy out and let me, you know, if I'm gonna use this tool, and if I'm going to build something on top of it, let me see what the contribution process even looks like.
Ben:Because this is impactful for me, but I think it's impactful for anybody using a tool professionally. What does maintenance of that tool actually look like? So in this like made up example, I would go figure out, okay. Maybe we remove all of the spaces before we, you know, separate this h x trigger out into multiple pieces. So I would just open up the code.
Ben:I would find that one line and that would just be a line and maybe it just needed, like a, I don't know, a string replace of spaces. And that's it. And then, you know, of course doing due diligence which is, testing that I it actually does fix the bug. And in the case of h t m x perhaps or any library that has a testing framework, actually writing a test for that fix. So you you would create a test to prove or to guarantee that, that actually was a bug.
Ben:So it was failing before and after your patch, it actually passes. And tests are not only important for proving that bug bug fixes are relevant and appropriate, they're also very important for preventing regressions in the future. So that there's no chance of that bug ever resurfacing because there's a test now in place. So ideally, if there is a testing setup which there is for h t m x, you would fix the code, you would write the test, and submit the PR with a, you know, a logical description of the before situation and the after. And that's about it.
Ben:And then hope that somebody has the time to look at it. And if you've done a good job, this is the other thing. If you've like done a good job of submitting a PR, then all the maintainer has to do is click the merge button and, you know, they're good to go and you're, kind of, guaranteed that it's gonna make it into the next version. So I think I would say my advice would be, like, start with something small that affects you and write a good PR so that it's, like, a no brainer for the maintainer to just merge this rather than forcing them to to write the tests and to, you know, write the release notes for it and figure out why it's an issue and in what circumstances. The more upfront work you can do, the better the chances of it being, added to the code base.
Lazarus:Interesting. So so how do you how do you run the tests on your device? I'm just trying to imagine, like, and and I don't know what the h t m x test would sort of, like, what language would they even run-in? Like, how would you write and run your own test?
Ben:So you need to adhere to whatever testing framework. The thing that you're contributing to is using obviously, but h index uses a JavaScript test testing framework. I don't remember now. It's been a while. Is it Mocha or Cypress or something like that?
Ben:And it says on there. Yeah. It'll there should be for any serious piece of software or open source package. There should be contributing guidelines. And those guidelines, I forgot to mention those of course.
Ben:You should read those first, and they should hopefully give you an idea of what submitting a PR, you know, should look should look like. And part of that should be describing how you create tests or how you run the testing framework. In the case of HDMX, I think, I actually think the testing framework gets run on every PR. Although that's not the ideal way of running tests, you should probably clone the repo and run them locally. I think it's quite straightforward because the repo should contain everything you need to run the tests.
Ben:And then, how do you create your own test? Well, you figure out where the file is that contains tests for the example I gave previously like, what tests are there in place currently that are testing the hx trigger attribute. And then, I would find 1, I would open up that file and I would add a new test that's called something like, 'tests'. That a space in the attribute allows for multiple triggers or something like that. Like a descriptive title for that test and you follow whatever convention already exists in there.
Ben:That's the easiest way I found. Like just follow the conventions of that particular project or library, because consistency is just just good in general. And then just run the test and and you want to do, you wanna do red, green testing. So you want to just first write the test, show that it fails. Alright.
Ben:When it should pass, then apply your bug fix. You know, you do this locally, run the tests, and then it turns green. And you know that you your your code has actually fixed the issue.
Lazarus:Yeah. No. I mean, that sounds that sounds good. It's like, it's always been a little intimidating to sort of take on other people's projects like that. And like I do other projects, but, yeah, that that sort of next level of actually joining an open source thing, I'm still kind of still kind of think you know, looking into it, but that's, I think that's that's a pretty solid description of how to actually go about it.
Ben:It's not the only way, like, I would say, like, probably approximately half of my PRs to HDMX have been, fixing and improving documentation and, fixing broken links, that kind of stuff. Like, you're always gonna find mistakes in documentation because it tends to be like a living breathing thing.
Lazarus:And that's a So is this documentation that goes up on the site? Like, is this
Ben:Yeah.
Lazarus:Okay. So that that like that's built and has its own separate repo or is it sort of the same
Ben:It's actually part of the same repo. If you go to the h n x repository, I think there's a folder called web or www or something along those lines. And you're gonna see a bunch of markdown files in there which are which is the documentation. Gotcha. And that there's a build process that happens.
Ben:I don't know how often this happens. But as soon as something is merged in within like 10 minutes or 15 minutes, it goes live on the site. So plenty of my contributions to the library have been documentation improvements really. And that's in in my best interest because like I said, like a lot of what I don't document in Sprig, I pass people on to the h t m x doc. So I want those docs to be as good as possible as well.
Lazarus:It's in my best interest too because I've just been mining that thing for, for for podcast content. Yeah.
Ben:Yeah. I
Lazarus:love the docs. Good documentation.
Ben:Like, who doesn't benefit from that? Everyone does. Yeah. Even the AI bots do, but whatever.
Lazarus:Yeah. Yep. Yep. So alright. So, let me see here.
Lazarus:Is there anything you wanna mention that we didn't mention? You know, some of the work you're you're doing. I I know you've got your company does, craft CMS, plugins and support and other stuff. Is that Mhmm. Is that accurate?
Ben:I mean, support is is part of the game. Yeah. And when you build plugins, so there's plenty of support being done. No, I mean the other thing I mean on the topic of support like what I tried to do with all of my plugins including Sprig is just make it as easy as possible to use with the perhaps selfish goal of like, then I'll have fewer people asking me questions if they can figure out No,
Lazarus:that's the best. Yeah, that's the best.
Ben:And in terms of like, like, I don't know. In terms of Sprague, HTMX, like I think it's the only way really to get better at it is to use it and build things with it. Like as with any technology really, but HDMX especially. Yeah. It's an extremely powerful library.
Ben:You can do so so much with it. Actually wonder Yes. Here's one thing I did want to mention. I don't know if this is another rabbit hole, but we can try and keep it brief. The out of band swaps feature in HDMX.
Ben:Yeah. I always thought was something extremely interesting and powerful. But I've only come to realize how powerful recently. And it's it's a bit of a difficult one to wrap your head around, right? Initially.
Ben:But what I've been able to do in the most recent version of Sprague is add a Twig function which is called swap o o b. And I've essentially built kind of a higher level API for the out of band swaps in HTML. And I think that's one of the interesting, like, really interesting things of layering something on top of h t m x is that you can take those kind of rather complex concepts of outer band swaps. And maybe I'll just describe what it is or I'll do my best to, briefly is that without a band swaps, you can kinda like it's almost like you package responses together and then you can like swap different parts of the DOM out, using different parts of markup. But rather than having to make, like, several requests to the server, you can just package those up in a single request.
Ben:Yep. Kinda hard to explain which kind of Can
Lazarus:I give a quick example of Yeah? Do it. The way that I've used them? So, you know, I'm I'm working on a site right now, that is actually related to HTMX. But one of the things that I'm gonna do is is take some of the podcast episodes that I've done and, include them in the site so that you can see them.
Lazarus:But they're gonna be sort of all over the site, you know, in different places. But what I'd like to do, you know, what what I've done actually, but is have a single request that once the page loads so that it doesn't slow anything down, I'll do an h x, trigger equals load, send that single request to, you know, load slash like load podcasts or something. Now this load podcasts is going to have, pull all the podcast episodes that are relevant, let's say it's, like, 40 of them, and include with each the ID of some ID in the dom with an hxswap o o b. So those IDs in the dom might be all over the page, you know, each section will have its own little podcast episode, you know, marker that you can click on or something like that, but they're scattered all through the site. So I have a single file that loads once and then it just kind of shoots those episode little snippets out to different ID's all over the dom.
Lazarus:And, yeah, I mean it's extremely powerful to be able to do something like that without you're not replacing the whole site, you're not slowing anything down, you're just kind of, you know, think of it like a traffic cop, for your your HTML, where it's like it sees each one has its own slot, and it puts it into the slot on the page. So that that's kinda how I've how I've been using it, how I think about it.
Ben:Yeah. It kinda it's like a delegator. Right? Like it delegates this piece of markup up there to this part of the page and a different piece of markup in the same response to a different part of the page. Actually, the the classic example I use when when describing it in Sprague is you have, like you have a commerce site with your products And in the top right hand side of the page, you have a little shopping cart image with a counter next to it, right?
Ben:So you see, oh, I currently have 4 products in my cart. And when I add a product, I want the the number next to the cart to automatically increment. So that would be fine to do if you were swapping out everything on the page that includes your products in your cart. But very often, the thing that is reactive is just the product itself and you don't wanna have to swap out the entire page or or a big chunk of the page. So yeah.
Ben:So this so OOB allows you to just like send back the the response when you add that product to your cart. Just send off a request and get the response. But in the response, you can also add or include the new count for the shopping cart. And if you specify it in the right way, then it'll swap out that, particular HTML element.
Lazarus:Yeah. That's a great use case for it too.
Ben:Yeah. And a very common one too, Craft CMS. There's a commerce plugin. So a lot of like, a good chunk of Craft CMS sites are commerce ecommerce sites. And yeah.
Ben:That's the classic case where you have a shopping cart and you want things to update on various parts of the page. But what I found is that the out of band API or the way that you use out of band swaps in HTML. It's a it's a little bit clunky because you need to match these IDs up. And the attribute is kind of like awkward. Like, do I put true in?
Ben:Do I set h x swap out of band o o b to true or to an element ID? Or as I've recently discovered, you can do you can set it to the swap, the swap strategy colon a CSS selector. So you can say after end colon, you know, my component with a hash in front of it or even a class name. So like, this is very powerful thing that I believe I heard. I think you I think you and Carson discussed it on a recent podcast.
Ben:Is that where
Lazarus:you go? Yeah. Carson basically, he added that to the agenda and basically like, I added this because someone asked me to, what do you think about it? Which I thought was really interesting. Yeah.
Ben:For the record, I don't think that somebody was me, but I am glad that it exists because, because I've now been able to leverage it in Sprig and add this much much easier to use API that takes advantage of out of band swaps.
Lazarus:Because Interesting.
Ben:Yeah. So I'll describe this one rather than show code again. You can imagine your Twig template and you're able to call a function called sprig.swap00b, and then you simply pass in the ID of your component. And I think you need to pass in the template path as well. And you don't need to mess around with the funny syntax.
Ben:Sprague will convert that into the syntax that you need. It will inject the markup into the div with the correct ID and h x swap o o b attribute and handle all of that kind of what I consider kind of lower level implementation details for you. So you get a
Lazarus:very So sorry. What are
Ben:you giving it? API. You give it the ID of your component or Yeah. Or it doesn't have to be your component, it can be any element on the page. And the second parameter has to be the template path to the component.
Lazarus:Template path to the component. Okay. So this is something that you would know if you were, you know, you're coding in the back end in Twig. You've got that, you know, that's how you're referencing your different components and what to add.
Ben:Yeah. Up until this point, I've been suggesting to people when they need to do something like this that inside of your re rendered component, you trigger a refresh on, let's say, your shopping cart component, right? So you add a product to your cart, so your product component is re rendered in the response in the result of that trigger refresh on the shop shopping cart component. And that works, but what it results in is one request to the server when you add the product to your cart. And then immediately after that, a second request to the server to update the value of the shopping cart.
Ben:And the syntax is quite similar. You need you need to say trigger this component and give it the ID. Right? So so your code knows what what it's triggering or sorry, what it's refreshing. But now with swap o o b, you're able to say, okay, when the response comes back in addition to this component, this product that we're adding to the cart, fetch the new value of the shopping cart count and package that up in that same response.
Lazarus:Yeah. So you
Ben:get And actually a single request and multiple things can be updated on the page.
Lazarus:Yeah. And you're not relying on, you know, I don't know how much you trust in general your event status on the front end. I just I get bitten by that sometimes where for whatever reason some event didn't trigger after it was supposed to, and so something else doesn't load. So this has a nice benefit. I and that's one of the nice things I like about, you know, doing a lot of stuff on the server side.
Lazarus:It's like, you know, you do it there, you know that it's finished, and then you can send it out, which, like, obviously, your front end should be reliable, but, you know, you never know. Yeah. No. That's interesting. That's cool.
Lazarus:So it's like, another example of kind of adding a layer on top of of the sort of a built in h t m x kind of functionality.
Ben:Yeah. It's it's seeing h t m x as a library on which you can kind of build a simpler API. That appeals to the people, yeah, that appeals to the target audience. In this case, it's craft developers who may or may not know what HTMLX is and how it works. So rather than having to learn that, they just get this simple API that, that is nicely documented and looks like it's just a Twig function because Twig functions are will be familiar to you if you work with Craft.
Lazarus:No. That's interesting, because you could also I could also imagine kind of packaging a swap OOB in different ways depending what you're trying to do. You know, if you're trying to just update a single cart like that, maybe that's one version of it. Maybe you have a slightly different package for if you're doing, you know, sort of what I was saying, where you're you're packaging 50 things up and putting them in different places on the page for whatever reason. And, you know, that maybe the API for that to help people understand it and use it is slightly different between those.
Lazarus:And so the ability to kinda just add that layer on top and make it nice for the user, that's interesting. That's cool.
Ben:Yeah. In the case of this function for Sprig, you can just you can use that same function multiple times. So you can package up 50 different things to swap out throughout the page, and that's simply the API that I chose that you. Simply execute that function 50 times in your Twig template. But you're right, you can build the API to be whatever you want, because you're in control of it.
Ben:And that's the beauty of it. You don't I have nothing against HTMX's API and when I say API, I don't mean the JavaScript to API which is another thing, but I mean the, you know, the attribute syntax. I have nothing against it, but, you know, there are ways to to make it simpler to use and to take advantage go ahead.
Lazarus:Yeah. And particularly for your, you know, once you're inside a niche, you know how craft CMS developers are thinking. Like, you're in their heads. You're building for them. So just, you know, packaging it in a certain way that just unlocks that power for them.
Lazarus:Nice.
Ben:Precisely. Yeah. And my guess would be that's why you love Livewire because you're you're already in Laravel world. Everything feels familiar and you just get this kind of super power added on, and without feeling like you've like had to learn a new thing really. Like it Yeah.
Ben:You don't have to learn a new language or a new concept. It's just like this additive, feature set that is suddenly available to you.
Lazarus:Right. Right.
Ben:So what's, before we finish up, what are what are what are you are you gonna contribute to a project or what's, your next move?
Lazarus:I don't know. Just a moment with the disc list. Yeah. Carson was was, when we talked, you know, trying to bully me into, doing some sort of, kitchen sink kitchen sink, version of HTMX because I don't I also don't, in addition to not really source diving, I also don't look into the extensions that often, because my general thought is, like, maybe I'll come across the extensions if I need it, but usually I just pull in the tool and and use, you know, what's there. But but there's some extensions, I think, particularly around, error handling, because, you know, with h t m x by default, when something goes wrong, you just kind of get nothing.
Lazarus:Like you're kind of just you gotta check the network tab, and even the network tab is a little shaky. It's like you get a little console error, and I don't know what's happening there. So I guess there's an extension which I haven't even used yet, to help you with errors and give you some more information and stuff like that. So I kind of, I wish that was part of the core, but you know, Carson is he's resistant for very good reasons to putting a lot of stuff into the core. He wants to keep it light.
Lazarus:He wants to keep the, you know, just the core things, and then you can just add extensions. So, you know, I had I asked him or he mentioned actually, like, maybe there should be a kitchen sink version of HTMX that kind of includes here's the core, extensions or let's see. Are they extensions or am I am I using the wrong word? Plug ins. No.
Lazarus:That's right. Extensions. Extensions. Okay. So here's the core ones.
Lazarus:So, you know, for people who just wanna not think about extensions there's a so, you know, that's kind of, its own its own world, and and he was saying, well, why don't, you know, maybe you should build that because if that's something that would be useful to you. And so it's like I like the idea of, you know, what you're talking about. I think it's just a really healthy and good developer mindset to be in, where you looked at a tool, you wanted to use it, you wanted to improve it, you helped the maintainer out, you gave tests, you made the PR nice. Everybody who works in open source talks about that. That's sort of the ideal user of these tools, is someone who who is involved and who wants to kind of contribute like that.
Lazarus:And and I've never really been that for any tool. I mainly just use stuff and and I've never really contributed. So I'm just kind of introducing the idea into my own head and trying to figure out how that would actually work of, like, if I did want to dive into one of these tools and contribute or, you know, make this kitchen sink version or or I haven't come across any bugs yet, but if I did come across a bug, you know, would I actually step in and and see if I could track it down, stuff like that. So just kind of something I'm thinking about.
Ben:Well, one thing I will add to that, Lazarus, and I'll push back on you a bit, saying that you don't contribute to HD NX. You you have started a podcast called the h x podcast in which you discuss HDNX. And this is this is a wonderful resource as well. So, thank you for doing this. And, do see it as a contribution as well to the project.
Lazarus:Oh, I appreciate that. It's mostly for fun for me. So this is my hobby. I don't get any there's no, this is not a monetary project in any way. It's just, you know, this is like a fun thing.
Lazarus:So, I appreciate So
Ben:you're contributing to something you love, which is great.
Lazarus:Yeah. I guess so. Well, cool. Alright. Well, one more thing.
Lazarus:Where are you calling from? I forgot to ask that. And I think you mentioned it at some point. But
Ben:I am based in Austria. But I Okay. I'm originally Irish, and I Irish. My wife and I kind of live nomadically, so we'll be like different seasons of the year. We'll be in different places.
Ben:Next time we talk, I'm sure I'll be somewhere different.
Lazarus:You'll be somewhere else. Okay. Nice. Alright. Well, thank you very much for joining us.
Lazarus:It was really fascinating, talking about this stuff. So I I really appreciate, you taking the time and coming on.
Ben:Yeah. This is great. Thank you for doing this podcast, Lazarus.
Lazarus:Great. Alright. Have a good one.
