The Truth About HTMX | Prime Reacts

I have some ground rules here people first off I want to let you know that I'm extremely biased one I hate working with react two I love htmx I just want to let you know that now so that no one's surprised by my takes here okay Theo's a nice guy we've had a lot of fun I've been to his apartment we've hung out uh we've gone to a couple conferences together I like hanging out with Theo but we don't see eye to eye on some things and this is one of those things that we probably won't see uh See about it so I'm curious I'm curious what he has to say in case you haven't heard I also have not watched this video yet so this is this is unwatched so I'm very excited about this so let's get going yet htmx is the new trend turns out there's a lot of it's not a new trend it's existed pretty much forever it's just now it's more convenient it's significantly more convenient you 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 by the way uh I don't mind writing front end code loving htmx does not have to do with or without writing front end code and I want to be real about that and I'll explain my thesis at the end of this we're gonna let let the man cook okay but I'll explain my thesis why I like hdmax better at the end we'll we'll get there though okay into it what is htmx thundersen htmx I think it's important to first understand HTML specific I think it's more important to understand horse heads that shoot lasers a piece but okay whatever typically 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 Django it's always Django it's always been Django it'll always be Django it's been Unchained for except exceptionally long time 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 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 yeah this is true but this was long before laravel and all the things he just said uh just like traditionally you would this is why PHP was so useful because at one point you had to generate an entire page to do anything and so that's what PHP was really great at it was like the world's most excellent HTML producer and so you'd use that that you'd be able to call into produce your pay page and replaced it that at some point jQuery came along with dot dot get and Dot post dot Ajax with an object that says post or get and it just changed your life right and then also now you have to start producing fragments right and so that is where things got all sorts of confusing because now you could make single page applications and it was okay I know you could do Ajax request before jQuery but let's be real okay no one knows how to use XML HTTP request object okay we didn't get it I never got it right you never got it right so stop stop pretending like you you were like some hacker man that figured out how to do HD hey XML HTTP request okay you did it you did not know you you don't know okay I want to have a button where when I click it it changes to a loading State and when it's done it 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 welcome to Costco I love you I forgot to turn off alerts I work at Netflix by the way foreign yeah this is where this is where I believe the shittiness started was actually this this concept right here what he's about to describe is when it all started which was when we started wanting the client to do something and the back end to tell you when it's done and we made the wrong choice and I believe htmx made the right choice we need to build an interactive UI on their front end I've 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 I'm going to take a slightly different spin my general problem is that people think to accomplish any of those things you must use react I'm going to go the other way around not that you use react to accomplish those things it's that people default to using reacts to accomplish those things they think that the only way to accomplish it is by using react which is just fundamentally skill issue right it's this classic skill issue that you think that one library is actually the way you do something when the thing the library is just a wrapper around the thing underneath it right I'm not saying it's not a good rapper I'm just saying to think that that is the way to do something that's bad and so you know it's just a way of doing it it is a view into doing something Jay diesel obviously being the best Tom's genius we all know Tom's a genius okay I'm not a genius Theo's not a genius Tom's the genius okay 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 I do I do again I do want to disagree with that uh you know I've been like I said I've been building this fun little little uh Conway game of life where I literally am doing a bunch of JavaScript right we're doing a bunch of JavaScript we're doing all this is pure JavaScript interactivity right here okay it's just it didn't have react but when I do the saving that's the htmx that's where htmx gets in is htmx is in between when I press save to go check out all my different saves which I haven't implemented yet that's all htmx that's doing boosting of links and all that to kind of replace the content not actually reload the page which you can see right here you know what I mean and so it's like the mixture of being able to do JavaScript when you need it and being able to produce that stuff and then using something that communicates how the page changes and having HTML as the state is what I really like I'm sorry I'm trying okay I gotta let him finish I'm not going to tell you why we're still going to do the diagram at the end sorry I just get I get too into things the deal Dr is they wrote the JavaScript so you don't have to they let you in 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 post 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 is 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 Auto HTML just simply means replace button with if that makes any sort of sense and so uh instead of so you have inner HTML which will replace the click me whatever whatever comes back whereas the outer HTML is the thing itself and then there's a whole bunch of other things you can do with swapping and targeting and all that kind of stuff it's very cool 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 for those that don't know what just happened there if you haven't seen the BET stack by Ethan it's very very good uh effectively what it is is it's going to be I forgot what the b stands for but we have htmx torso and then we have uh bun and express if I'm not mistaken I think I got that correct but effectively using react on the back end to produce all of your stuff but then using htmx as the communication from the front end to the back end template not too dissimilar from Rihanna 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 yeah HS Target is closest if the closest div is super cool like this is one of those things where you can actually there's a whole bunch there's like previous next uh closest walks up the tree so you can say where in the tree to do it and there's this whole concept in htmx called locality of behavior which I think is very important in which react completely misses meaning that your little template that you define has all the controls within itself to manipulate itself and that's it right the template itself has all the controls and it's just attributes for how to manipulate itself which I think is really really cool and so I've always been a huge fan of just like that kind of mindset it's very is very good yeah lob is a locality of behavior lob is really really cool so it's going to Target the div directly above and update it with whatever new HTML you sent 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 also a huge shout out for Ethan for saying learning Vim check mark let's go let's go Ethan 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 that there's a spectrum between the server and the client I have a video where I try to Define full stack and it 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 classic Engineers being on a spectrum classic classic 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 our front end was the small spot on top back in 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 five this I I feel like he's forgetting about that dot get okay that dollar sign dot get tell me that dollar sign dot get you did not try to do a bunch of stuff okay okay tell me you did not do a bunch of stuff right there um so much excite higher base that's goal was to let you query whatever you need or hasara and stuff like that that expanded slightly here I'm gonna call this the graphql era so the goal of graphql was to provide a almost like I like to call this the middle out era you know what I mean definitely the middle out era and my version was falcore by the way okay a best failed project of all time translation layer like a standard between the back end and the front end for how these things interface with each other and this was I don't know 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 that I've never worked at a company where this is true I guess I've all you know every company I ever worked at it's always been like front end doesn't just do front end but we also do like the middle end uh middle end being the place that like maybe there we have it like at Netflix they use the all right when I used to write stuff for the front end uh we'd have an API service Gateway so I'd call into these services that would eventually turn into requests to others you know to the actual other micro services at Netflix by the way just in case you're wondering um just and just if there's any questions about where I work I never either ah you know um and so we would do like some of this back end we didn't have the queel the graph wheel we had Falcor so we had to write all that um I don't know but I I see what you're saying like this this green area is a confusing area because it's the area in which the front end needs to work on to communicate with the back end but it does not exist on the back end it's like its own layer you know what I mean then there was much closer relations 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 and the front was consuming it but they would have to interface a lot more with graphql in the middle you now had a thing that you interface okay shut up with the with the Netflix it's 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 I think that helps having Rosy colored lenses with react if you didn't start until 2018. for all of us who started in more like 2014 the emotional toll that was using react since 2014 is very hard on on us and I'm still kind of slightly bruised from it um component did Mount you know still my favorite I just want to let you know component didn't mount on my heart okay all right on my heart doesn't help twitch with the website rewrite 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 just 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 and asleep half the time it was nearly impossible for me to move and that's damn Poland and sleeping half the time uh yeah I do think that if you don't have a good way to work I mean it's why this idea of a peer back end and appear front end makes no sense you have to have you got to have that middle out right you have to have efficient tip to tip uh you know Computing it just doesn't work that way it just really truly doesn't work that way that's where next.js came in I'm gonna 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 in a room together listening to music together with it was fm.tv called did the e be DJs right it was like something FM FM dot whatever turntable turntable.fm did he did Theo work on turntable that was really fun dude I'd get down on turntable oh no he couldn't have because that was 2011 or 2012. that I was going hard on turntable and he said he didn't start on the front until 2018. okay yeah so it could have been that turntable is so sours 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 back end 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 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 end bubble which I'm going to rename now to react I'll call it react client because this was before server components I think it'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 versel and serverless as well it became very easy for me to define the exact back-end functions I needed in my front end application 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 a 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 by the way I'm trying to let you guys all take this right I want you guys to all take this in I'm trying not to add too much flavoring here because I think this is really good to understand his perspective on how he arrived to his conclusions because I think it's very easy to miss this line of thinking I I don't I mean I totally understand this line of thinking I I you know in my head this makes a lot of sense but 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 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 by the way I'm so I know right now Ryan Winchester very angry right now right Ryan Winchester was like you have mystified Live Wire like I could feel it I could feel it coming in it's okay it's okay to 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 there's now things like GitHub work this 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 it is to have good interactions on the client for this reason in particular so with just HTML templates you'll probably get this far with turbo or Livewire or live view in The Elixir world you can get like this far gold Ryan calm down wherever you're at Ryan htmx is to get so far that you don't really think about react as much anymore if 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 in 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 your secret with react is that you're always angry reasonable reasonable all right we let the man finish cooking okay and that's the thing that makes me so excited about htmx is that this box right here is full of back-end Engineers who don't want to be here and they hate us for it the same way many Engineers especially like me pre-necks I hated when I had to say 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 sass 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 it's 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 front and focused but backend'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 which you don't need to just to be completely Fair you don't have to at all at all htmx solves that problem really well I think the same way next makes it so we don't have to bug the back end Engineers as much htmx 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 pin a video there all about that thank you guys as always peace notes okay so first off remember me the react hater what do I think is very obvious I think that there's a false dichotomy there obviously it's not react or htmx I think that there's plenty of other things you can do in the front end that don't involve it but let me tell you why okay I'm going to take a completely different approach and kind of explain how I view the old htmx uh world and how why I think it's good which I I would take my view of it very very differently and this derives from my frustrations notice that his his like how he drove why he thinks drove I'm not even sure if that's a word if you can pass tense derive uh derivative uh his his frustrations was because of his perspective on where the things were very upsetting for him right and mine are going to be the exact same things but different but I'm by the way Ryan Winchester really needs to get this out live view tldr all the dynamic elements on the page have an index live view pushes over websocket only the data that changed not the HTML X this change and then it's patched live all pushed from the server at any time doesn't need to be initiated by the client okay yes okay so it's it's a two it's more of like a two-way binding as opposed to a one-way binding htmx also has the same thing it also has server events and things that can be pushed from the server directly like you saw it with uh if you go on to twitter.com which is now known as and we search and we look for bad cop uh bad cop if we go to bad cop uh check this out right here this is uh Connect Four made with htmx using bash as your back end okay okay bad cop just loves bash okay just there's nothing to fight about that but here's the best part is that this is distributed um uh front uh red versus yellow and so meaning that like everybody can go play on yellow or on red and whoever clicks it first can do it uh but nonetheless this is kind of like a fully functioning thing that looks all nice and all that crap but it's done with bash right and that htmx right here uh so there is something kind of neat about that if you will um but I will like to say that there's one thing that's really upsetting here which is that after we get to this point yellow starts making some good moves here okay yellow starts making some pretty good moves uh apparently there we go look at that looking really nice right you know yellow's doing a great job and then yellow has this clear Connect Four and then proceeds to start stopping Red I don't know what's happening here I don't like what I'm seeing just just win the game yell yellow yellow why aren't you winning the game yellow just just put the gosh Dart piece right here yellow just put it right in your red what kind of choice are you making you're literally double you double trapped yourself because now you can go here or here good job blocking that but what okay you know why yellow did it clearly a five in a row it was the five in a row quit playing four in a row go for five in a row obviously obvious choice right there but nonetheless uh you can make pretty rich applications with HDMX there's nothing inside of hdmax that says you have to do things only on the server or on the client uh I know it is very very cool what bad cops doing I I love it okay so let me give you kind of like my general thesis my general take on why I think htmx is the place that I really really like and what I'm kind of more focusing on in general okay which is that I'm gonna use that kind of the same diagram just way less pretty than Theos uh with this idea of kind of modern web development today modern web development looks something like this where you have your server and your server contains the true source of State right and now what's happened is that we have uh or hold let me let me let me let me back it up this is let's start with web 1.0 days right so in in web 1.0 we had this and your client was extremely thin and it really just rendered out the content right it just rendered that's it rendered that's all it did and then at some point along the way we decided that we don't we you know jQuery opened our eyes date picker was the greatest thing ever written by Mark uh and we decided that you know what we don't have to do this anymore we can actually have a whole bunch of cool state to allow us to make a bunch of complex decisions on the client and so what ended up happening is we actually had two forms of State starting to be created we had this little front end state which represented the back end but it's like a not up to date or not complete view it's just what the view is we think it is but like that's it right it's just what what do we think the server has and this is from getting responses in Json so what ends up happening is that your server starts communicating educating in such a way where we're using an intermediate format to describe what the client should do and the client now needs to keep that state and react to it and keep it over a long period of time and typically this was done by Jason I think there was a small period of time where we made horrible life decisions and used to not just on um protobufts at some point would be great but nonetheless we did this whole thing and so now you have this this this problem which is that we have the true State on the server which we also have uh we also need validation on the server but then now all of a sudden we have to take the same logic and we have to put it on the client we now have state and validation on the client at the exact same time State and validation right and so then it starts growing and it starts growing and it starts growing and it starts growing and it keeps on getting bigger and bigger to the point where the state on the server and the state on the client are like these duplicities of each other and so the Natural Evolution is that you should just use one language to describe everything because that way your value station that exists on the on the server also exists on the client but here's the problem with that whole thing is that when you render you actually render out to something called HTML HTML is the state of your server it is the thing so that means you actually have several States here you have a state that's generated by the server passed down via Json it's either a diff of the state or a complete new state then you have the application cache which represents holding on to all the data and merging it all together having all these you know reefs biting and conducing and reducing and transforming and transducing of which most those terms don't even mean anything when they when they're used in this context and that now produces a new state in which is then rendered to the HTML so you end up going from a singular State back end that renders to a multi-stage state which is you have your true state of this uh the the true source of State the back end you have the intermediate at a certain time State you have the collected rendered State decision-making business logic State and then you finally have the HTML which is the representation of the client and server state so there's like this huge amount of just State Management that we introduced out of nowhere right like this is truest form of just State explosion and so it makes sense why react is trying to solve this by doing server components effectively what they're trying to do is they're trying to move this like intermediate server client State business all the way back onto this server and so that way you can program it from there and send it down right and so they're just trying to recreate the bygone days of your of this right here which I think is a fundamentally broken way of doing it is driving it again still from the client whereas htmx makes a different choice htmx is trying to say that your application state is the HTML you don't manage it the browser manages it you put on points of change within your state that can be changed you can have all of your fanceness you want to if you need to call out to JavaScript because say you want something that works like this where you can do some cool stuff like this which is just JavaScript running right now you can do that but when you want the state to change between the server and the client you purely use HTML as the form of the state and truly this makes it into a two-state item right which I think is which which is just way way better and so htmx has the true state of the server and then it just has a reflection of the state on the client it's just purely a reflection and I think that this is this is the better way it's like 1.0 but with all the niceties of 2.0 and none of the grifting of 3.0 so it's like it's like it's like together and so for me this is why HDMX makes the most sense is it's not about me not wanting to do the front end or the front end not wanting to do the back end it's about the fact that I have a singular place of State in which I reflect it out because I've spent many a many a many year working on caching caching is extremely hard I've gotten it wrong every effing time forever and ever forevermore and plus one I will get it wrong and so the fact that I can have HTML as the reflection of state of the server and have the server tell me when it's changes or I can ask it for a change and then have an automated declarative way to say how to reflect that it's thinking I've accomplished 95 of all things you have to do now obviously the Conway's Game of Life example is an extreme example where it only makes sense to derive this state or to generate the state from the client I wanted to see if this was possible it's clearly possible to do and it was not hard to do at all and so that's kind of how I look at it and I just don't look at it as a front-end back-end problem I think of it as a state problem and cash synchronicity or whatever you want to call it is extremely extremely extremely hard and so I just prefer the HTML the htmx way right which is to reduce the amount of places in which you make business decisions reduce the amount of things because that's the thing is you can use react on the server to generate all this there's nothing that says you can't use react go use react I don't care go do it I just think that it's more healthy for your brain and for the success of a project to have a singular place that this that determines the state of anything and you know you know how I know that this is this is completely successful is that we can have real-time video games sent down the entire State can be created on the server maintained on the server and played on the server and you are just simply experiencing that server and interacting with it and so htmx in some sense is like programming a live video game where your back end makes the decisions your front end is a reflection of that and uh obviously there is going to be some lag but the real deal is whenever I hear this like this argument right here uh I'm not saying a parkour it's not just you but like the idea that oh well what about offline and what about all these things first off offline is hard in anything offline is incredibly hard no matter what you do no matter how you program it no matter who's programming it offline is effectively impossible right it's just like it's just it's just the worst thing in the universe and so when you have hdmax offline doesn't make any problems when you want to update your state when you want to delete an item all of that every last bit of it is 110 required to go make a server request and the state that is updated is a reflection of the server that is why in today's world what you get is the worst form of it and this is kind of like I think this is actually a Capstone Point here I'm going to do this again this is why it makes total sense is that in our today's in our today's app what we do is that let's just say we have a to-do list with a delete button right and you press that delete button what ends up happening here well uh first we send down your list of items okay fantastic awesome I like seeing that makes me happy makes me makes me all very very excited did I get that where where is the arrow at am I doing the arrow correctly I don't know why I can't do the arrowheads give me the arrowhead right okay apparently I can't do arrows when I click this button I do two things right I greedily delete the item right I delete I delete the item and reflect future state or i j maybe better to say generate future state then I actually make the request itself to the server if the server screws up that's why you get these dumb little messages that look like this that look like uh like sorry couldn't do that but your State's gone right the elements have been deleted they don't show up anymore you're confused did you delete it or did you not delete it it's like this whole problem because now you've generated these multi-layered caching and caching is impossible so what do you do you have to refresh your page to see if your thing was actually successful or not whereas with htmx you don't generate future States instead you can say let's disable that to do item let's gray it out let's put something on top of it to say hey we're working right now oh it wasn't successful ungray it put the error message you can now try it again you can now try to redelete you now have the state all still in your application and it's still a perfect perfect reflection of the server it never deviated because it didn't make business decisions on its own it simply did what it does best which is saying hey interactivity needs to Halt hey we need the display that we're doing something we need to let you know that we're working and at the end of the day it wasn't successful here's your error message here's your to do you don't need the refresh good luck sir try again right and that's why I love that kind of stuff I love that kind of stuff because it's way better these future State generators that are this today's modern applications are horrifying they're always out of sync in some small amount and they're just like the world's worst thing ever okay then what's different from web 3.0 oh that was me just making a joke about blockchain um and grifting I thought it was really really great um yeah it's incorrect error handling I know but error handling becomes an impossible problem right it's really really really really really really really hard um yeah but 99 says yeah I know but that's the thing is Sam King you can still display that it's deleting you can still put a gray thing over it that people know that it's deleting like you don't need to actually remove it there's no benefits to either the person or the other side and I would argue that removing it and then displaying an error message is a hundred times worse than showing something grayed out with a little throbbing bar than actually removing it and being wrong 100 times better a thousand times better one million times better right it gives you more information and you understand more about what's happening a throbber a throbber is the thing that throbs uh you could uh totally disable the item using react until you get the confirmation deleted you totally can but again look at what you're doing you're handling the world's like you're handling State Transitions and the problem with this is that you have to do it everywhere and you have to do it in this really annoying fashion like this is actually a really hard problem it's not trivial you know what I mean it's not trivial and it's very easy to screw up that is why I'm so that's why I just like hdmax so much so I hope that you I hope that you enjoy it I think feels 100 correct from his perspective in the sense that he's gone on both sides and there's this natural contention between the two and I completely agree with him that contention's super annoying I cannot tell you how many times I've had to uh play the game of trying to talk to the back end to get me the just the end point so that I can do something right it's just like so effing annoying to take care of all that stuff me and him 100 see the exact same problem and I think he sees htmx as a way to alleviate that problem and I think he's 100 correct because that is part of the benefit of HD Max but my full belief is that hdmax benefit has nothing to do with that and it has everything to do with State Management State Management is the truest most purest form of where all of your problems come from and if you can reduce it down development just gets fundamentally easier completely and TJ is also trolling classic DJ so I think Theo's right but I think I but I think that it's it's just it's just part of the view that's all it is I think that I I truly have I'm truly saying the full the full viewage all right so TJ you're saying I may have missed some things um I'd love to hear it yeah so the well one you never use Hato as as an acronym so that just triggers me and htmx the framework obviously well I believe what you just said by the way what you just said you're gonna get unfollowed by him you know that if you call him a framework all of my friends with them oh oh no don't watch this video but it's gonna be a catch Point too because I did I'm gonna use Halo as and say why it's good right yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah yeah like the can you please define Halo ass so that way people understand so it's definitely along the lines of what you were talking about right with this idea of like only the back end has the state right and like the front end is just a representation of the state which I think is like with without saying it such that it makes sense to anyone that's hearing it and HTML is the reflection of the state right so that part is really really good and I think people can understand why like conceptually having the state in one place instead of two feels good right and like you run into a lot less problems with a lot of stuff but the other thing about this idea Hato as is hypermedia as the engine of application state so it's not just about uh like State being on the server but the things that are sent to the front end are the only available actions that people can take right so suppose you're not logged in then the same like path in your code or whatever that's going to generate the template it will have different it'll check if the user's logged in and it'll make different buttons if they're logged in versus not logged in right and so what's really cool is you don't have to sort of encode all of the options that you need to manage in some like Json blob right and then the front end like gets that Json blob so okay cool now I have a bunch of JavaScript that's going to turn that into random stuff and like do all these things blah blah blah blah right it's instead that you only send to the front end the actions that are available to the user right and so that actually also simplifies a bunch of stuff because you don't have to have your like API contract between front end and back end be like okay so this Json blob where I said that logged in really that means but in like okay we now have like 35 different words we all have to agree it's log in it's you know yep by the way have you used uh have you ever used coinbase API way back in the day or whatever it was canceled with one L instead of two L's and so it's just like that just get you permanently you're permanently broken because it's never spelled correctly yes but so like but I'm saying all you don't have to encode all of that state into some Json blob every time the front end needs a new piece of data you have to make sure that the back end now adds that piece of data now you can use that oh we changed what this data means so that means you actually need to display something different you don't do that you just like construct what you want to send and you put that on the front end and that's the idea right of hypermedia as the engine of application state which is really like oh I don't give you a button to delete something if you're not the owner of that thing obviously on the back end we still have all the validation yeah right like yep you can't you can't just delete someone else's thing but you can use literally that same code this is like the argument you always hear on the uh for like well why do we need a full JavaScript stack everything has to be JavaScript we got to share everything blah blah right it's like well I don't want to write I don't want to write these things well yeah but okay what if we just only wrote it once on the back end the one that really matters because it's gonna put it in the database yeah right and then we like don't we don't let you we don't we use that same thing like shut up can delete right yeah use that to say whether we're going to make a button or not yeah so I I'm full so I I tried to say that without saying all those complicated things I tried to say that the elements you send down are the your points of change meaning that the server makes the decision of what can and cannot be changed and I think that's something right like actions you can look at it as actions or however you want to but I think that that's a very important important distinction and you're almost making the Theo argument which that's why I said he is correct in the sense that either the front end has to bleed into the back end which is kind of his Preferred Choice which is next JS react or react server components yes or the back end has to bleed into the front end somebody has to make that Gap because that middle land where you're just trying to constantly like waiting for the back end to do something for you to get it has always and historically forevermore will be the worst possible place to ever be in the universe like it's just it's just a horrible place to be right but what's cool is if you have something that allows you to do it really simple right like htmx it empowers like people on both sides of that sort of spectrum right to make more deeper changes which like is also Theo's point but also sort of one of the things that maybe is like a little bit different in the sense that it's not about being like afraid to write JavaScript or something it's just that we're actually going to limit the scope and options that we have and have a shared language and that stuff's gonna all get done like in the back end uh which I think is nice yeah yeah it really comes down to the point of you need to qualify why JavaScript makes sense in this specific instance and I try that's why I've gone back to this game of life thing multiple times because I think that that's like the best qualification is like that's clearly a highly interactive like experience if you try to change anything about that it would make no sense for the server to drive that it would just make zero right so therefore this makes perfect sense and so this is why you can Define when javascript's good but for the most part you really don't actually need it as a driver of some sort of local state it's almost never actually needed right yes I think we're on the same page anyways it's it's very on the same page yeah I just wanted to like say the thing about when you send the HTML it's not the same thing as like sending you know like people are saying oh it's just like sending XML because you're just you're not gonna do anything with it you just display it right so it's like and and what's in that is the availability actions that you have to take open your mouth open your mouth open your mouth pull the clean out thank you also thank you for the four oh yum I know I'm watching I'm watching on stream DeLay So I see like three seconds behind okay well hey no I like that that's a good clarifying point which is just really I I do like emphasizing that it's the server defining when things happen because you got to really think about that if the server didn't just send you down a to-do with a delete button or without a delete button it's gonna send you down a piece of information that denotes whether you should or should not have a delete button and then you still have that same template whether it is I mean react jsx is just templating it's just templating inlined in JavaScript that's all it is it's just that's it and so you're still making the same decision you're just off putting it to or offloading it to the client where the client has to gather the state massage the state and then determine how to use the state which just is several extra steps right so either you include like a crazy amount of data in the Json that then the front end can use to construct write all the different things or you have a lot of complicated front-end code that figures out what needs to be displayed right and like you you need to have like is deletable and like you need to send that up or you you know like write a bunch of code to do that so I think that's where some stuff becomes really nice that's really missed as this idea that was the thing that really sold me on htmx was reading about this concept of thinking like oh I I don't have to construct that on the front end we can like make it the right way buy construction on the back end I don't have to worry about what the front end is going to do because the backend already makes that choice when it sends down can delete it's already constructed that so that business logic that exists for can delete now has to be Rewritten in a different form for the view it right so it's like yeah it's kind of one of those things that's just super funny about how you do duplicate the state everywhere and so that's what I mean someone's asking is that it's like the runtime computation of what something means yep uh someone was asking just like there's no assumed security like you can click on whatever link you want or go anywhere type one in the browser or run curl commands yeah you still need to be checking on the back end that the user's logged in and like has the proper role in things for all this other stuff it's just that you only send to the front end the stuff that they should be able to do at that moment which makes it really clear like what they should be able to do right you don't have to keep that logic in two places yeah and xss thing that we see people say this a lot uh HTML template and go but just yeah like all templating libraries will make it very difficult for you to just put random HTML elements and user input and throw those places that's a bad strategy just don't yeah if you just raw dog HTML you're probably gonna make it you are gonna don't you don't make templates okay let's somebody else make a template they're just better than you it's okay we've all made that mistake yes just just use the one that exists already yep all right cool hey I really appreciate this it's fantastic by the way bye DJ hey do you do you stream anywhere uh no oh okay didn't realize that huh

Channel: ThePrimeTime

Views: 354,310

Keywords: programming, computer, software, software engineer, software engineering, program, development, developing, developer, developers, web design, web developer, web development, programmer humor, humor, memes, software memes, engineer, engineering, Regex, regexs, regexes, netflix, vscode, vscode engineer, vscode plugins, Lenovo, customer service

Id: 2hMrk7A8Wf0

Length: 49min 55sec (2995 seconds)

Published: Fri Sep 01 2023