The Truth About HTMX

in case you haven't heard yet htmx is the new trend turns out there's a lot of developers that don't actually want to write front-end code and I have a spicy take you might not expect from me I think that's a good thing let's get into it what is htmx Thunders and htmx I think it's important to first understand HTML specifically HTML templates for a long time back-end Frameworks like laravel rails and whatever's going on in Python land I'm scared to check nowadays these Solutions have all had ways to make an HTML template on the back end so instead of just writing HTML the traditional way you would write something like HTML with pieces inside of it that are template strings that come from your other programming language so you can insert a username or a profile picture URL but the templating language is the thing that gets kind of translated into HTML and that happens on the back end so if a change happens on the page it has to generate a whole new HTML page there's no interactivity Beyond links and forms and things built into the browser so if I want to have a button where when I click it it changes to a loading State and when it's done it's shows the thing that it did just in there without reloading the page you can't do that with any of these back-end Frameworks and as a result a lot of back-end Engineers who need to build an interactive UI on their front end have kind of been forced to learn react and other tools like it and this is where the spicy tape comes in I think a big part of why react gets so much pushback is because a lot of developers who don't want to use react end up feeling like they have to in order to do basic things like have a menu that opens up and has content inside of it have a send button that will let you update the content of the page without having to reload the entire HTML in order to adopt react you have to adopt a lot of things that might be really outside of what you're trying to do which is just make the new post appear in the feed and I think this is what makes htmx so magical it allows for people who are coming from a back-end background that wants to have a better front end do it without having to leave the language and the tools they're used to in the back end you don't have to adopt this whole new mindset instead of tools if you're coming from a back-end mindset before I go too much further quick brief on htmx the tldr is they wrote the JavaScript so you don't have to they let you and your HTML you send to the user put some additional instructions that allow the htmx to update things without having to run a bunch of your own custom code on the client this example here you have bound button to htmx host to this URL what this does is now when you click the button instead of that having to trigger a form or run custom JavaScript htmx's JavaScript will Traverse the Dom see that you bound this here and now when you click that button their JavaScript is going to trigger your back end on this endpoint with a post and the HX swath says that whatever it responds with make that the new outer HTML the tldr is that whatever you return HTML wise that's the new content of the page and this lets you on any element Define posts and gets and HTML swaps and that type of behavior was something you would have to write a good bit of custom JavaScript before the JavaScript so you don't have to now the best Stack video is a decent base example that's a fair point so you defined to Do's which calls an HTML jsx template not too dissimilar from react in terms of how it looks and feels to use but that's not going to be code that runs on the client that's code that runs on the server and it generates new HTML that gets sent to the user and then the slash posts with toggle here it finds that value in your database in this case just an object but you get the idea if to do then we swap the complete State and then we return that item swapped so now on the HTML for that item if we find it here to do item you'll see HX post is the ID for this post with that endpoint and now when that endpoint returns new HTML I'm assuming you're going to put HS Target is closest div so it's going to Target the div directly above and update it with whatever new HTML you send and the HX swap says where to swap it and now that's a full stack backend front end solution huge shout out to Ethan for providing that if y'all aren't subscribed I'll be sure to put his handle in the description of this because he's a legend and he's quickly going to become the biggest typescript focused YouTuber I think I need to pull out a diagram where you guys are going to want to kill me so let's do that I think we can agree there's a spectrum between the server and the client I have a video where I try to Define full stack and I did an okay job it's tough to Define because the spectrum is so weird and every person fits somewhere along it and prefers to spend time in one place rather than the other but if you want to have like really interactive application with tons of different user interfaces with page session times that are hours long like twitch you're probably gonna need to spend a lot of time on the client side but if you're trying to optimize every byte from every packet sending millions of like video packets all over the world you're spending a lot more time optimizing on the back end but there's also the space in between where people are experimenting making better user interfaces and generally building the interactions between the front end and the back end before we had a technology like next this felt very much like or front end was the small spot on top back end was this big spot on bottom and if you just needed HTML you could do that with a template and go to like here but if you needed more back-end stuff on the front end you couldn't really do it we had stuff like Firebase that's goal was to let you query whatever you need or hasara and stuff like that that expanded slightly here I'm going to call this the graphql era so the goal of graphql was to provide a almost like a translation layer like a standard between the back end and the front end for how these things in interface with each other and this was how we decided we would build applications going forward you'd have a back-end team at your company you'd have a front-end team at your company the front-end team would never touch the back end the backing team would never touch the front end and you had graphql this thing in the middle that would be the translation layer before then there was much closer relationships between the front and back end even when you were designing a rest API usually that was to the front and spec or the back end was defining it the friend was consuming it but they would have to interface a lot more with graphql in the middle you now had a thing that you interfaced with instead but that also made iteration a good bit slower it was faster than before where everybody was just shouting at each other all the time wouldn't it be nice if on front end I could just go to there or if I'm back end I could just go to here it's like if the concern of your company and it's probably the most controversial thing I'm going to bring up here most companies Focus does not need to be this whole thing most companies differentiate or the thing that is unique about them is a much smaller sliver so it might be that you have the best UI in the industry or it might be that you have the cheapest servers so you can scale in a way no one else can but very few companies are actually trying to cover all of this with Specialists so how can somebody who's specializing in the area your company's focused on like here scale down to the back end without having to become a specialist in that too as I said earlier y'all might think of me as a front-end guy but my history was primarily backend up until recently I didn't write my first line of react code until 2018. I was almost entirely backend up until that point I got into front end because I wanted to build better user experiences and help twitch with the website rewrite I ended up falling in love with react so much so that I kind of left back end behind and got really really focused on building good front-end experiences but then I started working at a different company where the back-end teams weren't as competent we didn't have the graphql layer between things and it was impossible to get changes out even small things like I couldn't make the changes necessary because the team was in Poland didn't sleep half the time it was nearly impossible for me to move and that's where next.js came in I'm going to copy this diagram here and go back to the old way so what I was building required a really really good interactive front end because it was a music group listening app it was people hanging out a room together listening to music together with avatars and [ __ ] it was it needed to feel like an app because it was it was a page that you were supposed to spend hours upon hours sitting there hanging out with your friends the back end was just a way for us to keep track of what song was playing and as such I needed more ways from the front end to get the data we needed to play the right song update the song playing keep everybody in sync and just build a good experience and when backend would make a dumb change like report the song name too early the expectation is I would re-architect the front end to deal with all of their bad decisions in our state machine and it was getting untenable really quickly this is why I started looking into next and the thing about next is that it takes this front and bubble which I'm going to rename now to react I'll call it react client because this was before server components anything's important to know like this is the react client this is whatever backend API what next allowed for was to go exactly as far as I needed it didn't bring me to like crazy database architectures to hosting my own servers and boxes but with next plus react and importantly Versa and serverless as well it became very easy for me to define the exact back-end functions I needed in my front end up location it let me as a react front-end engineer go exactly as deep as I needed to and then from that point forward rely on services so this would be things like versel things like AWS amplify things like super bass but next got me quite a bit further and then SAS could take over from there this was a magical moment to suddenly not have to think as much about all of the things we needed to build a good application to build the good experience for our users and to not need a dedicated back-end team with like eight Engineers we were paying way too much money and they still couldn't keep up with one Theo on the front end so once we also had a Theo going exactly far enough into back end and then three services that we would rely on top of it suddenly we could build and iterate the right thing for our users much faster and this also meant I was becoming more a back-end engineer and honestly I still consider myself more back-end than front end especially after next because I spent all my time thinking about infrastructure and services and how to orchestrate these things in a way that makes it easier to build and iterate on our applications and this is where htmx comes in I'm gonna copy paste this top half one last time before we react back end already kind of do this with the templates it could go a little bit further but as soon as you needed interaction you would have to pull something like reactant to have your page that had content automatically update there were tools like Livewire and turbo that would allow you to send HTML down to a small JS bundle on the app to rewrite whatever content was on the page as though it was doing an application style like update even though it was actually doing was sending a whole new HTML file from the server is how things like GitHub works is how things like the hey.com email app work and as good as it can be to have everything based on your back end it's still rough because you have to wait for the entire content from the server before you can change anything on the client because the client doesn't know anything about how the user interacts it just sits there waiting for the server to send HTML and this is why if you try using the hey.com email app in like Australia it runs terribly Rich Harris has a bunch of content about this all of his talks recently especially talk about how important to just have good interactions on the client for this reason in particular so with just HTML templates in front I get this far with turbo or live wire or live view in The Elixir world you can get like this far goal of HDMX is to get so far that you don't really think about react as much anymore you're just trying to build an intense update experience where the average piece of content on the page changes a lot you probably want to write custom JavaScript for that still but the goal of htmx I'll just put this on the bottom here the goal of htmx was to extend the server so far that if your application's goal was to spend to here previously this range would have included react in it so if you wanted to have your application specialize and be a good experience in this range doesn't matter how good you are at back end you kind of felt like you had to adopt react or something like it and the result was a lot of developers who didn't want to use react falling into this zone right here and getting stuck with react and that's the thing that makes me so excited about htmx is that this box right here is full of backend Engineers who don't want to be here and they hate us for it the same way many Engineers especially like me pre-next I hated when I had to fight with the team to make change happen in this little box here it was miserable because this is not where our company's differentiator was our differentiator was in this area and I was stuck here in order to make things work and when I could SAS this part off and next.js this part off all of a sudden I could focus my effort where I cared about which was here htmx is doing the same thing from the opposite side for developers who want to focus on this part they want to make really cool back ends that serve things really well and they want the user experience to be good enough but their focus isn't the animation on every menu their focus is providing a good enough user experience and htmx makes it so they don't have to adopt react to get there for a lot of things and that's really cool so what do you think I know a lot of my audience is more fun and focused but that game's cool too and I think this will allow us to get along better with back-end Engineers I really feel like a lot of the hatred towards the tools and the people on the front-end side comes from a disdain for having to use these things to solve what are perceived as simple problems you shouldn't need to adopt react to update one item in a to-do list and htmx solves that problem really well I think the same way next makes it so we don't have to bug the backend Engineers as much HDMX makes it so the front-end Engineers don't have to be involved when you're making a decent UI for your complex service I see a very exciting future for htmx it does feel like the Natural Evolution of the old rails era what do you think are you more back-end or more front end is htmx interesting to you or are you going to stick with next tell me in the comments if you want to learn more about how I use next incorrectly for more back-end pipe stuff I'll put a video there all about that thank you guys as always he starts

Channel: Theo - t3․gg

Views: 168,024

Keywords: web development, full stack, typescript, javascript, react, programming, programmer, theo, t3 stack, t3, t3.gg, t3dotgg

Id: NA5Fcgs_viU

Length: 12min 27sec (747 seconds)

Published: Thu Aug 24 2023