HTMX: Frontend Revolution

Hi and welcome here at the Django Conference US 2021. I'm Thomas Güttler from Germany working for DScript. And today I want to talk about HTMX Make Web Development simple and fun again. So this won't be an academic, too detailed or dry talk. I want it to be personal, opinionated and fun. I studied computer science roughly 20 years ago, and finding the right front-end framework is really hard today In the past, things were much easier since you had less options to choose from. 1999, I wrote some simple CGI scripts with Shell and Perl on Linux. It was simple and fun. Not fun were the languages.

Perl was ugly, Shell not secure and not reliable, and Java and C<unk> too complicated. 2001 I found Python. This was fun, easy to read. 2008 I started to use Django and I don't regret this since 13 years. I have seen a lot of hypes coming and going, to name some Perl, XML, XSLT, Java Oplets, Macromedia Flash. And I am deeply relaxed and guess that some things we love today will be called deprecated or technical depth soon. In 2014 I came across Angular and I thought, wow, that's the future. The server sends JSON to the browser and you can build real applications.

But customers kept us busy doing the things we did before, Django with some jQuery. So I did not really use Angular in a day-to-day basis and I somehow stored in my brain, JSON is clean and HTML is dirty, but this equation is completely uh bullshit. But more on this topic later. Six years went by in a flash, Angular is not dead, but if you can start from scratch, it is very likely that you won't use Angular today. In the picture you see the Stack Overflow tech trend and you see clearly from the years 2013 to 2021 that Angular is in a big downtrend today. Last year I thought hey let's look at the modern way to do web development with front-end

tools again and I looked at React and View. First I played around with React and you see some codesnippet here, and somehow I liked it because it was a mixture. So there is HTML and there is code and it it is combined. That's something I like because as a developer you can change all uh moving parts at in one place. It's somehow a little bit like PHP. But uh like PHP executed in a browser. Then I had a look at View, that's nice too, a little bit more clean and and I think both ways are great if you want to do a web-based real application. But somehow I did not enjoy it

because you have then two parts, you have the back end and the front end and it does not feel very um simple and straightforward for me. In 2021, so this year, a friend told me about how she manages her work. She has a vegan lunch service organized in Excel. It was a mess. Up to now the people ordered via email and WhatsApp and the Excel sheet was edited by her for every order by hand Since it was a spare time project and not for money, one thing was important for me. It should be fun. I want to help her, but on the other hand I need to love the technology stack and that's very different from a business context.

I knew I will be coding in the evening after the kids went to bed and this means only 30% of my mental energy will be available. So it was very important for me to reduce cognitive load. So this is my spare time project and I had far too many options. Analysis, paralysis. So first I created a list and then a spreadsheet of all my options. For the back end it was easy, I want to use Django, but for the front end, hmm, I was not sure. So I don't get paid by the hour. I want frontend and backend to be easy and I don't have a frontend team so And nobody says to me, hey Thomas, use

tool A for task B, so this freedom of choice is sometimes difficult. So I had the front end blues. I still haven't found what I'm looking for. So I sat down and relaxed and said Ummmmm. So Thomas, what do you want? What do you like? First of all, I like the Django Forms library. I think that's a cool way to create HTML forms on the server. And then later. validate the user input which you get from the browser. And I like the Django ORM. I think that's a cool way to work with the database. I like HTTP, HTML and CSS. And I want good web

vitals or fast page loads that's what I want and JavaScript I don't like it so much And then the next question is, what do you want to improve? So the full page reload after submitting a form this post redirect get pattern Moo no, I don't like this. I think that's outdated in the twenty-first century, no. And jQuery, mmm, no, no, no, that's outdated too and Do it yourself, so write a JavaScript library for submitting and reloading snippets. Ah nah, I don't think that I'm the right one to implement the JavaScript library So let's paint a picture of what's on my mind.

So I have one page and on this page there are several parts. So we have here part one, part two, part three. And I want to be able to update each part on its own. So for example, part one could be a news ticker. Part 2 could be a complex form with a lot of input fields and part 3 could be a chat or something like this. And if you paint this picture to somebody, then you get the answer immediately. They will tell you, hey Thomas, you need a single page application. But wait, wait, wait. Thinking fast, thinking slow, let's wait. I have several pages.

I have several pages and each page should be some kind of interactive I don't have one page, I have several pages. And if you reject the modern front-end frameworks, people start to argue they will tell you, hey, form validation. in the client side is great you can do this with javascript but wait wait wait wait wait I need to validate the data on the server side and evil hacker could send me any kind of data and working around the client-side validation. So that's Given, I need to validate on the server and if I do so, hmm, it's additional work to do the validation on the client side. It makes no sense for me.

So and HTML5 has already some cool stuff so you can do some minimal validation on the client side. And yeah, maybe I will later add some validation on the client side. Some people argue hey that's great, so you can write JavaScript validation which gets executed on the client side and which you if you use JavaScript on the server you can use the same validation there and but yes of course but somehow for me that's not Does not make big sense. I have my Python Python on the server side and I really am happy with it. I'm forced with it And it makes no sense for me to use JavaScript on the client and on the server.

No no. You can do it if you want to, but I won't do it. And the next big hype is server-side rendering. I looked at server-side rendering in React and View and yes, it's possible, it works, it's fine, and but all this hydration and rehydration No no no it does not make sense to me. I want good web vitals and of course if the server sends HTML directly to the clients that's super fast. You don't need to load JavaScript libraries to get the first page. So are there no alternative to server-side rendering today? So I searched around and tried to find an answer and I came to this page. It's from Google

about web development, about very um basics. It's called rendering on the web. And here you can see five columns. And the first column, that's a very old traditional way of web development. So we create HTML on the server. and sends this HTML to the browser. And on the right hand side, this column is full client side rendering It's about the uh modern React or view-based applications. And if you read this article, um then at least I think the first column, the old way of doing web development, has a lot of benefits. So I still have the front end

blues. Am I too old? Am I too stupid? Am I maybe too lazy? Don't know. BABAM and then comes the revolution. By chance I came across Unpoly. A big thank you to Henning Koch, the author of this library Unpoly. He created a really cool comparison where he compares the page speed of Angular with his approach. His approach is sending HTML fragments over the wire. First I was unsure, isn't this considered dirty? what will people say if I go this way? Fragments over the wire is a real revolution in the truest sense of the word, because it means to evolve to something which has been the state in the past.

It took me some time to get the useless equation JSON is clean, HTML is dirty, out of my head. There are things which are clean. HTML, CSS, SQL, Python, all these things are very cool and clean. Analysis paralysis again. Which fragment over the wire framework should I choose? Unpoly, Hotwire, HTMX? I was meandering forward and backward. But the cool thing about spare-time projects, there is no pressure, no deadline, you have freedom. you can do relaxed decisions. In business context, this decision would be much harder. There's a deadline and you need to convince co-workers, an employee or client

to try out something new. That's sometimes really hard. So I was lucky, I had the freedom of choice and my choice was HTMX. So again, this picture I have one page and several parts on this page. And now let's have a look how partial page updates work with HTMX. So you have some plain old boring HTML. Here you have a button and some extra attributes. These attributes are new, these are from the HTMX namespace. So they start with a prefix hx. Hxget here is an URL and a swap method, for example

outer HTML. And if you press this button, what happens? The library accesses this URL, so HTMX makes an Ajax call to this URL, patches some HTML fragment. For example this simple div here. This is a response from the server. And this snippet gets inserted into the DOM inside of your browser and you can define a swap mass method for example outer HTML So this means you have a button here and if you press this button this volt button gets replaced by this simple div.

And this is the basic way how HGMX works and this basic pattern yeah makes a lot of things possible. So once again, how does it work? First step, the user clicks on a button. Second step, HTMX receives the click event in the browser. Step 3, HTMX, does a HTTP get opposed to the URL. And then the server sends a fragment, also called snippet, to the browser. and HTMX merges this fragment into the page. Yeah, that's it. And while creating these slides I realized that HTMX is somehow different

to other ways of web development. It's declarative. And that's something I like. HTMX is declarative like HTML Excel itself. HTMX is declarative like CSS. Like SQL is declarative like the Django admin or maybe like Terraform or Kubernetes manifest. So declarative is somehow um yeah a very professional way of working and doing things Here are some facts about HTMX. HTMX is written in JavaScript so that you don't need to write JavaScript anymore. It works with every language on the server side. This means you can use Python, Go, Rust, whatever you want on the server side.

The library is very small. and the initial page you send from the server to the client usually usually just contains HTML with some additional attributes. So this can give you very good web vital scores, because the largest contentful paint measures the loading performance. And since no JavaScript is involved during this loading, the LCP score is usually very good. Because you only need the HTMX things if you have some kind of interactivity. But the first load is completely without HTMX and this is then very fast. So let's have a look at some examples here.

And all these examples are available online on HTMX. org examples. Let's have a look at Click to edit. So let's jump to the demo right away. We have here a first name, last name, and an email address And if I click here, click to edit, I suddenly have a form. Now I can fill in this form and I can submit this form and that's exactly what I was looking for. So we have a part on this page and this part is interactive, that's cool and all these other things like scroll position and so on stay the same. Hmm, that's what I was looking for.

And the cool thing is that All these examples have this show here and there you can see a log. So you can see what happened behind the scene. So at the beginning we had an initial state, we had a div with an Ajax target of this and a swap method and we had a button and this button here is Ajax get and then URL and if I click this button here click to edit what I did then HTMX does an Ajax call to this to this URL and fetches what it gets there and he and HTMX gets in fragments there. So

the server size Sends HTML to the browser, but not a whole HTML, it's just a fragment. So let's have a look at the second step. Set the response from the server. And in this response you see this form here and you see there's no HTML head tag, there's no head or body tag, it's just a fragment. it it it's not a json or something like this it's just plain HTML it's an HTML fragment okay and this is a form like You know it, it's with the input type text for example here and this form here has age put. This means if I submit this form

HTMX sends the data via HTTP put to this to this URL. Okay, this way I can update the state on the server. And then the server sends me some data back. For example, roughly the same div again, but this time this time my daughter is in the div here and that's exactly what I was looking for. It took me some time to find it really several weeks until I uh found the library I want to do my front end work with and now I found it I'm very happy

so So let's have a look at our second example here, cascading selects. I guess most developers already implemented some kind of cascading select It's quite straightforward. So you have first the first select and then the second select. And if you choose for example Toyota in the first Then the second one updates and now you see only these options which correspond to the this First one. So if I choose BMW here, send the model list updates to BMWs That 's very simple and straightforward. And the cool thing is that you don't need a single line of JavaScript to implement this here.

So HTMX is very flexible, also it's quite simple. Let's have a look how it all works. You have the initial state Here it's in select and here 's this hx attribute get. So if you select something here The this URL gets called and new models are fetched from this URL and this time the HX target is a different one, so not This select gets updated, but the second one here this with the ID models gets updated. by this target target selector.

Yes, and that's all you need to implement cascading select It's very straightforward, it's declarative, no single line of JavaScript on your side. I like it. So let's have a look at our third example, infinite scroll. So how does it work? No no let's wait, let's have a look at it in action. So I scroll down and you see this loading indicator again. I scroll down. I see the loading indicator and new data get fetched from the server. And how does it work? The magic is behind a HX trigger revealed. This means

as soon as this HTML snippet is visible and so for the user, then it triggers and this HX get URL gets called The server sends an HTML fragment to the browser and their HTMX inserts and swaps this fragment into the DOM and here's a method After end. Okay, that's all. So the trigger revealed happened. The server sends data to HTMX. HTMX inserts the new data after end So again, no JavaScript involved,

it's just declarative, it's straightforward and it's very simple. I like it So let's have a look at our last examples, CSS animations. Last let's have a look at the demo first. So we have this button here and I press it and the button fades away Isn't it cool? And it works very very straightforward and simple. You have this CSS class on this button which is called Fade Me Out. And then you have the usually usual HX attributes, for example, swap

the outer HTML. And there's something new. This here. This means the swap should last one second. And during this one second, HTMX um adds an additional um cs class to this to this button and we can do some css um with this special um class and the special class is a um given name and HTMX swapping gets added to this existing CSS class. This means this um selector here Matches during the swapping phase. And now we have the possibility to do some CSS

transitions during this swap. So we have opacity zeros, this means At the end it should be completely transparent and you can do any kind of CSS transitions you want to for example ease out but this ease out and so on says that's CSS transitions that's not HDMX the HDMX part is only this adding the this special class during this web phase. So yeah, and that's all that is needed. So the transition should happen on the opacity and it should last one second. At the end it should be zero. Yeah, and it's so straightforward and so simple so that you can do really nice CSS

transitions during um your your your web request during your ajax calls to the server yeah very straightforward I hoped you liked it So we are here at the Django conference. Up to now I only talked about HTMX. So what does HTMX mean for me as a Django developer? So I changed the way I developed software with Django and HTMX because now I write a small method returning small fragments. This means function-based views make more sense for me. So I switched from class-based views back again to function-based views. The next thing which

changed in in the way I develop is that I use format HTML now again. It's a very cool method of Django to create safe HTML strings directly in Python and it's very um It's like locality of behavior. So all the things I want to change are in one place. I don't need to switch between the Python code and my template code. um I have the HTML and the Python in one place in one file and this is um very natural for me. It feels easy, it feels like very yeah fluent software development.

So I created a small naming pattern for me to better understand the code and I want to show it to you So I have three kinds of method, and the first kind of method is a function-based view which returns a whole page. So this means this is an HTTP response which contains HTML with an HTML tag, with a head tag, with a body tag and so on. And to make this more obvious that this function-based view is such a view, I call it foo underscore page. So I use this suffix here. page to make it more visible and this returns as I said a bold page

and the URL is then called just foo here. Okay That's the initial page. So usually the first page which gets opened by the user and then later From this page I do this um callbacks to to get some updated fragments or Things like this like we have seen in the infinite scroll example, these method which return fragments I call this like this, I have the name and then underscore hx. And this means for me, okay, this function-based view returns a HTML fragment. The URL I call it the same.

So here you see the HX and I think it's perfectly fine to leak this information into the URL namespace because the average user will see this one here, just the first page and only experienced users who open Chrome DevTools can see that these Ajax and these URLs get called via HTML uh H via HDMX. Okay, these two kinds are function-based views and sometimes I need a utility method where I create some HTML and this HTML gets used in several places in the function-based views and then I create a method with the

name underscore HTML and there I immediately see R that's a method which returns HTML directly So this is for internal reuse for me. Yes, I found this naming pattern um to to make my code more readable. If you like it, use it. If not, then don't use it. So let's summarize what we have seen. HTMX is great for. It's great for search engine optimization because you hit get a super fast largest contentful paint. Nee not pain, paint. So largest contentful paint. So the first page gets loaded very fast. So if you compare this for example to loading Gmail Loading Gmail for me means

there's a loading indicator and you get a real application with Gmail and that's not what I want. I don't want the real application, I want the page. which loads fast. So you can do with HTMX Professional Series, but maybe a little bit boring stateless web application like shops ERP system, startup-based frontends and so on. And I think it's very super cool to create an MVP so you get an prototype very fast and out. And later you can optimize and later you can add some sugar like client-side validation or something like this So what's it not well suited for? It's not well suited to create an offline first

application. So this does not make sense with HTMX. because HTMX um needs this server as central part so at least I have no clue how to write an HTMX based application as an offline application. Okay, then there are great interactive chart libraries out there and it makes no sense to try to re-implement this somehow with um HTMX. Of course these interactive chart libraries are written in JavaScript and then use them. No need to reinvent the real or it's the same for what you see is what you get editors, um like TipTap. They are available, they are written in JavaScript, they are great, just use them

and it doesn't just because HTMX is great for one thing does not mean it can be used in every case. So it really depends on what you want. If you want to write a real application which the user opens once in the morning and he keeps it open the whole day, then like Gmail, write a fat JavaScript front end. But if you want an application which loads f loads fast with the first page gets loaded very quickly, then HTMX makes a lot of sense. What made me think JSON over the wire and fed JavaScript frontends are great seven years ago One thing was this picture here.

Seven years ago I thought hey Angular is great because I create a JSON API once And then I use can use this API in two cases. I can use it for machine-to-machine communication and I can use it for um HTML frontends. But this is really nonsense and I will show you why So let's have a look at this picture. Again, I have the SQL on the server side and I send HTML directly to the user. And if I want a machine-to-machine communication, then I need to create a different API. I can't use the same API here

because let's have a look at improved daily and A B testing. For my user interface, I want to improve daily and I want to do A B testing and other fancy stuff And now let's have a look at the stable API. I don't want to improve daily here. I don't want to do A-B testing on a stable API. It's nonsense that you um save some time by creating by by by splitting front end and back end because ah you you Later I will need in machine to machine communication and if I split my front end and back end now then in ten years I save me three hours of work. That's nonsense So usually you create a user interface first and then focus on the user interface, make it a great HTML

user interface. And if you later later need some um machine-to-machine communication and some APIs, yes of course create some, but please don't put um the one thing onto or upon the other. This at least for me makes no sense. Now is this the end of my Odyssey? I don't know. Maybe it's just the beginning. At least I solved my front end blues for now. But the next question is, how to create HTML on the server side? At least I I want to work with Python. So in Python there are several hundred ways to create HTML on the server side, but somehow I have not found the

m my my preferred way up to now. I really like the Python F strings but and they don't escape the data which I put into the string so it's very likely that I I could get something wrong here. So That's up to now I use the Format HTML, but it would be really cool to have a mixture of Format HTML and F strings. Maybe like in JavaScript there's something called template rituals. which use these back ticks and this would be really cool if if Python would have these backstrings with the possibility to auto-escape the data Yes, that's would be heaven at least. Ah, but this would this is this would need a change in Python itself and uh I'm not a Python um

hacker, so I have not uh worked on the core up to now. Maybe someone of you has an idea how you could get something like these JavaScript template literals with bacticks into Python. This would be really cool, yeah So here's a link to my GitHub project called Django HTMX Fun. Check it out, test it. It's a very simple application. using this naming pattern I talked about and some simple um yeah Django application to demonstrate how how Django and HTMX could be used together. But there are several Out there, just google for it, Django

HTMX, and you will find several of these applications. Yo, check it out, have fun. Last but not least about my team, I'm from D Script, Germany Dresden, and we are developing web-based software projects with Django since 2008. So we know what we are talking about and we are looking for new crewmates. So if you are a developer and you like Django, yes, if you're looking for a job, please contact us. Okay, that's it. Thank you very much for listening and I want your feedback. Please tell me, is there something which I could improve? Is there something which was difficult for you? Please speak up.

You can contact me and follow me on Twitter or send me an email. Yes, I would like to hear from you. See you, bye!