HTMX and InterCooler ft. Carson Gross - JSJ 513

JavaScript Jabber

A weekly discussion by top-end JavaScript developers on the technology and skills needed to level up on your JavaScript journey.

Subscribe

Follow

HTMX and InterCooler ft. Carson Gross - JSJ 513

Guests :
Hosts :
Published : Dec 14, 2021
Duration : 1 Hours, 12 Minutes

Show Notes

Carson Gross is the creator of InterCooler and HTMX. He pulled them together to manage the way that he wrote JavaScript and interacted with hypermedia and HATEOAS to make managing the DOM and backend easier.
It's not really a competitor to web frameworks as much as a different way to think about the front-end of your application.
Panel
  • AJ O'Neal
  • Dan Shappir
Guest
  • Carson Gross
Sponsors
Links
Picks
Special Guest: Carson Gross.
Sponsored By:

Transcript


AJ_O’NEAL: Well, hello, hello and welcome back JavaScript Jabber listeners. I'm your hostess with the mostest AJ O'Neill and we have an exciting show today. We have with us Carson. Oops. I don't have your last name in front of me. Where'd he go? Carson Gross. Try to save you. It's okay. You are the author. 

CARSON_GROSS: It was a rough, it was a rough third grade. 

AJ_O’NEAL: Yeah, I could see that. So you are author of HTML. 

CARSON_GROSS: Yeah. Few different libraries, HTML, HyperScript and, uh, and our cooler just.

AJ_O’NEAL: All right. And then we also have with us Dan Shapir. 

DAN_SHAPPIR: Hey from Tel Aviv, where it's still nice and warm. 

AJ_O’NEAL: Yo, yo, yo, I'm coming at you live from Toasty Garage Converted Office. And welcome to episode five, Gazillion D and three, I think is what we're at. Right? 

DAN_SHAPPIR: Yes, more or less. 

AJ_O’NEAL: Let's go ahead and dig in. 

 

Have you ever really been happy with your project management tool? Most are either too simple for a growing engineering team to manage everything or too complex for anyone to want to use them without constant prodding. Shortcut is project management built specifically for software teams and their fast, intuitive, flexible, powerful, and so many other nice positive adjectives. Let's look at some of their highlights. Team-based workflows. Individual teams can use Shortcut's default workflows or customize them to match the way they work. Org-wide goals and roadmaps. The work in these workflows is automatically tied into larger company goals. It takes one click to move from a roadmap to a team's work to individual updates and vice versa tight VCS integrations, whether you use GitHub, GitLab, or Bitbucket shortcut ties directly into them so you can update progress from the command line. Keyboard-friendly interface. The rest of Shortcut is just as keyboard-friendly as their power bar, allowing you to do virtually anything without touching your mouse. Throw that thing in the trash. Iterations planning. Set weekly priorities and then let Shortcut run the schedule for you with accompanying burn-down charts and other reporting. Give it a try at shortcut.com slash dev chat and get two months free. Again, that's shortcut.com slash dev chat. Shortcut, because you shouldn't have to project manage your project management. 

 

AJ_O’NEAL: So Carson, go ahead and just give us a little bit more of an introduction to yourself and tell us what you would like to talk about today, which I assume is going to be a lot of HTMX, but maybe some other things too? 

CARSON_GROSS: Yeah, I think we could talk about, we'll talk obviously mainly about HTMX, but there's some other topics we can talk about as well. My name is Carson Gross, and I've been a web developer now for a long time. I've been, started programming back in the late 90s. Actually, the mid 90s, I worked in something called Hypercard, which was sort of a proto worldwide web that it was on a single computer, but it had the notion of links and things like that. 

DAN_SHAPPIR: That's cool. Yeah, I remember that. 

CARSON_GROSS: Yeah. HyperCard has always been something I miss and I love. There's some modern versions of it, but if we talk about HyperScript, you'll see some influence coming from HyperCard. So, yeah, I've developed for a very long time. And about a decade ago, I was working at a startup, and I needed to do some front-end programming. And I didn't, the front end libraries that were available at the time were primitive compared to what we have today. People mainly use jQuery, a lot of jQuery basically. Angular was just starting to come on the scene and I didn't want to work that way. And so one thing that your listeners, I'm going to ask your listener, to anyone who's listening to this podcast, presumably is a JavaScript person, who's someone who uses a lot of JavaScript in their day-to-day work or anticipates using a lot of JavaScript in their work in the future. And today's going to be a little bit different because the technologies that I've been working on mainly don't involve the users using much JavaScript. They're written in JavaScript, but rather than adopting sort of the JavaScript paradigm that we use today for single page apps, for example, both HTMX and intercooler are instead extensions of the base hypermedia model of HTML. So like the basic idea of HTML with links and forms, one way to think about HTMX is a generalization of that technology and an extension of that technology. So I built Intercooler about a decade ago to help me write front ends in a more, more interactive front ends and a hypermedia sort of manner. And then about a year and a half ago when COVID hit, Intercooler depended on jQuery and I had always been bothered a little bit by that dependency because it was so big and jQuery had sort of aged over time, although I still think it's a great library. And so last summer, I decided to try to rewrite, I was at home and I decided to try and rewrite Intercooler without that jQuery dependency. And that turned into htmx. I renamed it as well because as I had been working on intercooler, I had learned a bunch of stuff, I'd made some mistakes I wanted to fix and so forth. But then I also came to this conclusion that by calling my first library, intercooler.js, it was compared with things like Angular and then React and Vue and, you know, all the new ones that have come out as a JavaScript library. When instead it's just a very different approach to building websites. It's a hyper media oriented library. And so I felt like HTML X captured that concept a lot better than something.js. So that's kind of the history. There's another project in there as well. Maybe we'll talk about close to the end called Hyperscript, which is directly inspired by HyperTalk, which was the scripting language for HyperCard. But maybe we'll get to that at the end if we have time. So that's kind of the history. That's where I am and that's where I'm coming from.

DAN_SHAPPIR: When we started talking before the show started, I was looking at the documentation for htmx before the show to prepare. And like I told you, my initial reaction was, hey, this is this is genius. Why didn't I think of that? Because I really love the concept of using the declarative nature of HTML as a means to specify more let's call it complex operations or the types of operations that we kind of expect these days from from modern web applications. But yeah, but doing it in a declarative way within the HTML itself, rather than by doing it imperatively with a lot of JavaScript. So it was really cool for me to see. I obviously haven't tried it yet. So yeah, I can't attest how much I would actually enjoy it after significant use, but it looks really cool, especially for fairly straightforward web frontends. 

CARSON_GROSS: Yeah, I think that's right. To your point, one of the problems that I see with the web, and there's a million different ways you can build web apps this way, or these, excuse me, there's a million different ways you can build web apps these days, I should say. But most of the ways that more complicated apps are going to be built is with a very JavaScript heavy infrastructure on the front end. And I don't blame people for that because unfortunately, HTML really hasn't advanced very much in the last two decades. You can't, you still can't submit a non get or non post from HTML. You know, that's crazy. You have to kick out to JavaScript have access even to that basic level of HTTP technology. So you can't issue a delete from a button in HTML without using JavaScript. And so I'm sympathetic to the conundrum that people have been facing here, which is that a lot of stuff just has to be done in JavaScript. A lot of technologies in the browser are locked up in JavaScript. And so, HTMX is an attempt to take HTML and drive it forward. I think I said when we were getting going that at some level, I feel like HTML is just how HTML should work. This is the sort of direction that they should go with HTML, increasing its expressivity as a hypermedia, so that there are patterns that right now require JavaScript that can then be folded into a pure HTML implementation. And so, you know, if we go into any of the examples, just to give some concrete examples of what you can accomplish with HTMX in a, like you said, a purely declarative HTML-oriented way, you can do things like infinite scroll like active search as you type in an inbox, it filters results that are coming from the backend. You can have inline editing. So if you have a table row and you wanna click that button on that table row and replace it with an editable version of that data, and then click save, the scroll state stays the same. All this stuff that today, if you were faced with implementing that feature, you would immediately think, oh, I need JavaScript to do this. Well, that's not totally true now. So with HTMX, there are other technologies that are coming up that are similar to htmx. Onpoly is another one that I really like, a great library. But with these technologies, you can build these user interfaces using hypermedia concepts rather than having to go out to JavaScript. And you said, oh, how did I not think of this? Well, I think kind of I joked that it requires someone who's just dumb enough to not be able to handle the big JavaScript frameworks, but just smart enough to be able to actually write the code. And so I fell into that sweet spot just right. I wasn't gonna, I just, you know, I threw my hands up back in the day at React, the original React and said, I can't handle this. And, but I could write enough JavaScript to make this work. So. 

AJ_O’NEAL: So looking at this, it seems that it's perhaps most similar from other things I've seen to AlpineJS. Is there any inspiration drawn there or have you seen AlpineJS to be able to compare and contrast? Because we had an episode about that recently. 

CARSON_GROSS: Yeah, I think AlpineJS and HTMX pair well together. Alpine was in parallel. I mean, IntercoolerJS is super old, you know. So, HTMX was directly just a port of IntercoolerJS to modern vanilla JavaScript. So I, but that being said, I know a lot of people who use HTMX and Alpine together. And the reason they use them together is that Alpine is very good at expressing front end logic, like toggling a class on some element in the DOM, right? And that's something that you don't necessarily want to buy into a whole enormous JavaScript framework to make it happen. And back in the day, we might've used jQuery for this sort of thing, but jQuery is showing its age. It's quite big and it has its own issues. And so something like AlpineJS, where you're embedding the code directly on the elements, that you're embedding your JavaScript directly on elements, satisfies that front-end need. HTMX, in contrast, is mainly about interacting with the server via hypermedia. So one thing I should say about HTMX in contrast with most JavaScript frameworks that your users are used to is that with HTMX, you don't get JSON back from the server. Instead, you exchange HTML. And so when we get into the details of HTMX, when it makes a request, it's an Ajax request typically, but when it makes a request, it's expecting HTML from the server, not JSON. And so it's really about empowering HTML to have more expressiveness, have more, the ability to express more complicated interactions, more complicated server interactions with a backend that is producing HTML. Whereas Alpine would be more geared towards sort of front end state management. So I think they complement one another very well. They pair well together. I have a lot of passionate users of both of those technologies. Hyperscript, which is sort of, again, a sister project of HTMX, I would say is more a direct competitor with Alpine. And it has their features and Hyperscript that have come from people who are using Alpine with htmx and say, hey, I can do this in Alpine, but I can't do it in Hyperscript. Can you take a look at this sort of feature? And so there are some, some direct inspirations in Hyperscript from Alpine. It's a great technology. Caleb's an unbelievable engineer. So the two technologies play well together. 

DAN_SHAPPIR: I think it's, it would be worthwhile to give a brief explanation of how htmx works because we are kind of talking explaining concepts without getting into the concrete details. And I think it's simple enough that if we do provide some concrete details, people, a lot of people just go, aha, I get it, even though, you know, we can only talk about it and not show actual examples. 

CARSON_GROSS: Sure. Yeah. So let's let's just go over like if you just go to htmx.org, there's a simple example on the on the home page there. And what it what it is is a button you've got a button in a UI. And what you want that button to do is post to URL. And so in order to do that, the way that htmx works is you're going to add attributes to your JavaScript, to your HTML. You're just going to add attributes. And so you can put the attribute hx-post, and you can prefix that with data hx-post if you want to be compatible with standard HTML. But you can say hx-post equals and then on the home page it's going to post a slash clicked. And what that's going to tell htmx is okay when a user clicks on this button by default with a button that it's going to the request is going to be issued on a click. When a user clicks on this button issue a post request to slash clicked. And then take that HTML and swap the HTML that comes back from that. So recall with HTML X, you're exchanging HTML with the server rather than JSON. And so slash clicked is going to return some HTML and then that HTML needs to be swapped into the DOM somehow. And so the next attribute on this button is HX swap outer HTML. And what that tells htmx is when we get html back, I want you to swap that html in for this entire button. So replace this entire button with whatever the server responded with. And so that's gonna completely replace it. If you didn't have an hxswap attribute on this button, it would instead use inner html. And this is standard terminology from the DOM API. So this is all part of the, I'm just trying, I try as much as possible to use standard DOM concepts. And so the inner HTML would instead take that HTML and swap it inside this button. So, and maybe you want that, it depends, right? If this was a div or whatever. So these two attributes basically enable you to drive an interaction with a server in purely hypermedia terms. So you're issuing an AJAX request in a post to slash click. And then when you get that HTML back, you're gonna swap it in for the outside for the entire element that issued that request. And there are a couple of other elements, there are a couple of other attributes, excuse me, that are useful here. So if you didn't want to issue the request on click on the default event for this particular type of element, you could use a HX trigger. And you could say, for example, hx trigger equals mouse in, and then that request would be issued when a mouse enters the button. Why would you wanna do that? I don't know, this is just an example. I'm not saying this is a good one, but you can respond to different events. So you can say, okay, it's not gonna be just clicks that drive interactions with backend, there's whatever event you wanna have that drive the interaction can be used with HTML. But once again, it's in a declarative way in HTML rather than requiring you to hook up some listener or something like that. And then the other, the last one I wanna mention. 

DAN_SHAPPIR: Before you go on, I just want to mention again, just to clarify to our listeners, because this extended behavior may be surprising to some. So it's important to understand that you need to add a script tag into your HTML that actually loads the HTMX library. So you just have a script with an SRC equals blah, blah, blah, whatever. Let's say an unpackaged with the URL to the HTMX library. And once you load it, I assume you just look at all the HTML elements within that page, find the HTMX attributes on them and behave accordingly. And again, it's important to note that it's just an HTML. It's not some special file. These are just, let's call them custom attributes that you put on the regular HTML elements. Like you said, on a button, you just added an HTML attribute, hx-post equals in quotes, slash clicked. And then it will post to that URL, to the slash clicked URL. So it's really cool that by just throwing in that single JavaScript file, which I think is really small, correct me if I'm wrong, then you get this extended functionality in the HTML itself without having to resort to any additional file that you need to download or anything like that. It's just completely built into the HTML itself.

CARSON_GROSS: Yeah, that's right. And so the idea is we're enhancing HTMX, we're extending HTML. And so you're absolutely correct. Just by including this tag, now all of the elements in your DOM have this ability to interact with the server in a more advanced way than standard HTML allows you to. So the final attribute that I did want to mention is hxTarget, which is another attribute. And you can use hxTarget if you don't want to replace the current element that's issuing the request, but you want to replace some other elements in the UI, then you can use hxTarget and a CSS selector to say, okay, when you get this response back, I want you to put it into this other thing. And so that can be very useful to replace, you know, you click a button to download, say the latest transactions, but you don't want to replace the button, you want the button to stay there. Instead you want to target some other div that's holding your transactions. And so you would give an ID to that div, let's call it transactions, and you would add an attribute HX target equals hash transactions. And then when HGMAX got that content back from the server that HTML content back from the server, we simply swap it into that other place in the DOM. So those four attributes, I feel like, are probably the core of HTMX that lets you interact with the server in a much more dynamic way, directly from HTML in a declarative manner. 

DAN_SHAPPIR: I think that this is the second really smart idea from my perspective of HTMX. So the first one was to extend the functionality of HTML by just adding these declarative attributes on it. And the second one was the concept of downloading HTML fragments from the server and then effectively hot swapping these fragments into the specified areas of the current HTML document. You know, by default, like you said, the actual element that issued the request, but you can also specify a target other elements in the page. I thought that that was really cool. And what made it even cooler for me, which it took me a second to figure it out, but then it was obvious that the HTML that you swap in can also have HTMX attributes. So if you swap a button, let's say, that has an HTMX extended functionality, you can swap it with a new button or something else that also has extended HTMX functionality. So you respond to user interaction, you go to the server, you get some something back, which is a combination of both data and functionality for the next user interaction. I thought that that was a really cool concept. 

CARSON_GROSS: Yeah, thank you. I appreciate that. And that's the idea we're trying to make. Again, we're trying to make HTML more expressive and give us more power to interact with the server in ways that just standard HTML unfortunately doesn't allow us. And so if you'd like, you know, one concrete and I think somewhat surprising to people who are new to this model of programming, one example of HTMX is what I call active search. And we could talk through that if you want, or if you want to talk a little bit more about the concepts of HTMX, that's fine too. 

DAN_SHAPPIR: I think it's a great idea to talk about the concrete example. 

CARSON_GROSS: Okay. Well, so just, you know, your listener is okay. That's great. HTMX is a little bit better. What does that mean from a practical standpoint? You might think to yourself, okay, buttons can now can issue a delete. That's great for really simple stuff, but can this, can HTMX really allow me to do what my more modern UI than something is. So is just issuing a delete from, from a button. Well, the answer is yes, and I would encourage your listeners to go to htmx.org slash examples slash active dash search as a potential as an example of what can be accomplished using this htmx model. And so unfortunately, you know, this is audio, so I'm going to have to describe things. But again, I encourage your listeners to go check that out. And what I'm going to do is I'm going to walk you through active search implemented using HTMX and active search is when you've got an input that you type values into. And when you pause for a moment, a request is issued to the server to find matches for that input. And so Google does this, right? As you type, when you, when you go to Google and you start typing, it shows you a bunch of potential matches. And so this is a simplified version of that. But nonetheless, you're able to accomplish a user interface like that with HTMX using purely declarative terminology in HTML. And so let me walk you through the essentials of this example. So if you go to that page, what you'll see is we have an input and that input has an HXPost on it, attribute. The input has an HxPost attribute on it, and it posts to search, slash search. Very standard, you know, you have some search URL on your website. And the next attribute on this, and this is really the magic of HTMX, is the HxTrigger on this. Normally with an input, the default event that's going to trigger a request is changed. We don't want that, because what we want to do is issue a request every time the user types of key, right? We want this to be very active and interactive as they're typing. And so the attribute to make that work in HTMX is hx trigger. And so hx trigger, the value of that attribute in this case is key up. So whenever a key up occurs, we're gonna issue a request. Well, the listeners are probably cringing at this point because you don't wanna issue a server request on every key up. Of course, we don't want to do that. And so there's some modifiers for that key up event. In particular, there's a delay colon 500 milliseconds modifier for that key up. And what that tells HTMX is, okay, when a key up occurs, wait 500 milliseconds before you issue that request. And if another key up occurs, then don't issue the original request. Wait until basically, the user has paused for half a second before you issue a request. And that way the user can type some data in, stop, we issue the request and update their search results so that we're not hammering our server. And then there's another modifier on it, which is changed, which will only issue requests when the input's value has changed. And so if the user, for example, hits an arrow key, the value will not have changed. And so we won't issue a request in that case. And so the whole trigger attribute is key up, changed, delay 500 milliseconds, and all those together work to provide the behavior that we want, which is we only issue a request when a user is typed in some new data and they paused for a moment. So that's a pretty sophisticated trigger, but nonetheless it's declarative and it's just right there in your HTML. And then the final attribute that really matters is hxTarget, which is in this case is hxTarget equals hash search results. And so we have an input. We don't want to replace that input. Instead, we've got a table down below and we want to replace that table that we want to replace the table body actually with the search results that come back from the server. So the server again is just returning HTML. It's just going to be the table body results that match that particular whatever the user has in the input. And so those three attributes taken together implement the active search pattern. And so that's, you know, it can't be more than 50 characters. You're implementing what I think is a pretty sophisticated user interface pattern that would I certainly interact with a lot of websites that would benefit from having just this. So it's very simple. And that's, you know, I think one of the benefits of the hypermedia slash HTMX approach. And the final, there is one more attribute on there that I'll just mention, which is AJAX indicator. And we won't go into the details of that, but it provides a way to show an indicator when an AJAX request is in flight. So that's a better user experience. You want to tell people, hey, something's happening. So they know, oh, I can wait for the server to come back. But the other nice thing about that page is down below there is actually a live example. And you can go down to the bottom, there's a little demo section, and there's an input with exactly this code on it. And if you start typing in it, like I think, yeah, if you just type like AE, what you'll see is that the table below the input box is updating dynamically as you type. And so you can, it's a pretty good user experience. You're not, your scroll state isn't resetting. It's, you know, it is the active search pattern being implemented. But again, purely with HTML attributes, you haven't written a lake of JavaScript to make this happen. And you can, there's actually, if you notice a little bit lower on the page, there's sort of a little section that shows- 

AJ_O’NEAL: Which section is this under? 

CARSON_GROSS: This is under the, if you go to examples slash active search, and then you go down to the bottom of the page, there's a demo section. 

DAN_SHAPPIR: Or you can go to just htmx.org. and then searching the page for active search and there's the link to that example. And I have to say that example is really cool and it's nice that you got this functionality, including the actual specification of how it's displayed on the page, you know, the input field, the header, the table, etc. in under 25 lines of code. So an HTML code which is totally declarative, no looping, no anything, and like you said, it just works, which is really cool. And also that the response from the server is actually the HTML content of the body. So it's not, you know, most of our listeners would be used to the fact that you issue a fetch request, let's say, or something along these lines, and you get back some JSON data, which you then transform into HTML on the client side. Well, in this case it's just an HTML response that is directly injected into the HTML itself. 

CARSON_GROSS: Yeah, that's right. And actually, at the very bottom, there's a little shelf that you can hide and show. It shows the server requests. And so you can actually open that up and click through and see the content that's being exchanged with the server. In this case, it's mocked out. We won't go into the details of that, but you can actually see what HTMX is doing and how it's all happening. And so that'll give you some idea again, and you're absolutely correct. We're exchanging HTML with the backend. And one of the nice effects of that is that the backend can be whatever language you want. There's, because you're not producing JSON, you're just producing HTML. Not that any backend can of course produce JSON. But let's be frank about this. JavaScript is the natural environment for JSON. And so anytime your backend is just producing JSON, you have to ask yourself, why am I not using a node and just some JavaScript framework to do this? Well, in this case, you're just producing HTML. And so I think this gives people who, for example, there's a lot of passionate Django Python slash Django users who have picked up HTML recently, and they like it because then they can produce their HTML in Python, in Django, and do it the Django way that they like, but at the same time, still introduce relatively advanced user interaction patterns like active search to their applications. So I often say HTML is backend agnostic in that sense, in that it doesn't introduce any pressures or make any assumptions about your backend going back to the HTML model, which was, I'm going to exchange HTML with the back end and that's it. And however the back end produces it is fine. I'm going to take that HTML and I'm going to swap it into the DOM based on the user specification. 

DAN_SHAPPIR: Now in most cases, would an HTML website be like an MPA, a multi-page application with extra functionality or would you actually build a single page application with it? What would be your like preferred architecture for this technology? 

CARSON_GROSS: I just because I've been doing it for so long, I would start with a multi-page app and then introduce HTML where it adds the most value. One concept that I talk about sometimes is this notion of a complexity budget. And you want to spend your complete, you know, an app has so much complexity it can absorb before you just can't make it any better. And things just started getting worse. And so I like to keep things as simple as possible and then let the users interact maybe using just a standard multi-page application infrastructure. And then, okay, we've got this really important screen and adding active search to it would make our users life way better. So let's spend a little bit of our complexity budget, not much, I mean, we did this in three attributes with HTMX and then maybe a slight refactoring of your backend. But nonetheless, that's a little bit fancier than your normal stuff. And so let's spend that on this page that where it makes a difference. Rather than let's do this big bang, let's adopt even for like really simple form interactions, let's have a super complicated bit of infrastructure whose job it is to communicate a form to a backend. Why do that? Instead, let's just let the HTML, which does a pretty good job of this stuff, and HTTP, which does a very good job of this stuff. I would like to remind your listeners that HTTP stands for the hypertext transfer protocol. So let's use that infrastructure for the easy stuff at the very least. So I would probably, again, start with an MPA and then incrementally improve it. 

DAN_SHAPPIR: It sounds like an great idea and I wholeheartedly agree. I think that way too often people go for single-page applications where a multi-page application, the basic building block of the web, just navigating between HTML pages would have sufficed and in fact probably may have provided a better user experience. People like go for the sledgehammer where a screwdriver would do. And I really web pages and enhancing them. And one of the things that also occurs to me as I look at it is that you can also build it in such a way that it falls back really nicely to the built-in HTML functionality. So if for some reason JavaScript doesn't work at all, like you said, you just need to throw in the small JavaScript download to work. But let's say for some reason even that isn't downloaded. I guess you can just fall back to the standard HTML functionality and regular HTML form attributes and behavior. 

CARSON_GROSS: Yeah, that's right. So the terminology for what you're describing there is progressive enhancement. And HTML doesn't focus on progressive enhancement, but you can use a progressive enhancement mindset exactly like you're saying with htmx and htmx for example, when it issues an Ajax request includes a header that I think it's hx-request that you can inspect on the server side so that you know, oh, this was an htmx request, I need to render this bit of content versus, oh, this was just a normal request, in which case I need to render the entire page for that resource. And so, htmx tries to provide you infrastructure for making intelligent decisions on the server side depending on exactly what the structure of the request is. And so, that actually brings up another attribute that htmx has, which is the hx-push-url attribute. And when that is included on an element, it will actually interact with the history API to push whatever URL has been requested from the server into the history of the browser, and also up into the navigation bar. So, and with that, you can implement deep links, because when and it's fine. So one of the big advantages of NPA is this ability to have deep links or just have URLs for things that can be shared. And HTMX tries to provide that even if the interaction that's occurring is kind of this partial update of HTML content in the screen. Now, with that being said, that URL has to be able to respond to both the HTMX request as well as the full new page, someone just opens up a new tab and paste that URL, the server needs to understand the difference between those two. And again, HTMX provides headers to help you make that decision on the server side. And it's usually not that hard. Like if the header is present, then render a partial. If not, render the whole page, something like that. But it solves that deep link dilemma that you have with single page apps. 

 

Time is of the essence when identifying and resolving issues in your software and our friends at Raygon are here to help. Their brand new alerting feature is now available for crash reporting and real user monitoring to make sure you're quickly notified of the errors, crashes, and front-end performance issues that matter most to you in your business. Set thresholds for your alert based on an increase in error count, a spike in load time, or new issues introduced in the latest deployment, along with custom filters that give you even greater control. Assign multiple users to ensure the right team members are notified with alerts linked directly to the issue in Raygon, taking you to the root cause faster. Never miss another mission critical issue in your software again. Try Raygon alerting today and create a world-class issue resolution workflow that gives you and your customer peace of mind. Visit raygon.com to learn more. Their simple usage plans start from as little as $4 per month with unlimited apps and users. That's raygon.com to start your free 14 day trial. 

 

DAN_SHAPPIR: Now I see that you also implement a mechanism that enables more sophisticated logic for stuff like form validation. Can you elaborate on that a little bit? 

CARSON_GROSS: Yeah, one of the things that I've tried to do with HTMX is, so I have my criticisms of the people responsible for HTML. Again, I think HTMX is the direction that HTML is should be headed and there are just some very obvious improvements to it that I think htmx points to. But nonetheless, they have advanced in some areas. And so one of the things that is standard now is the HTML5 validation API. And so htmx, whenever there's something like this, htmx tries to respect that. So you can use HTML5 validations logic, the API for doing those validations and HTML will run those validations before it issues a request. So that gives you the ability to do some client-side validation using a standard API that's part of the HTML spec. Now, of course, as I always try and stress in these conversations, any validation you do on the client side has to be redone on the server side because the client side is not a trusted computing environment. So a hostile user can figure out a way to bypass those validations and submit invalid data. So you're always going to have to redo those validations on the server side. And that's pretty easy to do with HTML. Another example that you can look at is inline validation. If you just go to slash examples and then scroll down a little bit, there's an inline validation example. And what that does is there's an email validation that occurs and so you can see the email input on that page has an HXPost, which posts its value to the server side, to a slash contact slash email URL, and then that value will be verified to see, is it unique? That's the sort of validation that has to occur on the server side, right whether or not an email is unique in your system, you can't do that client side. You have to ask the server, does anyone else have this email? And so this is a simple example of where that validation is done by HTMX for that individual input. And so you can go down and type in, any email that doesn't match test at test.com will be considered invalid. So if you just go down to the demo and type foo at bar.com and tab out of it, you'll see it says this email is already taken. You get a nice little error message. And again, that's the sort of thing that I think people would typically expect, oh, I need to do some JavaScript to make something like that work, but you don't. Instead, you can express that in purely HTML or hypermedia terms using HTML. 

DAN_SHAPPIR: Now, in terms of actual projects that are using this library, are you familiar with such projects? Well, I assume that you're using it, but are other people using it as well?

CARSON_GROSS: Yeah, people, it's starting to get more popular and you're starting to see the first sort of public announcements. CommSpace is an application and the guy in charge of CommSpace, he was an Intercooler user for a very long time. And he's just recently switched over to HTMX and he also uses Hyperscript, the scripting language that goes along with HTMX if you want. And he recently, if you go to my Twitter account for HTMX, which is htmx underscore org. He recently posted a demo of his app updated with htmx and hyperscript, and it's pretty good. It's a pretty good demo. It's something that I would consider a fairly sophisticated web application that normally you would expect to be implemented in some sort of SPA framework. So we're starting to see them. There's a pull request that's open against CraftCMS, which is a popular CMS for in the PHP community that introduces HTMX into craft, at least on the plugin side of things. So I think it's starting to get some momentum, but Django is where the momentum first started. I think that's where you're going to see a lot of momentum. So if you're on like the R Django forums on Reddit, for example, you're going to see a lot of people discussing and recommending HTMX. Google hasn't adopted it yet. They should though. They should. Every time I use Google search, go to google.com and right click and view source and ask yourself, is this the world that I want to live in? 

DAN_SHAPPIR: Yeah, that's true. Now I assume that this is a labor of love for you. I know this is an open source project, right? But is there like, are you able to actually, you know, make a little bit of a living from it or hopefully or something like that? Or is just really purely a labor of love?

CARSON_GROSS: Not yet. Not yet. I do have a Google, or Google, excuse me, a GitHub sponsors page set up. And I'm very happy to say I've gotten some sponsors like any... I didn't expect anybody to sponsor it. But CommSpace is sponsoring it at the corporate level. I don't think that this will ever be what I work on. I know Caleb Porzio is making enough money on his donations to work on Alpine full-time. And that's wonderful. But there's a power law here with open source work. And so I don't expect that to be the case. I'm just a working staff. So I work at companies and I do recommend where it makes sense for them to use HTMX internally. I'm also happy if anyone ever wants to talk with me about it and maybe do some consulting, I'm of course willing to consider that. But I'm not really expecting to make a ton of money on this. It's an open source project. It's a labor of love. I just like the hypermedia model. I feel like the hypermedia model of development has been unfortunately neglected in the last 10 or 15 years. And so I'm fine with that. And hyper script is even more a labor of love. It's such a crazy programming language. I doubt very many people will find it amenable for their day-to-day development, but it is what it is. That's the story with open source.

DAN_SHAPPIR: One thing, again, looking through the documentation and the examples, I've got one suggestion for you. Maybe you already have something like that already implemented. You seem a bit averse to using JavaScript, but maybe still consider this suggestion. When connecting to first-party backend services, you know, you can tell them you can configure it any way you want. And like you said, you know, return HTML instead of JSON. In many cases, it's even more natural to do it that way. But when connecting to, let's say third party backend services, you get what they give you. Now you can obviously tunnel it through your own backend and, and, you know, transform the data there. But it might be a nice idea to also introduce support for using JavaScript functions for doing data transformations. So maybe having an attribute that specifies a JavaScript function via even its global name, whatever. And then if the response is JSON, you can feed it into that JavaScript function, get back the HTML, and then inject the HTML into the page the way that you currently do.

CARSON_GROSS: Sure. Yeah, I think that's a great idea. And in fact, htmx has something called an extensions mechanism. And so that is an API that can be used to extend htmx. One of the reasons, one of the ideas when I rewrote IntercoolerJS as htmx was I wanted to keep the core very small and focused, and very tight and focused on this hypermedia concept. And so, but there are a lot of very useful things that can be done that some people would find extremely useful. Like for example, being able to interact with a JSON API, but still using HTMX for that. And so there's an extensions mechanism, which you can see if you go to htmx.org slash extensions. And there are also some extensions that ship by default with HTMX and one of them, as luck would have it, is client-side templates. And so if you go to extensions.com and scroll down to the included extension list, you can click on the client side templates link down there. And you'll see that we provide the ability to take JSON. What this extension gives you is the ability to specify a template to apply to, to, to a given response and given JSON response. And so that can be used exactly in the manner that you just outlined where given this response from the server that is in JSON, I need to turn it into HTML. How can I do that? And out of the box, it supports mustache handlebars and non-JUX templates on the client side, but if you wanted to do something different, it's the extensions mechanism is very simple to do. And so you can plug in and use that for whatever sort of transformation you want to do. So the, the extensions mechanism was a big focus. of the HTMX rewrite of intercooler so that for situations like this where people had specific needs, I didn't want to include it in the core library, but I wanted people to be able to get at the internals and change the way it works. The extensions mechanism is how to do that. 

AJ_O’NEAL: Well, is that everything? 

CARSON_GROSS: Might be everything. We've got a couple more things I can talk about, but if that's enough for you guys, that's enough for me 

AJ_O’NEAL: to Jason, which this has been rebuffed in previous episodes as well. But one of the reasons we started switching to Jason is that we can use an API. We can, we can export that API to different types of applications. It can work on the Android app. It can work on the iOS app. It can work on the webpage. And so why, why have two versions of the app or, or maybe this, this is really just for HTML pages and very simple HTML content sites, but I guess, I don't know what my exact question is, but somewhere between, would you recommend this for things that are more on the appy side? And if so, why do both the HTML rendering and the JSON? 

CARSON_GROSS: Yeah, that's a great question. And it comes up a lot. And actually, believe it or not, I've got an essay on exactly that. So if you go to HTMX. There's on my right hand side, there's an essays and with some conceptual essays that I've put up and one of them is splitting your data and APIs. Actually, that's a typo. It should be splitting your data and your app APIs going further. And it links to an article where someone who's working purely in JavaScript, actually recommends splitting up your JavaScript app API and your public app API in purely JavaScript JSON terms. And he recommends that because he noted, and I would note as well, that there are different behaviors of those two sets of APIs. With an app API, you tend to be very churning and it tends to be very specific to pages in your application. Whereas your general data API tends to be very general and provide high-level things like some sort of query mechanism. And then it also tends to be rate limited and has these other things that go along with it. And so he was recommending this and purely just, okay, let's split our internal and our external JSON APIs up. I agree with that, but I think he should go further and say, okay, well, once we've decided to split those up because they have these different characteristics, these different fundamental characteristics to them, why not reconsider our internal API as a JSON API and think about, could we use HTML more effectively internally? So I would say, you know, I think there's obviously some argument for reuse across like your mobile app and your external customers and all that with a JSON API. But I think that for many applications, certainly that I've worked on, the use, the public API, the shape of it and the use cases for it are just different than the internal API. And so it's okay to split those up. And once you split them up and then the next turn of the crank is, well, would hypermedia be a more efficient way or a better, a simpler way typically is probably what I would argue from a simpler way to implement a very dynamic and restful application than using something like JSON. And I think the answer there is yes for many apps. You know, nothing's 100% but I think for many apps that would be the case. 

AJ_O’NEAL: That is the most well reasoned argument I have ever heard on the matter. 

CARSON_GROSS: Good. Well, I'm glad.

AJ_O’NEAL: Any software engineer should be able to consider and understand and agree with to some degree, even if their position is different for their use case. 

CARSON_GROSS: Sure. Yeah. 

AJ_O’NEAL: Well said. 

CARSON_GROSS: And you know, I'm... Thank you. I appreciate that. I'm pragmatic about it. There's going to be cases where HTML and HTMX isn't the right thing. So it's just you have to be mature about it and think it through. 

AJ_O’NEAL: So I noticed on that page something that I've only seen a couple of times HADES.

CARSON_GROSS: It's a bad acronym. 

AJ_O’NEAL: I agree. What? Yeah. 

CARSON_GROSS: Why do that? What is HADES? That was the other thing that I wanted to really probably talk about with your listeners. HADES. What is HADES? Well, you've probably heard the term rest before, right? And arguments about whether or not a particular API is restful or not. Yeah, 

AJ_O’NEAL: and to be clear, it's H-A-T-E-O-A-S for those listening and not knowing what the letter helps Google to get that. 

CARSON_GROSS: Yeah, it stands for hypertext or hypermedia, but we can just say hypertext, as the engine of application state. And that is probably one of the most controversial aspects of REST today when in terms of the JSON API community, the JSON API community uses the terminology rest quite frequently to describe what they're trying to do. And recently, for example, rest has fallen into like some people have dismissed rest and have started talking about like GraphQL, which is not restful. So then that's fine. I actually think that's a good thing because I, I mean, whatever you want to do it, it's all good. But I assert that JSON APIs are fundamentally not restful at all and that's okay. That's the other thing that I want to say. And the reason I assert that is because Hadeos or hypertext as the engine of application state is a crucial component of a RESTful system. And so let me try to describe. So, and the important thing to understand here is that REST and Hedios were descriptions of the original web. They were not, it was a description of HTML interactions of what Roy Fielding, the guy who coined all these terms, would call coarse-grain interactions, coarse-grain hypermedia interactions with the server. And so it wasn't a natural, JSON is something else. JSON is more what I would call RPC or remote procedure call oriented. And so Hadeos, the idea here is that if you think about a browser and you go to a page that has a bunch of contacts on it, right? The browser doesn't know what contacts are. It doesn't know anything about the concept of a contact. It just has an HTML representation of the contacts. And you can click on a contact and you can see what actions you can perform on a contact all without the browser needing to know anything about that. All it knows about is the HTML, the endpoints that, oh, there's a link that goes here, there's a button that submits this form. It doesn't know anything about the API, the actual network API that it's using. It's just interpreting links. And that is in contrast with your typical JSON API, where rather than the content coming down and telling you, hey, here's all these places you can go to do things, instead you go and you read the manual you read the docs on the JSON API and you know, okay, when I want to create a new contact, I hit this API URL. Like I, the developer, have to know about that. And so in a hypermedia application, all of the state is actually encoded in the HTML. And this is why these applications are so flexible. You can introduce new endpoints, you can introduce new actions, new links effectively into a contact UI and the human can see that link and say, oh, okay, I want to do that or I don't want to do that. Whereas with a JSON API, if you introduce a new link, a new endpoint, you typically have to update code. The code has to get updated that works with that API. So they're just fundamentally different network architectures. So the Hadeos SA is an attempt to explain Hadeos and REST really in terms of HTML rather than in terms of JSON, which unfortunately even the Wikipedia article on Hadeos uses JSON, and JSON just isn't a natural hypermedia, so I don't know why that is. So I know if I make a change to that page, it will get instantly reverted, and so I just wrote my own essay on how Hadeos really works. So it's a deep concept. This is a short conversation, but I would encourage your users or your listeners, excuse me, to go and read this article and then trying to internalize this idea like the REST and Hadeos. They're really talking about hypermedia interactions. It's not JSON is a different thing. And that's okay. And I think the JSON API community would be well served by maybe backing off on using the terminology around REST because it's just not appropriate. That doesn't mean they have to change anything. It's just recognizing, okay, this isn't a hypermedia. Like, JSON isn't a hypermedia. And there's some funny quotes from Roy Fielding on that, on my essay page that you can read that, where he's like, what do I have to say to people for them to understand the rest requires a hypermedia? But It's an interesting concept. Or it's an interesting, you know, and the whole history of this is really interesting, like how we ended up in a world where REST is, in my opinion, being used to incorrectly describe so much of what we work with on a day-to-day basis. 

AJ_O’NEAL: I think that's the entire developer ecosystem. Name one acronym or term that isn't predominantly used in the incorrect way. Take for example, JavaScript. How many quote unquote JavaScript developers do you know that know JavaScript? 

CARSON_GROSS: Yeah. 

AJ_O’NEAL: How many HTML, CSS people do you know that use HTML or CSS? 

CARSON_GROSS: Correctly. Yeah, it's true. 

AJ_O’NEAL: So I want to push back a little bit in that I think that the, the philosophy of REST, which is that you can, so REST in contrast to what people were doing in PHP before the Ruby community, Doug REST out of the archives and, and made it popular. 

CARSON_GROSS: Sure. 

AJ_O’NEAL: It was create a URL and name it whatever you want at the time. 

CARSON_GROSS: Yeah. 

AJ_O’NEAL: That was, that was the prevailing philosophy. And when, when rails came around and people started doing talks on rest, the important takeaway was, Hey, why don't we name things according to what they're related to and not pick the names at random, but actually systematically pick the names because if you looked at the way that things were being done in PHP before, before rails, it was an absolute nightmare. It was, there was no rhyme or reason to it. It was just throw it together. If it sticks, it fits. And so from that perspective, I think that JSON APIs, it makes sense to be restful. And some people go too far and they say, well, yeah, the users needs to be separated and it only needs to do with users. And if the user has a friends, then the friends need to be its own endpoint. And then if a user has purchases, the purchases needs to be its own endpoint. And it needs to be slash users slash one, two, three slash purchases slash five. 

CARSON_GROSS: Right. 

AJ_O’NEAL: And, and I take more of the approach of it's a guidelines that you should name things intentionally and you should scope things intentionally, but like we were talking about before, if your application has, uh, needs to get some profile information when the person logs in, you probably might as well not just get their name and their email address and then make 10 other requests for all the things you're going to load on the page when they log in, you probably ought to fetch their profile with all the things that they're going to need for the next five minutes, because why make a hundred requests when you could make two or three and then just cache the data. But I think that that, that too is kind of fallen by the wayside because people, uh, I don't see in, in the react code that I see, I don't see people doing those types of things properly or in a way that is conservative or of bandwidth and of having to redo things. I see people just, you know, just like it fetches everything all the time. Every time you click the button, it goes and fetches again. And I think that's the predominant behavior. So with all these things, I think there's a methodology behind it, which I agree. In the strict textbook sense of the original use of rest, it applies to hypermedia. And hate OS is essentially a layering on top of that, that gives more specific direction. REST is maybe a framework for frameworks and, and hate OS is maybe a more specific framework of REST. So I do agree that it ought to be hypermedia and that it ought to be standardized in, in the way that, but, but I also think JSON APIs are restful not in the hypermedia sense, but in the sense of organizing things intentionally. 

CARSON_GROSS: Yeah. And so, yeah, what you're pointing out is that the naming conventions that are used in restful systems. And I agree entirely with you that that made sense to port those over to the JSON world, at least to an extent and in many cases. But I would point out that the original dissertation where all this terminology comes from doesn't talk about naming conventions at all. That was an argument that happened like a decade later. And so that has become turn like, you know, we'd, I would, even I would use the terminology a restful URL layout. But to an extent, that's not, if you go, even the Wikipedia article on rest, isn't gonna talk about the URL layout. It's just not part, I mean, you know, URL is a resource and it is what it is, but Roy Fielding didn't have any comments on exactly how you should lay things out. And what is crucial to REST, again, and this is in the pedantic maybe, but like, you know, sort of nerdy sense, was this concept of uniform interface, where the client, in this case, the browser, really didn't know, like, the whole cool thing about REST is that the browser doesn't know what the heck it's interacting with. You type a URL into the browser and it just goes, and then you can be working with contacts, emails, a map like whatever, the browser doesn't know about anything about maps or contacts or emails. It's just getting hypermedia back and rendering it. And then that's, and that's it. And so it's this ability to encode all that interactively, internally in the hypermedia. That's really, in my opinion, that's the core, that's the crux difference between a restful system and a non-restful system. And there's advantages and disadvantages to it. Roy Fielding himself said, REST doesn't make a lot of sense outside of a coarse-grained hypermedia-based system. And, you know, so I just agree with it. It's tough because the language is, you know, so baked now. Like, I'm not under any illusions. I'm going to be able to get people to change broadly what they're talking, how they talk about JSON APIs. But the more people know at least the history of how this terminology evolved over time and sort of what the original meaning was, the better. So a couple of people here after listening to this, read that essay and understand, hey, the also a little bit better in its original terms and rest in its original terms, then that's, that's good enough for me. 

AJ_O’NEAL: Reappropriation is hard. 

CARSON_GROSS: It's fine. 

AJ_O’NEAL: Is there anything else that you want to, you want to chat about for another couple of minutes? 

CARSON_GROSS: Yeah, we're kind of at the end. If you just want to go through the picks, we can talk about it and you know, whatever, whatever works for you. 

AJ_O’NEAL: Yeah. Let's just go ahead and do picks. 

CARSON_GROSS: Sure.AJ_O’NEAL: And then hopefully Dan will jump again, but I think this has been good. I really appreciate your pragmatic and reasoned approach to things. I, uh, that jives with me. So good. 

CARSON_GROSS: Yeah. I tried to be, and when I was younger, I was more of a hothead about this stuff, but you get older and it's like, all right, it is what it is. It's fine. All right. 

AJ_O’NEAL: Well, I'll go ahead and start us off for picks. We'll see if Dan manages to hop back on and then, and then we'll save you our guests for last. 

 

Hey folks, this is Charles Max Wood from Top End Devs and lately I've been working on actually building out top end devs. If you're interested, you can go to top end devs.com slash podcast, and you can actually hear a little bit more about my story about why I'm doing what I'm doing with top end devs, why I changed it from a dev chat.tv to top end devs. But what I really want to get into is that I have decided that I'm going to build the platform that I always wished I had with dev chat.tv. and I renamed it to Top End Devs because I want to give you the resources that are going to help you to build the career that you want. Right? So whether you want to be an influencer in tech, whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever, I want to give you the resources that are going to help you do that. We're going to have career and leadership resources in there. And we're going to be giving you content on a regular basis to help you level up and max out your career. So go check it out at topendevs.com if you sign up before my birthday, that's December 14th. If you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's top end devs.com. 

 

AJ_O’NEAL: So the first thing we're going to pick, because we've been talking about rendering stuff on the front end. Now I don't, I'm not a believer in rendering stuff on the front end. I'm not, or let me reverse what I said. I said exactly the opposite of what it meant to say rendering the front end code, the front end HTML on the backend. I'm not, I'm not a big fan of that for applications, but I know a lot of people are using EJS, which I think is sad. And the reason I think it's sad is because there's such a better alternative, which is ETA, which is spelled ETA, but it's the Greek letter ETA, which I don't really know Greek that well. But anyway, it's essentially it's EJS, but maintained and it has the things that that every template system should have, which is layouts and matching brackets. So, uh, just the, the number of in any template, the number of opening tags and number of opening, number of opening and closing tags should always be equal. If your number of opening and closing tags are not equal, your tooling is not going to be able to lent your templates the browser is going to just barf on it, but then maybe do something that happens to be correct if you're lucky or just does anything at all otherwise. So that's really, really obnoxious. If you don't have layouts, it's easy to get in a trap of where you include a header that has more opening tags, uh, than it has closing tags or include a footer that has more closing tags than it has opening tags. And EDA makes it easy to do your templates in the sensible way that's going to work with your tooling and be standards compliant actually results in HTML that is a proper valid HTML that you can be proud of. And the, of course you can use these template languages for anything. It doesn't have to be HTML, but EDA is something that is good that I'd recommend if you, if you have burdened yourself with EJS, you can pretty much almost do a find and replace to fix the couple of instances where the, the two things are different. And then after that, I'm going to, I'm going to pick. So I don't exactly know what it calls, but the awake catch pattern. So one thing that I was going, I was going to pick fastify and I am going to pick fastify. Cause again, if you're using express, you probably ought to be using fastify instead because fastify is maintained fastify. I don't really care about the benchmarks and all that. If you wanted something performant, you'd be doing go or rust, but they claim it's performant and that's great. But that's not what makes fastify great. It's that it is, it is a maintained framework that is a, or not framework, but library that is the similar to express and has the modern features for modern JavaScript. But one thing that makes me sad is that even in their documentation, they do this, this tri-await pattern, which I consider to be an anti pattern for modern JavaScript or for any JavaScript. And so I got a little video on the await catch pattern, which is basically how to not have the tri-await code smell all over your code, where you're recreating the same promise pyramid of doom, but with try, try await or the same callback pyramid of doom. You know, people just find ways to re-implement the pyramid of doom. And if you use a wait catch, you won't be re-implementing the pyramid of doom. Other than that, it's just my normal stuff. Prismacraftsmanship.com. Feel free to post a comment there as well. If you've got a good resource that you think is really just a great engineering resource for JavaScript or for any language, would love to have that added onto there. And then the live streams and the contact info, if you want to either follow beyond code or add Coolage86. And then Dan is only partially connected. So I guess we'll give Dan a second and see if he's able to say his picks. And I can't hear you now. Okay, well that's good news is that we're still recording. So break that. All right, and with that, I'll turn it over to you, Carson. And maybe we'll loop Dan's picks in after the fact. 

CARSON_GROSS: Okay. Well, you've kind of set up a softball for me here. I'm going to, this is a little bit of a selfish pick, but we didn't get much time, or we didn't get any time really, to talk about Hyperscript. But if you go to hyperscript.org, you can see my other big project that I'm working on right now, which is a scripting language for the web that at some level is equivalent to something like AlpineJS. So you write code directly in your HTML. Has a very different syntax that's inspired by something called hyper talk, this old scripting language. And so it reads very in a very English manner. So you, the code would say something like on click toggle dot big text, which would toggle the big text class on the current element when you click it. We won't get too much into the details of that scripting language right now. But I did want to mention one very interesting thing about the scripting language, which is that it is something called async transparent. And what that means is that you were talking about the promise pyramid of doom. The way that the hyper script runtime works is that in any expression, promises are all resolved before it returns. So it effectively makes it async transparent. You don't have to worry about promises. And so you can write code in a linear fashion without any awaits or callbacks or anything like that. And instead the hyper script runtime itself figures things out. And so if you go to the docs page, for example, there's a section called no more promises. And you can see that you can write things like onClick, put the string I was clicked into me, which will change the inner content of this thing that I was clicked, and then wait two seconds, and then put click me into me. And that wait two seconds is what we would all be implemented as a setTimeout in JavaScript. But in the Hyperscript runtime, what ends up happening is a promise is produced by wait two seconds and the Hyperscript runtime resolves that promise before it continues. So it's a very high level scripting language designed to make it very easy to add scripts to your site. It's event oriented. So it's very driven. It's all designed to be driven by events. And that's, that's how it integrates with HTML. HTML emits a lot of events and you can use Hyperscript to hook into various parts of the HTML life cycle. But that's really one of the core cool features about Hyperscript. Now, this is a crazy scripting language that I would expect the vast majority of your users might enjoy, but a couple people who are listening to this might find it interesting. So that's at hyperscript.org you can go there and check that scripting language out if you like. And again, the concept that I'm describing is what I have termed async transparency, where you don't need to worry about callbacks or awaits or any of that stuff. The runtime itself is responsible for resolving promises rather than the script writer. 

AJ_O’NEAL: I'm not sure if I'm 100% with you on this one, but... 

CARSON_GROSS: Yeah, it's crazy. 

AJ_O’NEAL: You wrote your own language. That's cool. 

CARSON_GROSS: Yep. It's crazy. You know, like, so just as an example, on click fetch slash click message, and then put the result into me. That's something where, you know, you're issuing a fetch that's asynchronous, but you can write that code and hyper script and the promises will get all resolved for you. So you can just write it in a linear way rather than having to use a weight or anything like that. So again, it's not going to everyone's cup of tea. The syntax is very different. And I think someone on Twitter said, on first glance, this is the worst thing I've ever seen. And I was saying, really the worst thing you've ever seen? 

AJ_O’NEAL: I imagine you've been around long enough to hear this comparison. Yeah. Perl is a write once language or only language and Apple script is a read only language. 

CARSON_GROSS: Yeah, 

AJ_O’NEAL: Apple script came from hypercard and this is inspired by hypercard. And so this looks very much like Apple script and you pointed out right up top. Not Apple script. Not at the same. It looks I have struggled every time I've had any time I'm reading Apple script. I know what it does, but I can I part of it's the documentation is out there too. But I can never figure out how to write Apple script. 

CARSON_GROSS: Yeah, that's right. 

AJ_O’NEAL: Too much.

CARSON_GROSS: That's right. I think a lot of people share that frustration. But I do. And I think that there's going to be a bias against it because of that. And I totally understand that. However, there were and there continue to be a lot of very passionate hyper talk users. And I think AppleScript, for reasons that the syntax admittedly is a little crazy, but you're right that it's very readable. And that's one of the goals with Hyperscript is to produce very readable code so you can understand what's going on. And my hope is that with documentation, and then also it has a lot of stuff baked into the language it's gonna be very familiar to web developers. So for example, you can use a class literal, like you can use like dot big text to refer to that class or to all the elements that have that class. So there's hopefully better documentation, as well as a lot of things that are very familiar to web developers. It would make it less jarring to deal with than the Apple, the Apple script APIs that were just, I don't think very well done. So not going to be everyone's cup of tea. Totally get it. But if you're into more esoteric languages and if you really don't like dealing with callbacks, maybe it's worth a peek. Well, the documentation looks good. 

AJ_O’NEAL: I'll give you that for sure. 

CARSON_GROSS: Thank you. 

AJ_O’NEAL: This looks better than 99% of projects out there. 

CARSON_GROSS: Sure. Not hard. Yeah. 

AJ_O’NEAL: All right. Well. Hey, thanks for coming on the show. It was great to have you. Yeah. It was great to let our listeners hear about some alternatives to loading up their application with JavaScript. And, you know, at this point in 2021, I think if we go too far back in the other direction, we might almost reach an even balance. 

CARSON_GROSS: Yeah. You know, yeah, well, yeah, I appreciate that. Thank you for having me on. You know, I know this is definitely outside the bounds of what you normally talk about. 

AJ_O’NEAL: It's not. We cover a broad spectrum on here. So this is right on target for... 

CARSON_GROSS: Okay, cool. Well, and if I can ask your listeners, if they're interested, Hyperscript, or excuse me, htmx.org is the main website and I always appreciate GitHub stars. That's my primary source of compensation as an open source developer. So please head on over there and start the repository if this sounds at all interesting to you. And you can find me on Twitter at htmx underscore org. 

AJ_O’NEAL: All right. Well, thanks. And we will catch you later. Adios. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit C-A-C-H-E-F-L-Y dot com to learn more.