"The Life & Death of htmx" by Alexander Petros at Big Sky Dev Con 2024

I know we're not HTM X conference okay we're not this is Big Sky Devcon but we happen to have a core maintainer of hmx coming up next okay uh freelance developer used to be a lead Dev over at Washington Post Alexander where's Alexander all right there he is yeah nice so it's going to be awesome and he's going to be talking about H2 Max very excited very excited appreciate it [Applause] hey everybody little Insider tip they never asked me to see these slides so anything could be on them fortunately what's on them is the talk that I said I would give all right so I'm Alex I'm one of the core maintainers of HTM X and this is the life and death of htx um most of you probably know what it is but just a quick recap uh on the screen we have a button it says get users we can imagine that when you click this button it will get you a list of users so that's what that looks like in HTML uh and HTM X makes it really easy to enable that experience so you just add these two attributes say HX get users means when you click it go to the SL users route and HX swap means replace the outer HTML which means the button with everything once uh once the thing comes back so the user clicks says get to the server the server responds with a A list of stuff and then the button becomes a list of stuff stuff that's it that's htx there's a little more to it but that's the core idea um so the title of the talk is a reference to a talk by Gary burnhard called The Birth and Death of JavaScript uh and in it he kind of describes like how where JavaScript came from what it accomplished and kind of posits a hypothetical future where JavaScript eventually is becomes a compile Target um and kind of creates the seeds for its own obsolescence uh and so I'm going to do basically the same thing uh but with HDMX talk about where HDMX come from came from and then uh how HTM X can kind of push the standards of the web forward and if you're wondering why I changed uh birth to life uh by the time I realized that I had done that it was too late to change the title of talk so um what I'm going to describe here is the pattern by which things end up in HTML so basically HTML is a set of core functionality that is available in every single browser and developers can use JavaScript to extend that core functionality so uh as that happens over time turns out that a lot of developers do not have original ideas or more charitably they have lots of versions of the exact same idea so as we continue to make the same idea over and over again we kind of decide what works what doesn't and with kind of the law of large numbers arrive at what is a good thing that should be in HTML and then that the best most important functionality uh that arises from the large community of developers those things we pull into the standard uh we extend the standard and then now we have a new Baseline for what should be in HTML so uh that's kind of the way that progress happens and I'm going to talk about how HTM X specifically uh can be part of that cycle and this has happened many many times in the past so jQuery pretty famously had this like made it much much easier to find things in the Dom and eventually the people who uh maintained the Dom said ah we should have query selector and now you can just use CSS selectors to get things from the Dom um same with uh many many re-implementations of the I click a thing it gets bigger I click it again it gets smaller uh and we said okay well let's just have a details element and that'll just be there and you can style that it can look like whatever you want so this cycle repeats itself many many times all right so um this is a brief history of partial page Replacements which is essentially what h2x does so uh in 1999 an early version of the XML HTTP request API ships with Internet Explorer 5 and you can see it's not the easy EST thing to use you have to like open a socket and then you have to wait for the you have to do a call back for when it finishes but uh it's there it's a thing that lets you do an HTTP request outside of the confines of HTML uh in 2006 jQuery says we could make this a little bit easier uh and introduces uh Ajax which is now basically a name for we take a thing uh we make a request we replace the thing with what came back um and you can see also here that what jquery's done is say there are a couple core things we need to do every time we need to specify the method we want to say where we're going uh and we don't need to be fiddling with the internals we can just describe that declaratively and then uh make it easier for the user to use so you can see the interface keeps getting better then in 2016 the first version of intercooler JS was released uh which K mentioned earlier was the precursor to HDMX and it says hey all this stuff we're doing here we keep doing that a lot let's just put it on the thing itself uh and we'll say hey now we're posting to this thing and and do all this jQuery stuff every time because it turns out that we need to keep repeating this many many times uh and then finally now we have HTM X which kind of cleans up that interface uh removes the jQuery dependency because intercooler was a jQuery extension uh and says all right here you go you can now do Ajax from an attribute uh and I think this is pretty close to the platonic ideal of what this interface should be uh and this has worked very well uh this is the this htx is the second fastest growing uh JavaScript uh front end framework so that's pretty cool um and again as I mentioned we keep iterating on this interface like oh we have to do this same series of actions many times let's keep making that thing easier until we arrive at kind of the right idea here so um how do we get this on the standards track we have a clear pattern we want to take a thing in the Dom make a request replace the thing with what came back let's get that in HTML uh and I have three I think relatively simple ideas for how to do that and they map up very well with the stated motivations for HDMX on the web page so I'm going to start with uh why should only get and post methods be available and If you're not familiar with this problem uh the top two things are a form that is legal in HTML uh which is a form that says method get or method post these are two HTTP methods uh but there are other HTTP methods that just don't work so if you do put or delete or patch uh it just ignores you and does a get request uh we should change that and if this has ever annoyed you you're not alone uh this stack Overflow question has been asked like 10 times the first example is from 2013 uh 2011 2018 2020 this is so obvious like people say oh there's a method I should be able to do put and delete and then they continually run into the wall that you cannot in fact do that so form should be able to put in delete that's my first big idea um and the reason that these HTTP methods matter is because the methods say different things they mean different things so this is an example of like a very basic HTML or HTTP resource uh which is just like a users like let's say you have a list of users um and you want to be able to show those users and do things to those users for the people who uh are visiting your website so if you get SL users you're telling the server I want to get all of the users and if you add another slash and say what user user one two 3 you're saying I want to get user 1 2 23 specifically now if you want to modify those resources uh so if you want to change something about user 123 uh you need to do a put request because a put request says I want to replace that user with this new data this is different from a post request which says I just want you to make a new thing uh and if that thing happens to be there already fine whatever but a post request is for making a new thing and a put request is for adding uh is for updating a specific thing it might create a new one if it's not already there but these two things have very different semantics uh and delete is an entirely different thing delete says that should no longer exist so uh there are lots and lots of ways that developers work around including these semantics uh by saying hey well there's another form that says this is there's another input that says Ah this is a post request but do a delete uh but you shouldn't need to do that because it's all right here uh and this matters because the browser or whatever your HTTP client is is able to do different things for you based on what you've described that your method is supposed to do so a post request cannot be repeated which is why every time you refresh a page after submitting a form you get that scary message that says you may be resubmitting the form are you sure you want to do that and then like the user freaks out it's like know uh if you had a put request you can keep repeating that uh the fancy HTML word for this is uh item potent I don't know that anyone's ever said that out loud uh there's no agreed upon pronunciation I looked it up um but what that means is that you can retry it many times and you'll get the same outcome so if I keep telling the server hey replace user 123 with the contents of my form no matter how many times you do that if the contents of the form don't change the server is supposed to do the same thing every time uh same with a delete request doesn't matter how many times you say delete this guy if you send that three times the outcome should always just be delete this guy so the browser can retry those things uh based on you describing with HTTP semantics what the browser is supposed to do um and there's another practical reason that I don't see a lot of people talk about here uh which is that programming with uh HTTP methods used semantically is much much easier because the way that we describe what an HTTP server should do is often with a router uh this is an example from expressjs um and I kind of formatted the column so that you can see like I'm saying hey uh here's what the method is on the on the left side post put delete uh get Etc uh the yellow bit is the root itself uh and then I also describe different levels of permissions for all of these things and then I say which function should handle the actual um you know successful response to the HTTP request uh and I want to zoom in specifically on this is a app that I maintain that manages outdoor trips um for a college and uh one thing you do with this app is add or create trips that are other people might join um to go on and if you post a trip that's creating a new trip but if you put to a specific trip ID you're updating a trip that already exists and these two things have different permissions because any any leader in the uh in the outdoors Club is allowed to create a trip but you're only allowed to edit the trip that you created so by describing these things with different HTP methods I'm able to in the router declaratively describe uh in a way that's pretty easy to read even if you're not familiar with expressjs uh itself what permissions are on each of these routes and how these routes do different things uh this is much much easier than trying to put like an if statement inside the post that's like if uh input method equals delete then do this if this um because there's just a lot less room for error uh and if you're noticing that a theme of this talk is that doing things declaratively uh makes them easier to maintain and understand over a long period of time that's not not an accident um this is Jango uh this is python fans will be familiar with uh URL patterns which is basically the same thing you describe a route uh and then you have an object or like a class and that class has methods on it like post get delete Etc uh I don't like this like as much as the express GS way of doing it but it accomplishes essentially the same thing uh and the more surface area you give to the application to describe your application at this level the more ability that you have um to kind of audit it and make sure you don't make mistakes uh this is one that's in Rust I wrote this this is a macro and again you can see it's almost an identical structure there's some uh there's there's some affordances made to rust kind of weird uh type semantics and macros and whatnot but I'm saying the same thing so even if you don't know what this code like how it works which you can't because it's a macro that I wrote uh you can still see that um that it's saying here's a method here's a u URL here's who's allowed to access this URL and here's the function that handles fulfilling that particular request so this has been tried uh a number of times uh first in 2010 uh and then there's a there's an open but inactive um GitHub issue saying hey why can't forms do this um and there's been a couple objections raised um this is kind of my attempt to resolve all of the objections that I've seen when this has come up in the past um and I want to emphasize like the fact that this hasn't happened yet uh isn't really a anyone's fault uh it's really really hard to add things to HTML or any of the web standards because everything that we agree to add to the web standards we are on the hook for supporting essentially for eternity uh so it's really good that we take our time to get these things right um and the the the need for this thing has been questioned in the past and so one of the things that I hope the Resurgence of interest in HDMX and other similar Technologies turbo PJs whatever um demonstrates that this is still a very very clear missing ho in HTML that's something that we do have the capacity to fix all right number two uh why should only links and forms be able to make HTTP requests uh this is one that uh the HDMX website gets a fair amount of criticism for because people say that well these are the semantic elements for doing things so we should be able to we we shouldn't be just like willingly putting HTML HTP requests on uh random uh HTML elements uh and I agree with that actually uh my only addendum to this would be we should be able to do it on buttons so links forms and buttons that's it they really don't need to be anywhere else you can style links forms and buttons however you like you can make them look to the user like whatever they expect but you should be able to put them directly on buttons now buttons uh here's a log out button uh and don't don't shout it out because we're not equipped to take questions but just like ask yourself how would you implement a log out button and and there's not actually an obvious way for this extremely common HTML activity if you wanted to do it in pure HTML with a post request probably what you would do is wrap the button in a form but I'm not submitting a form I just want to take an action I just want to log out uh and the idea that we have to wrap buttons in forms uh it kind of makes people feel like they're doing a hack and then kind of oh well if I'm already doing a hack I might as well just do it in JavaScript or do a get request with a link or just do any there's no obvious supported uh kind of pattern for doing this um and you should be able to specify clearly and concisely what a button does uh hey Button delete this thing when it gets clicked great um the aforementioned outdoor trips program that I'm in charge of uses this pattern very frequently um up here the green person in green uh that is Carson he's the leader of the trip um and he can choose to make me a leader of the trip by clicking make leader and the way this button works it's not a form uh it's just a button that issues a put request to the list of leaders and says hey add this person to the list of leaders and then when you click it it makes you a leader and it returns a new button that says hey when you uh click this red button now remove them from the the list of leaders again none of this is like a form I'm not filling out any paperwork I'm just doing a thing and then inserting the response from the server uh so if they you should not be wrapping these things in forms uh and when you don't have to wrap them in forms you get to do these nice patterns with forms where you have the button do a different thing even though both of these buttons are in the form so the save button is a regular submit um and it will submit the form and update the profile but the cancel button is uh just a regular just issues its own get request independent of the form and just like returns to the non-editable view of the form uh and if you had to wrap that button in a form then you'd have two forms inside this would just get it gets confusing really really fast um so to to steal one of Carson's lines from his grug brain essay you should just be able to put the thing on the thing uh where it should be uh and what's nice about this I think is that it turns HTML people say well you're not using semantic HTML right oh you've made this div usable now you have to add an ARA Ro that says what the thing does but if the button can do a thing that the div can't then everyone will just use the button and so you've accomplished what you actually want which is getting people to use HTML properly so that screen readers can use it so that websites are accessible to a much wider variety of people but you've done that by making the thing more useful so rather than being a list of rules that you have to memorize it's functionality that you have access to um and then people will use it um okay some more details um again just my attempt to address what I think are some of the ambiguities that would happen if you do this um but basically buttons should have action and Method attributes that operate identically to the way they operate on forms uh and you have to like explicitly specify how that interacts when the button is in a form how it interacts with type equals button versus type equals submit but uh I think that these are solvable problems and the surface area the API surface that you have to modify is very very small so I also think this is quite doable all right last one uh why should you only be able to replace the entire screen um so why when you do a form request right now the whole screen gets wiped and then you replace it with what comes back or in many cases you just redirect to a different thing so then you're you know kind of doing this thing um so yeah I I agree with this uh HTML should be able to specify partial page updates now a lot of people don't know that we're like 90% of the way there on this one because a link has a Target attribute uh and the target attribute has a couple keywords or uh any I frame so this is just like a a regular open maps embed and uh if you have a link on a page you can Target this embed and have those links like change what's inside the iame so that is a partial page update you're saying hey this little bit of the page this if frame um I'm controlling that with these links H there is a a uh framework called HTM z uh that basically takes this idea and generalizes it and and to be honest I think that this started out as essentially a troll and then the person who made it realized it's a pretty good idea uh and it's been updated a couple times since then and all it does is says hey here's an ey frame and when you uh Target this ey frame I'll just take what you put in here and ye it into the Dom somewhere else that that that works uh it works really really well um they also have a little bit of a ding uh on HTML here or on HTM X where they say well naturally we can only do this with uh links and forms because those are semantic uh to which I would just say and buttons you should be able to do it with links and forms uh and buttons uh also uh while this is like a little bit of a ding links and forms are the only things that support targeting if frames so yeah sure it's semantic but again it's it's what they have access to which is what makes the Paradigm of hdmz work uh hdmz though is burdened by the fact that because they have to Target the if frame they can't say where the replacement should go in the Target element they have to do it with this like um page anchor after the hash the the blue bit there um and what they really want to do and what we should be able to do in HTML is just Target the thing uh and that's that's really all you have to do for partial page updates just make this uh many libraries have kind of coalesced on the jQuery like idea that this should be a CSS selector so just let Target be a CSS selector uh and then on a link a button or a form and just say hey replace what the CSS selector is uh what the response is with whatever the CSS selector is um yes so some details to this uh you for backwards compatibility reasons you probably have to say um ignore like if there's an iframe that for some reason has a name that is a valid CSS selector that should probably take precedence it's very important to not break backwards compatibility with existing web pages but I think that this is very doable so just some ideas for this that will hopefully make it into uh an HTML standards proposal in the near future all right conclusions um I did it I I addressed most of these things um the one thing that doesn't get addressed is why should only click and submit events trigger actions this is basically for scripting purposes um and it's not what I'm interested in for the purpose of this talk I want to know how HTML itself can be a more descriptive hypertext and uh yeah so these are the proposals and one of the reasons that I care about this so much is that the HTML standard is the the Baseline that everyone has access to and if you write something that is in pure HTML that thing will last as long as browsers are around and we have a pretty safe bet that browsers are going to be around a very long time so there is an entire category of web pages government services um SAS companies you know just like the internals of some random Cisco like place where you just need this thing to work forever and you don't want to have to be maintaining it in an ongoing manner uh and all those things if we just very very slightly increase the expressive power of HTML we would be able to say build them in uh build them in a language that more or less never goes Obsolete and I think that's a very very powerful concept uh and again I want to emphasize because that thing never goes obsolete it's really really important to get every single one of the details right so this talk should be understood as a way of starting the conversation how do we take these ideas that many libraries HDMX included have coales around and how do we get those into a thing that everybody has access to for as long as HTML remains um the most important document format in the world uh that's it thank you very much

Channel: Montana Programmers

Views: 32,915

Keywords:

Id: inRB6ull5WQ

Length: 23min 0sec (1380 seconds)

Published: Sun Jun 09 2024