Subscribe
Share
Share
Embed
Join me while I learn HTMX and talk at you about it
Twitter: @htmxlabs
Alright. So I'm joined today by Lukas Petisz and, from, let's see, CzechSec. Is that correct? So yeah, thank you for joining today. No problem.
Speaker 1:And you do use so so, you know, we we got in contact on Twitter and basically, you mentioned that you've been using h tmx for years. And, yeah, HTMLX is relatively new. So, you know, a lot of people who've been using it, it's like a month, couple months, you know, or since it got really big. So this is something I feel like you're, you're now one of the OGs, one of the original, HTMLX users here.
Speaker 2:Yeah. Like, the the the first time, I heard about HMX was, I believe, DjangoCon 2021. And, like, at the the first first interaction, it's always weird. So you you think this is very, very strange, like copy pasting, like, HTML. But, after some some talks, especially from conferences, especially the one the holy grail, where I believe a company converted an entire application from React to HTMLX.
Speaker 2:At the time at the company I was working, we started to pay more attention. And since most of the work we did was, let's say very CRUD based, so administrative applications, back office management, data pipelines, There was no need for excessive UI, let's say. Something very just simple MPAs will do the trick. But of course, sometimes, we'll have some some necessity for what we feel with the same, let's say, effort because we were a small team. So there was there wasn't a very, like, budget for having front end and back end to to build something that will be better than your usual run of the mill, MPA.
Speaker 2:So we started doing smaller implementations until having complete projects built around the hypermedia approach, and using HMX completely. So yeah.
Speaker 1:Interesting. So before we get into some of the the details of that, one of the big picture things I'm kind of noticing here is that I would say the Django world and, you know, DjangoCon, I've it's come up several times, in talking about HTML stuff. Do you do you feel like there's kind of a natural, pull in the Django community for this stuff? Or what's what's sort of going on there? What's your take on on,
Speaker 2:on the So like if you if you if you look at other other similar frameworks like Rails, LiveWire, stuff like that. Django doesn't have anything like that. It just has plain templates, HTML templates, where you can insert your Django ORM data. HTMLX really like clicked for Django because and FastAPI, other Python frameworks because it filled that gap. Interesting.
Speaker 2:Yep. Django doesn't have a native, let's say, REST API, so you'll need an extra package for that. So when you're building APIs, that's very common, building APIs in Django, but it's not out of the box. And Django is a framework out of the box. Like, it provides you templating, ORM, middlewares, all all those those features.
Speaker 2:But it doesn't provide you, like, an easy way to do REST. You'll need an external package. You'll need to learn an entire new tooling. Right? And, I guess like you can can take full advantage of Django, when using REST.
Speaker 2:And when using REST, no. When you're using an API, you're not using the template layer. And I think a lot of people notice that even for the most, let's say, CRUD applications like data management, back office, administrative things, You don't need a fully featured, SPA. You just need a good looking, no page loading, let's say hypermedia approach. And it's very easy to prototype and to, to get to, let's say a proof of concept.
Speaker 1:Yeah. Yeah. So, okay. So that's interesting because, you know, you're talking about the different frameworks. Like I come from Laravel, you know, which I would sort of put in the same class as Django and Rails, and you know, there's all these sort of large back end frameworks with different languages.
Speaker 1:And yeah, Laravel has Livewire, which kind of gives you that from the back end hypermedia approach with some Ajax. It's got a different different approach than HTMLX, and then Rails has Hotwire, you know, this is like the official approved DHH, you know, stuff that basically HTML over the wire, same sort of similar kind of concepts. And yeah. So the ones that have really sort of, seems like embraced HTMLX the most are, you know, Go seems like kind of goes with it. Yep.
Speaker 1:And Python and Django. Yeah. So I guess that that that makes sense if it's kind of filling that void of, like, we want to use this back end framework, but we do not want to build an SPA and, you know, do a react view.
Speaker 2:It's like, I'm not saying this, works for all applications, right? When you have a lot of client side states, you can't go the hypermedia way, or you can go if you encapsulate certain elements. For example, a common pattern when you have, let's say, a wizard, form with multiple pages. Right? And you have a certain page that has a lot of interactivity, a lot of client state, needs to save a lot.
Speaker 2:Maybe the Hypermedia way isn't better, but that should shouldn't stop you from using the Hypermedia way. You can just encapsulate that page into a web component or some a bit of Alpine JS. And I think, like, Django allows very, very quick development and especially on small companies. You sometimes you can't have like the dedicated front end team, dedicated back end team. So having the control over both sides because even on larger corporations and you have like the communication side between the front end team, back end team, there's a lot of, resources that can be eliminated with, with using this approach.
Speaker 2:Even even like, I also do freelance work for small companies like also management software. And it's a one man job. So back end, UI infrastructure, meetings with customers. And for a single person, like maybe, I don't know because I don't have that kind of experience, but 10, 15 years ago, it will be a easy job, like for one person maybe using PHP, something like that. But right now, like developing, complete back end with, front end application, and doing it in a quick and reasonable, let's say, schedule can be a bit tricky.
Speaker 1:Yeah. Yeah. And so when you do a project like that, do you get to choose your tech stack generally? Or does it kind of depend on the client and depend on the person?
Speaker 2:So in terms of freelance, usually, I choose, the tech stack. However, like, some requirements push me outside of the boundaries. Like, when I started working, I started learning React, then I switched since I saw front end is not my thing, I'm going to Django. I started running React, but I've never touched it for 4 years. But recently I need, I have let's say I need to do a mobile app and I ended up going for React.
Speaker 2:But it's a bit of a basis, depends on the customer's requirements. But when it's web based, I usually go for Django HCMX always.
Speaker 1:Yeah. Yeah. No. I'm I've I mean, except for the Django part. I'm in the Laravel world, but, you know, the same sort of deal for me.
Speaker 1:It's like if I get to choose that tech stack, that's my current one. So what's your general, like, what's your general role? You said so you know you do your freelance stuff, so you do some stuff on the side. What's the the company you work for and it I mean, is it something that's your company or is it someone someone's company that you work for and and sort of what's your role there?
Speaker 2:I I usually like we we work with, like, the infosec market. So, security companies, we we do software for managing and pen tests, managing pen test reporting, and all all sorts of communication between, like, pen test teams and security firms and their clients
Speaker 1:What are you saying there? Pentest?
Speaker 2:Yeah, like, Pentest Reportings. So if you have a company that does, infosec services, we develop software for them to manage their reporting and their day to day business.
Speaker 1:What is an infosec service? I just look what's your what would
Speaker 2:It's a bit complicated because it's it's a moving part, a lot of moving parts, but usually if you have like a security company that needs, that needs, actually, the the other way around. If you let's say you have a website that needs to be pen tested, report to something like that, our customers will do usually go and ask them to file a report, a request, and they will just deliver a report in the end, test the website, for example, or the application, something like that for security flaws. And the software that the company where I'm at currently does is a software for managing those kinds of interactions. It's something that we've been looking at into HMX, not for the main projects, but other smaller projects, and seems to be paying off. Although some let's say the hypermedia approach is still very young and fresh.
Speaker 2:Right? So for bigger projects, it still needs, I think a little bit of development, but that depends a lot on your tech stack. But yeah, like on most of the I can say that I joined this company this year, but on my best best experience, most projects were fully migrated to Django HCMX. Interesting.
Speaker 1:So like, you know, I guess, I've been trying to sort of push up against the limits of HTMX just to find out what they are, you know, because in my, you know, a lot of the stuff I do, it sounds somewhat similar in terms of, you know, the the end needs are like it's very data driven. It's a lot of, you know, text, it's a lot of team collaboration, so it's about sharing data. Most of the work is done on the database side, you know, the like core application logic. And and then, you know, you need to see it, but it's like, I do what I've really appreciated using htmx4, and you know, before that Livewire, and I still use Livewire for some things on some projects. What I've really appreciated it for is, you know, taking something like that, and like I have this idea in my head of how I want the UI to be, and it's like and I base this just solely on what I would want to use, you know, it's like I'd like to be able to do a lookup and select something and move to the next part without refreshing, without losing, you know.
Speaker 1:So it's like those types of, you know, being able to just take my sort of simple version of the page and just make it much better, in my opinion, you know, and and a much more much smoother UI. And so far for my personal requirements, you know, I haven't sort of run up against the wall in what I can do. And sometimes it has gotten tricky, like, a little bit, you know. It's like nothing you're never gonna just gonna nothing's ever just you know, it's not like some magic bullet or something like that. You still have to figure out, you know, how you're gonna divide the page up, and what you're gonna send, and where you're gonna put files, and you know, all that kind of stuff.
Speaker 1:Would you say that what would you say is, like, can you think of a time where you sort of came across something and you felt like, okay, I'm gonna have to rethink this or maybe someone else made that decision?
Speaker 2:So I can I can give you 2 two examples of that? So like I said before, when you have, let's say a page or a view section, let's call it, where you have a lot of client side, interactivity, there are various ways to deal with it. Alpine JS, inline JavaScript. But the problem is that with the the times, like, maintaining that it's very hard. So usually the the approach I take so when we when we found a problem like that, usually we delegate we still make client side interaction with JavaScript.
Speaker 2:So DOM interactions, all that stuff delegated to an custom Alpine directive. So isolate it.
Speaker 1:Interesting.
Speaker 2:I guess it goes a bit like, not the same thing as HTMX because HTMX, wants the declarative way and everything on the, on the code. But, take all the interactivity to a custom Alpine directive and just declare it on the partial or in the element. And when things get really pushed. So I can tell you an example of a UI I did, I think, last year. So we had like an active search.
Speaker 2:It's a search at the groupings. You can move around the groups, like, and make subgroups. So you'll have, like, a sortable experience. So you can sort elements. Right?
Speaker 2:But with different levels. So it's not a simple just sortable UI. That plus the active the act the active search plus adding extra elements, creating them on the fly. While that can all be achieved with h tmx, it will be like a giant mess. So we just like moved it to an any run of the mill front end framework.
Speaker 2:We use Svelte because it's it's quick and easy to to do things and it generates small bundles and just dropped in as a web component. So it's just an HTML tag and it will render when it, when the, the HTMLX, settles. But like I said, those are the biggest hurdles I think is, too much client side interaction or things like, for example, we used a lot of Maps, GIS software. So like Leaflet, those types of things you need JavaScript. You can't you can't forgo with JavaScript.
Speaker 1:Yep. So okay. So on that, let's just stay with that example of the sort of multi tiered search where you need to be able to to do a search. It sounds like what was hap like what's happening is you're you want to be able to like you can run your search, and when you resort, you're not necessarily pulling new data from your back end. You can can you sort of trust that you have sent enough to the front end, and then at that point, it's sort of you're moving it around and filtering it and sorting it with Alpine, or is it still is that sort of component still pulling from the server?
Speaker 2:Like that, that example, I gave was actually like a Svelte web component with its own, like, micro API because it's you can do it with Alpine and with HMX. No problem. But the amount of swaps and the amount of wouldn't be very, very efficient, especially and we're not talking just about user experience, but also as a developer experience. That specific element, right, was going to be used on multiple pages with multiple types of objects. So it will be useful to have just a single source of truth and have it on a single component you can deploy on all partials.
Speaker 2:Yep. That's the
Speaker 1:same. Yeah. So, you know, one of the things I'm just kind of like I've been thinking about a lot in my usage of HTMX is this kind of issue, and, you know, I think that's a good that's a good solution to it is to if you know kind of, you know, there's a some of these front end frameworks kind of have to take over your whole site, but not all of them, you know, Svelte doesn't really have to, Alpine doesn't have to, Vue actually doesn't have to, although my experience has been that you end up going more and more to the site, so I don't really use Vue anymore. But, you know, you don't have to. You can bring it in just for a small point.
Speaker 1:So I think that's a good solution for this kind of thing. But one of the things I still you I still really appreciate and like about Laravel Livewire, is it does kind of encapsulate, your like, you can sort of you think of things in terms of a component, and that's one thing that, you know, I sometimes wish that I could do with HTMX, because with HTMX I am sometimes creating several routes, you know, I have sort of one object and I have maybe 5 ways to update it. I think a search is a great example of that. You know, a lookup. You're doing filtering on the results, you're sorting the results, you're, you know, I don't know, besides filtering and sorting I can't really think of other things, but there's a you're having like a report button that's, you know, shows the results in another way, or adds, you know, showing different fields and stuff like that.
Speaker 1:So there's a lot of stuff you can do, but what I sometimes want to be able to do, and like what Livewire gets right, is you have this like single component, and that sounds like what you're building in Svelte also, is like, okay, this is like my search component, and everything I change goes back to that search component. I don't necessarily have to declare a new route for it, make a new, you know, a new template for it. I don't have to necessarily pull in some several different partials. It's like we have this one thing and many ways to change it. So, you know, if HTMX had that kind of con like, does that even make sense with HTMX, you think, or is it sort of not in the realm?
Speaker 2:Like, I understand what you're and also is something that's I'm trying to to manage. So I'm preparing a talk for the next DjangoCon Europe next year. And I also see that that approach. So like in Django, you have views. I I believe that basically, it's an endpoint.
Speaker 2:Right? I think, Laravel must have a similar concept, but you could join everything into let's say, you can treat basically a back end view as a component. You can have, and I use that technique, basically lazy loading. If I have a page with 2 tables, right, I load the page and then I use hx trigger loads to load each table independently. And I couple them as a component.
Speaker 2:Right? So if I wanna, let's say, someone, reaches me and says, okay, so that table needs now to be displayed on another place. I'll just move the HTML element that does x h x trigger load to another place and it just loads because the entire view works as a component. And I think that's something that's maybe not with Django because I don't know if I'm seeing Django as a project move into the HCMX side. It's under the HCMX works more like, auxiliary, components.
Speaker 2:But I can see maybe in other frameworks, they adopt a similar style where you define components and you render them in the DOM. And the endpoint works as the logic of that component. I guess it's basically your usual React component, but the logic is on the server.
Speaker 1:Yeah. So so I do I do a similar thing with Laravel. You know, Laravel has their blade templating. And so I'll divide up the page, you know, similar kind of way like we've got our page and then we have the table and tables a separate view. So if I need to reload that or put, you know, move it stuff like that, I'll do the same thing.
Speaker 1:I think that's, I think that makes sense. But one of the issues I think that that does have is that, at least right now, it's something to think about is sometimes that table, let's say it does need to be loaded somewhere else, do you have the data for that? Because usually a view, a template, kind of just has your layout, you know, and like what you're passing to it you still need to pass that separately. So what I've kind of started doing sometimes is inside that template, Larva lets you do this, I'm not sure if Django, you know, what what they sort of allow in your templates, but you can load stuff in there. And so I'll basically check like if the data I need is not there, then first pull it from the database, make sure it's there and then continue.
Speaker 1:You know? So is that sort of a pattern you've come across
Speaker 2:or had to do? The thing about, the Django templates is are very powerful, but they they don't have, let's say, component composability. So you don't have, like, components. You just can include and extend templates. And that's something that I used for months, years, I guess.
Speaker 2:Just having like extended, for example, tables. And that will just extend the blocks that has, table header, table body. But at least in the Django world, it started to show up in the last few months. A lot of packages, I can name a few like Django Cotton. It's one I use a lot now and JinjaX that basically allow you to create components that can be passed around and can be extended.
Speaker 2:And they work more in a component way so that if you wanna change the data, you just declare it with another slot or another content inside. But of course, it's not a native feature, but it's it's not popular because of HTMLX. So you can have, like, the basis for a table, for example, or for a button. And you can declare it with a single HTML tag or in this case, a custom tag, and it will fill the data in. But that's, of course, outside the of Django's internal template engine.
Speaker 2:It's external packages.
Speaker 1:Yeah. And this is relatively new in in Laravel as well. And I still don't really use the components stuff that much. I guess what I'm sort of talking about more is, like, making database calls directly from my templates, you know, where it's like I used to go through a controller first. It would be like, you know, I'd hit the route, go to the controller, get all my data, pass that to my view, and then my view would just assume, okay, we've got all the data we need.
Speaker 1:Now I just like I'm skipping the controller sometimes because you can just sort of, you know, go straight to the view, and then in my view I'm like loading some of the data I need. And so I'm sort of treating my view as like a single page, you know, component that has everything it needs in it. You know, I don't know if that's a pattern I should be doing exactly, but I found it very convenient.
Speaker 2:No. Like Django was, like the the way you're talking about bypassing completely. The Django has similar features. You can create custom template text that run logic inside your template. But it's usually not used for an entire logic.
Speaker 2:It can be useful, but I think probably in terms of performance might not be the best use case.
Speaker 1:Right.
Speaker 2:But it might, like you said, it might evolve to some kind of element like that. Yeah.
Speaker 1:Does your team use HTMLX as well or is it something that you brought to the mix? You said you're relatively new there, you know, I'm guessing
Speaker 2:it's I'm there, I think, 6 months, 7 months. Yeah.
Speaker 1:Okay. Yeah. So you're you're very new.
Speaker 2:Yeah. But, when, yeah, I'm I'm dealing I'm the only one right now at my current company working with the HMX. But at my, long staying last company, there was, I can say, a team of 3, 4 people working with HMX. And of course, certain patterns, that we shared between us, we used to go to the Django Cons. We share knowledge with people.
Speaker 2:We, my last company actually organized some. So it wasn't really a question. It was, at at a certain point after we saw it, it really works, when works well. Yeah. It wasn't even a question.
Speaker 2:It was always using it. Yeah.
Speaker 1:Yeah. So you said you're gonna be doing a talk going forward like at, have you done, you said you've done, have you done one before
Speaker 2:or is this the first time? I've done one at PyCon Portugal, last
Speaker 1:year. Portugal. Okay. Yeah. Nice.
Speaker 1:What about that?
Speaker 2:It was more like, common patterns and how to improve the Django experience when using HMX. Like presenting a bit of an introduction. What is HMX? How can you use it instead of using a REST API? And, let's say quick quick tricks to speed up development with HMX.
Speaker 2:Maybe in Laravel, but in in Django, like REST API, you define a view and it does all the actions. It delegates using the REST rules. But when you're working with, regular MPAs, you Django provides you with a create view, an update view, delete view. So you'll you'll have to declare them all at once. Yeah.
Speaker 2:But with HDMX, you don't need because you have deletes on every link form. So you can just have a single view that does everything like a rest, a rest view. And those kinds of tricks speed a lot of development time. And it was mostly about that. Next year, I'm thinking about presenting at Cengoku on Europe if they accept my my talk.
Speaker 2:Right? But more advanced stuff, some stuff like we talked about the components, like getting composition testing. Also a bit about what are the or what I believe are the right and wrong choices when tackling UI. So if you do an out of band swap, if you increase the area, what should you do? I have some thoughts.
Speaker 2:Let's see. Yeah.
Speaker 1:So I wouldn't mind hearing some of those thoughts if you got a minute.
Speaker 2:Yeah. So some of the common patterns, I've actually saw before. For example, out of band swaps. At first, we really didn't use them, but it's very useful for, for example, if you have a menu or a sidebar where something changes the state of the sidebar, you don't want to swap it. You just want to pass it with the response and it will swap the sidebar.
Speaker 2:Stuff like that. Small tricks like those, decisions on complex UI. When is it enough? I've had, let's say a small stay at a company, that I guess had haunted me because of HMX. Since there are, very few of us, I only spent there 1 month, but, I saw a bit of what can be, the hypermedia approach, gone wrong.
Speaker 2:Interesting. Because the the it it was mostly Vue developers and Django, and they were used more to, I guess, progressive enhancement, if you could call it that. So, taking an MPA and giving it a little bit more interaction.
Speaker 1:Right.
Speaker 2:And sometimes you add so much client side, interactivity, that they will just dump all the all the context into Alpine and make a lot of Alpine calls. And the HTML got way too verbose and small partials like using an MPA but swapping the entire page instead of small partials, small components like like you said. And, at the time like that, I didn't saw a lot of promise on the using htmx on that environment. So it was something that I didn't like. Coming from a company that used HDMX intensively and add a lot of projects like in production that worked perfectly.
Speaker 1:Right. But, yeah. Interesting. So let's see. So it seems like just like as an overall kind of like thesis, you know, your experience with h tmx has been like overall positive, and, like, you you like to kind of take, the MPA and expand on it.
Speaker 1:But in your sort of mental model of it, once it reaches a certain level of kind of client side interactivity, it would be, you know, better to kind of start moving into, you know, a client side like a more component client side type thing or or at least that's maybe how you've how you've seen it so far.
Speaker 2:I will don't say like that. I would say like, when you're starting to to work with HMX, one thing to note, and I guess, by watching Carson's interactions and, and reading, all all the notes he has on this website, it's the hypermedia way. Like, you're you can make, let's say, a fake SPA, with the hypermedia approach. You can just, load everything you need at startup and then just swap partials or components. But the problem is that if you don't follow, I think that philosophy, if you treat the TMX just as a enhancer and, as a or thinking of it like, I guess, a client side framework.
Speaker 2:The example I said, like dumping the entire state on Alpine and just let Alpine do everything. That's not the intent of the use for Alpine.
Speaker 1:Yeah.
Speaker 2:That's that's like it's it's not the thing about using or reaching like a limit. It's the way you use it. So if you use it right or wrong, I guess right or wrong depends on the person you ask. Right. But in my way, it's like it was a mess.
Speaker 2:And, I call it type, I call it hypermedia approach, the HDA, approach because it seems to work well. But of course there are limits, let's say, where you really need an SPA. But I guess, like, there's you can mix and match, like I said, with web components. HTMX 2 has improved the compatibility web with web components. So view transitions also some new features that are, I think, good for us HMX developers.
Speaker 2:But Yeah. Yeah.
Speaker 1:Yeah. Yeah. I've I've been really kind of, you know, it's tough because I'm still I'm a I'm a working developer here so, you know, I get to I get to experiment and do fun stuff, you know. I'm lucky to be able to do that sometimes, but, you know, it's not something I can do, just all the time. But, like, I I kind of can't wait to get a little deeper into the view transition stuff, with the CSS because my sense right now, is and I've done that as well where I started to kind of bring in alpine, and, you know, this was kind of one of my I'm like, okay, you know, I like Alpine.
Speaker 1:I think it's it's clever, and it's by the same person who did Livewire. So there's some sort of, you know, hypermedia sort of and like you put your attributes right there. I get it. It's nice. But the problem that I've had was the same problem I had with Vue, is you're still kind of working you're converting everything into this virtual DOM, and just kind of showing the results of your sort of front end calculations and stuff like that.
Speaker 1:And my experience now, the more I've done that with h tmx, is the more that I'm calculating with alpine with Vue, you know, with Vue on the front end in the virtual DOM, the more time I spend in the virtual DOM, the worse the overall mixing of the 2 is. It's like, and I think maybe this is what sort of the hypermedia part of the HDA hypermedia driven approach in my mind now, I've been using less and less alpine. And part of that is, I think, this view transitions, you know, the stuff that I really want from alpine is, you know, I don't know, you delete something and you get a little animation, you know, like it's deleting it from your front end also, and maybe it sends a command to delete it, but you don't have that sort of friction of, okay, I deleted it, and then something happens, and it I have to wait till the server comes back before I really get a new state. And so that's what I was sort of using it for. I'm more coming around to the idea that, like, I delete something, something happens, it grays out, you know, I get some disabled button, I get something like that, and then I do wait for the server.
Speaker 1:And there's actually advantage to that, to, like, that's what that's when you know it really worked, that's when you know something happened. So I think I've been going more towards that. The alpine in my code, I'm not gonna say it's 0 now, but I mean it's been reduced drastically, and I'm hoping to sort of use view transitions to fill that gap.
Speaker 2:Well, I, my my my take with Alpine because like, during a lot of years, let's say the first couple of years with HMX, didn't even use Alpine. I think Alpine and for most of the tasks I use, it's usually for states, maybe client state. Client state that is like hide tabs, for example. Because I think it if you have if you use Bootstrap or Tailwind, for example, Bootstrap as tabs that fade in and out declarative, like without any codes. While Tailwind doesn't, unless you have a component library.
Speaker 2:If you have a good component library, most of the need for Alpine disappears. Gotcha. And there are there are alternatives like, I Iprescript and and others. But they like like I say, very small complex stuff. For example, if you have a form when you cancel, you want to show, like, a message, you didn't save, what you wrote.
Speaker 2:Continue. Yes or no? That's an easy way to do it. But I'm gonna give you like an, an a trickier example. If the user has typed anything on the form, show that.
Speaker 2:If not, don't show it. Just cancel. That's like you'll do an Ajax confirm for the simpler case. But for the the other case, it will need like a lot of inline JavaScript. Yep.
Speaker 2:Or you can just extrapolate it to an Alpine directive and just use the the effects. They use effect like in your react on a React component.
Speaker 1:Yep. Yeah. Okay. So that's interesting. I almost wanna like compile my own list of like the times where something like that is necessary because, you know, I I think in my ideal development world, and I that's probably true, you know, it's like, I want to be able to not step outside of HTMLX as much as possible, you know, when I'm Yeah.
Speaker 1:Like, because I'm already I know Livewire. I know, you know, Blade. I know PHP. Like, I'm very I feel very comfortable in this world of the prog the code I'm writing, and the fewer kind of things I can you know, right now it's like adding HTMX has removed a lot of other things for me. Like it's made it.
Speaker 1:I can build sort of these, what I feel like are really nice fancy UIs, without needing to bring in too much other stuff. And I've really appreciated that about it. And I've added it to some really old projects, you know, projects started in 2012 that are still running on the internet, and now I can add fancy things to them because I don't need to update all the versions of everything, and, you know, it's all compatible. So I think, like, I really appreciate that about it, but I don't want to, you know, I guess, like, I don't know if you have any any thoughts on this or or if there's like like, what's your ideal situation with HTMLX? Like, do you feel like we should always kind of keep in mind, like, a some front end tool, whether it's Alpine or Svelte or something else, or is there an HT is there a version of HTMLX, that kind of handles that stuff, or do you feel like those are a little bit incompatible and you should need, you know, a front end version to to go along with it?
Speaker 2:Like like I said, if if you have a lot of client side state, you can do it, h t m x, all point, or another similar solution. But you're gonna have a massive massive inline scripting or a lot of swaps that will introduce a lot of latency. Sorry. A lot of requests. The, I would say so far it's the the that's that was the limit of htmx.
Speaker 2:I think with time and with improved template, templating systems with, more more maybe like like we've seen, like, focused in hypermedia entire frameworks, Maybe that will go away. But, I would say, like, the the limit so far was the client side thing on my experience. Like, I saw the other day using, was it WebSockets to constantly updating the page using hypermedia.
Speaker 1:Oh, oh, yeah. This was this, the Delaney?
Speaker 2:Yeah. I think so.
Speaker 1:Yeah. Yeah. So he's using the server sent events. Yeah. Kind of an event driven approach.
Speaker 1:Opening, you know, opening the request but never closing it, and then having it just return data over that, you know, over that open request. I still haven't tried it.
Speaker 2:Yeah. But an approach like that, like, it seems like it could be because if if you're constantly connected to the server, there is basically no need for client state. You're always in sync. I think that we'll we'll get to something like that probably, and it will eliminate most of the problems on the client side at least.
Speaker 1:Interesting. Yeah. I mean, that was Delaney's sort of argument as well. You know, he started with HTMX and is and kind of built his own DataStar, system, DataStar dot dev to sort of solve that problem of of not needing to constantly pull or, you know, not needing to go to the server every time it's like, you know, you you just sort of have a connection open with the user and you can the server can send whatever it wants. Which
Speaker 2:Yeah. Certain applications are I can give you an example on my freelance stuff, acquire a car washing, booking application. So people book, during the day. Right? And people go to work, they leave the laptop open with the bookings there.
Speaker 2:And my current situation, I'm not using h t m x actually on that one, It's just pulling every 30 seconds for new bookings. Yeah. Having that direct approach, like where you are constantly refreshing the data, I think it's it's the next step, at least in some environments. Yeah.
Speaker 1:No. I mean, and I I was I'll just say completely convinced on the speed, by him. You know, he when he was talking about the way that kind of works and the efficiency of it and the speed you get, like, that's kind of the to me, you can get that sort of SPA. You know, you click something and an event happens and it sends that to the server and then your your stream is updated of stuff. I my questions with that and, like, this is just my own not knowing how to do it yet, is, like, how easy is you know, right now if I couldn't replace my whole app with a setup like that because I've got all these routes, I've got all these views, the structure is just totally different.
Speaker 1:I'm not using events, you know, I don't have server events, I don't have an event bus, like those are concepts that I think, you know, obviously they have these huge benefits, but they're not how any of my apps work right now. So, you know, I don't see it realistically for myself as replacing those yet, but I it almost seems like if you could take rather than taking a component like you're talking about and using Svelte, if there was some HTML server sent event solution that opened up some component and then allowed you to kind of stream that from the server and and handle events, maybe that's something that's
Speaker 2:I think I think that depends a lot on more on the back end framework than on the the HCMX side. But, yeah, like you said, that's I think completely different architecture. The way of doing things will be a lot different. And it's a new approach, but, maybe it's not well developed yet.
Speaker 1:Yeah. I mean, it's interesting because I, you know, I only sort of recently started hearing about event sourcing and, which is I guess what this is called, you know, some of it and that like the theory. I do like the theory of it, you know, it's like you just you you keep track of all the events and then you sort of decide what each event does to your site, and then you send that out to the user. Or you update your application or your database, you know, based on those events. But it's such a it's such a paradigm shift in this sort of way that that apps are generally built that, you know, I'm not quite ready to I don't quite see how I can implement some of that stuff yet, but I am intrigued, you know.
Speaker 2:Same. It's a very interesting concept, but, I will say it's not like HTMX on the let's first couple of years was was just a concept, I guess. Not maybe on small projects, but are on real companies, real big projects was just a concept. And it eventually went, to, I think, a good way because, like I said, our take on h t m x when I when I was at the company was weird at first. This just seems to paste HTML blocks inside the what is this doing.
Speaker 2:But after, like, we don't need to do an entire API, serialize everything. Just gives us what we need. And after testing it and like, like we we talked about view transitions, the support for WebSockets, I think the the future is is quite bright.
Speaker 1:Yeah. I mean, you know, I've been asking you about the limitations. And so we've been, you know, we've been talking about the the parts of HTML that it can't do a lot. But I mean, the reason I'm even talking about it is because for me the parts that it can do, have been incredible and have kind of taken over, the way that I'm building applications a lot of times. And, yeah, What do you think, like, I don't know if you have any any thoughts on this just off the top of your head, but what do you think, like, big picture, what is the h t m x community kind of is there anything that you feel like the community or the, you know, is there anything that's missing that you think the community needs or that would be helpful for people starting out with HTMX or, you know, something along along those lines?
Speaker 2:I I think, like, the the problem with, with things like that is, I last year, I believe, I ended up doing a course for full stack web development.
Speaker 1:Like taking a course
Speaker 2:or a crew No. No. Giving a course. Giving a course. Yeah.
Speaker 1:For for,
Speaker 2:college students. So they have their web development classes, but they don't get the full picture like infrastructure, like, developments. You need to hear
Speaker 1:it from somebody who's in the trenches every day.
Speaker 2:Yeah. Basically, something like that. And it was hard to to to to show them, like, it wasn't a main part of the course. Right? But, in the end, like, I I show them, like, we I'm teaching you guys, like, how to do the front end APIs.
Speaker 2:But there's another approach and it's hard to to show. I tried to show them, like, the way HDMX benefits you not having to do an API since you're not doing a mobile app, just a web applications or a website. I think the message is a bit hard to pass, especially for people that have touched, front end frameworks. I hear that some students go straight to React. They don't even almost know vanilla JavaScript and they'll go straight to React or Next.
Speaker 2:And they lose a bit of concept of how a backend works. They just have endpoints and they know that the endpoints give them data. And I've seen some people work like that. When I started doing web development, I was still in college. I started with Vanilla PHP doing PHP database access, like everything without any framework.
Speaker 2:Then I switched to Django. So I guess I've taken the routes to know how it, how it is, like, from the start to the end. I know the entire path.
Speaker 1:Yeah.
Speaker 2:And, I think the that's the issue with HTMX, I guess, is, also the limitations and trying to to show people that are used to the SPA approach that maybe there's another way. I guess that's the message that, Carson needs to to give with with his memes.
Speaker 1:Yeah. I think he yeah. And he's been doing, you know, I think he's been doing a nice job talking making the case that there is another way, which I, you know, I probably wouldn't have never heard about it if if, he wasn't on Twitter and stuff like that. So Yeah. But yeah, I think you're right.
Speaker 1:It's like just that big picture. The new the younger developers, you know, didn't sort of start from the back end. They're they're starting where in their their mental model of the web is a client side app with an API, you know, base Yeah. That you with endpoints. So kind of getting getting a introducing another mental model is difficult.
Speaker 1:So it sounds like
Speaker 2:I'm I'm relatively young. Right? I'm 26, but, when I when I was in college and learning web development, they still learned they still teach us like XML, HTTP requests. Although fetch already exists, stuff like that. But nowadays, like, if there's already learning directly React or other frameworks like that, I guess they don't even get the picture of how the DOM works and what kind of interactions is done, like in an HTTP request flow, some things like that.
Speaker 2:And I think it's it's one of the challenges for HTMX that ends of because it's a very radical approach to the standards. I guess big companies, can be a bit skeptical about taking a risk on switching something to from from, React to to h tmx for example.
Speaker 1:Yeah. Yeah. And I've got the sense, you know, if you're looking for something really slick and, you know, it's easy to find react examples, you know, you can find sort of react component libraries, you can find, apps made, and, and I think, you know, that's I've also been kind of on the lookout and and I've seen some that I really that are really good, but, I'd like to sort of, you know, see more kind of here's something really cool built with HTMX, just because that sort of inspires people. It gives them some trust, you know, that this is possible. So, you know, so I saw it.
Speaker 1:I've sort of thought of it as like, you know, more examples of stuff, and specifically stuff, you know, I think there's a natural the crowd a lot of people who are part of the h you know, who are using HTMX are maybe a little older, and and so some of that retro style kind of appeals, and I think Carson's like that, and I'm a bit like that too. I really don't mind a lot of the sort of retro web look and feel because I feel like there was a certain amount of utility to it. But, you know, for getting more people on board, there's no reason you can't have a more modern look, you know, to an HTMX app, you know.
Speaker 2:Yeah. Like, like like we talked to, if you transition to API, the the SPA feel. I think that's one of the the perks of the edge the hypermedia way is you can build, an SPA, sort of SPA. Like if you use the Ajax indicator well, the transitions, the CSS animations, if it is polished and done well, it can like for most users, it will pass as an SPA.
Speaker 1:Yeah. And you don't get I mean, SPAs have some trade offs, some negative trade offs. So it's like you can get the SPA look and feel, I mean, in my opinion, without those sort of negative trade offs of having to switch all your auth and all your kind of client side routing. And, like, there's a nightmare of data, you know, issues when you try to duplicate everything on the client side. And people in the SPA world are just kind of used to that as like, oh, yeah, that's just what you have to do.
Speaker 1:It's not easy and it's not fun. And it's like, you can just avoid that.
Speaker 2:Double the problems. Double the code, double the problems. And like, especially for small teams where a company can't handle, like, or most of the work is just back end. HCMX revolutionized like the way of thinking.
Speaker 1:Yeah. No. And I mean, it's like exactly you said double the problems. It's like every single validation you're doing, you've got to do it twice. Like you're gonna do it on the server anyway.
Speaker 1:So why not just like, you know, just do it once and be done with it?
Speaker 2:That's the problem of, like, I would say regarding the teaching and the showing like the HMX is that some concepts are getting lost. Like the server does the validation. The server should be the source of truth. Like anyone can go inspect, go to dev tools and change stuff. And HMX bypasses everything because you you start the state on the on the server.
Speaker 1:Yep. Yeah. Excellent. So yeah. And I guess, you know, anything else you kinda want to plug you.
Speaker 1:So you you may be doing a talk. You've submitted the talk for the upcoming Python or upcoming DjangoCon EU.
Speaker 2:Yeah. They haven't opened, the submissions for Okay.
Speaker 1:Okay. So you're thinking
Speaker 2:for the next year's DjangoCon. But, I'll try to to have it done the next few months. And, if another PyCon, I don't know, some maybe European country, opens the the call for purposes, I'll probably also submit there.
Speaker 1:Great. So if you have any videos or anything like that, any like blog posts, links, you know, send them over and I'll I'll include them, along with the show notes. But yeah. Sure. And and the next one's gonna be kind of on it.
Speaker 1:If you do, you know, do another talk, you're thinking it's gonna be sort of advanced HTMX, patterns.
Speaker 2:Yeah. Yeah. Because I, I saw a lot of, my first talk about HTMX. I gave a small talk about Django forms, but, my first big talk was about HMX, more of an introductory, stage. And I think most people that go to conferences already heard a lot about the introduction to HMX and really want to know what happens in the trenches.
Speaker 1:Yeah. They wanna know once you start using it, can this really do what what you need it to do? Yep. Yep. I like that.
Speaker 1:Awesome. Well, Lucas, thank you very much for for joining today. I really appreciate it. Thank you.