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.
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.
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: 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.
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.
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.
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?
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.
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?
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: 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.
AJ_O’NEAL: It was create a URL and name it whatever you want at the time.
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.
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: 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.
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.
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.