Transcript: htmx - Carson Gross

I'm Carlton Gibson, joined as ever by Will Vinson.

Hello, Will.

And this week we're very pleased to have on us Carlton Gross, who is um author of the very, very, very super exciting HTMX library.

Hello, Carlton.

Yeah, thank you.

Very excited to see uh the Django community taking a taking a look at HTMX.

So for the for the audience, let's let's go back a bit and can you give us sort of the back your backstory and then we'll get into the backstory of HTMX and what it is and what you know why we're all so excited.

Um so I actually I've I have to admit I've never done uh any serious Python development, at least not in Anger.

Um, but uh I've been programming for a very long time.

I uh programmed in Java just forever.

Um and uh I started doing web application development back in the late 90s, um, and uh just right when things were starting to get going.

And uh always kind of was in the Java world um until probably around 2005, and then I started picking up Rails and started doing uh a lot of Rails development.

Um and uh I still work on Rails in a uh there's a startup that I work for, well it's not a startup anymore, but uh a software company that uh I founded with a couple of other people um that's based on Rails.

And so the original library that turned into HTMX was called IntercoolerGas, and I built it sort of in the Rails with a with a Rails backend against a Rails backend.

Is that still holds?

Um and I still I write in a very idiosyncratic uh way.

Um I I tend to write in the older uh ES6, I think uh it's called uh form.

And uh I just I don't use the newer stuff.

Uh HTMX is uh IE11 compatible.

My understanding is that IE11 is being formally destroyed here in a few months, but I've always just I've I've always uh I've always coded and I found a way that I like to where I can can write JavaScript without uh creating too many bugs.

It's a very functional uh way, but it's it's very idiosyncratic.

So when normal, you know, quote unquote normal JavaScript developers come and look at my code base, they uh are often very confused.

Um I have found that other people coming from outside the JavaScript community find it uh fairly approachable, but uh it's definitely not the standard way to write JavaScript.

Because if you were using Rails, like okay, so uh let perhaps we need to fill in some context for people who don't know about HTMX.

So let's talk about briefly what HTMX is and then we'll cut back to the history.

We're just writing a normal vanilla web app.

Um the the problem that you run into from an interactive standpoint is that uh every time you click on a link or submit a form, you're gonna do a full page reflesh.

And so you get that clunky, you know, uh full screen re-render.

And so one step into the mindset of HTMX and Intercooler was well, why don't we make it so that those can replace a part of the screen rather than having to replace the entire screen?

So that's a step towards that, and thinking about okay, let's take let's take the hypertext that we've got HTML and let's extend it so that it can do uh do more stuff as a hypertext.

Um, and so replacing parts of the screen is one.

Um, maybe responding to other events, not just click and submit, is another uh way to improve uh the way HTML works.

Um maybe you don't want only anchored tags and forms to submit to make uh server requests, right?

Very often you have other like divs or whatever that are making requests these days.

Um then you know I also the the last kind of component in there is uh uh making all of the HTTP actions available, um, so it's not just get and post.

Most web apps, unfortunately, are hamstrung by the defaults in uh HTML where it's really it's it's only easy to uh issue gets and posts, but there's other stuff, there's deletes, and so you know, there's all the restful types of actions that you want to use.

And so taking all of those and making surfacing them in HTML is sort of what uh what HTMX does.

It was just one example.

So you can have a an app that uh has the nice features we've come to like from the more uh extensive front-end frameworks like React, but hopefully without all that heavy weight, without all the coding infrastructure that was necessary for that.

So let's swing back to so with HGMX in play, so it's this this cool library, and you talked about building it um working with Rails.

Um but Rails has um well for my history it was Pjax and then TurboLinks and then the hotwired stuff, and so I found HDMX f in the the few weeks after the um Hotwire announcement where they had the nice website and there was a lot of hype and then someone mentioned Adam Johnson mentioned HDMX.

I was like, Oh, what's this?

It's in the same space.

Umx in particular, Pjax.

I mean, I used Pjax back when that was the the big option.

Um and uh TurboLinks, obviously in the Rails community, is very big, and people use it outside of Rails as well, and it's a good piece of technology.

Um but I uh when I was looking at it, I felt like uh things it just needed more it needed more of a formalization.

Um TurboLinks and Hotwire both kind of have a magic.

They they reflect, I think both libraries reflect the personalities of the um the people who are developing that.

And so DHH really likes magic, like he wants links to just work.

And uh to me, when I when I especially as I got into it and started to figure out what I wanted Interpooler to be, I felt more like I was coming at this from the direction of I want to improve HTML as a hypertext and not provide some total solution that is magic and everything works, you know, but it's hard to understand what's going on.

So HTMX, I hope, is is fairly incremental, and you can you build up, you know, a few uh a few attributes and you you understand what's going on.

It's not just automatic.

Yeah.

I was trying to think more, let's go with the grain of HTML and and take it further rather than let's just make it all work magically.

And one answer to that question is that Django you kind of do it, it that it's not quite so auto-magic.

It you know, Rails gives you the full controllers and the Ajax forms and all the things just out of the box, and that's lovely.

Whereas Django, you have to wire that stuff up yourself, but but you know, there's a bit more flexibility perhaps, or you know, yeah, who knows you know, you can

You have to be careful with uh too much magic because you can you can have sort of a uh a helpless feeling when it doesn't do what you want it to do, right?

Um it's I've I've kind of moved away from you know trying to minimize everything, and uh it's it's okay to be explicit at times.

And so HTMX is definitely it's much more explicit than some of the other options that are out there for this style of development.

I should mention uh live live wire as well, that's another example.

And in both of those cases, uh HotWire is the same way in that it requires WebSockets, there's a server-side component to using it that is necessary.

And HTMX does not have that explicitly.

I've I've been trying to focus, just it's purely extending HTML to hypertext, and therefore um it's not, it doesn't make any specific requirements on your backend, so it can be used with anything.

Django is a great example of something it can be used with.

What's the story there between the change in the libraries?

And uh I came out of the jQuery world that I was I did a lot of jQuery development, and so intercooler.js was based on jQuery, used the all the jQuery infrastructure.

And uh last summer um you may recall that uh the the the world kind of shut down, and so we uh I was sitting around and thinking, all right, what do I want to do with myself to keep from going insane?

And uh I it always bothered me that HTMX uh it increasingly it didn't at the start, but it increasingly bothered me that uh intercore was dependent on jQuery.

And JavaScript had come a long way in the last you know seven or eight years, and so I said to myself, all right, well let's try and see how hard it would be to break that dependency on jQuery and just write it in pure um pure JavaScript.

And uh along those same lines, one of the things that always had bothered me when I tried to tell people about InterpolJS, and I have to say I've gotten quite uh quite quite a lot of grief uh on the internet when I tried to talk to people about this style of development, uh particularly in the JavaScript communities, which is it's understandable.

Um but uh it it they were they the library was uh being compared with React.js or with whatever, whatever the big JavaScript library of the time was.

Initially it was what what was Google's?

Angular Angular, yes, thank you.

And um, and I I just so I didn't like that.js aspect of the name because I felt like what I was really trying to do was push HTML as a hypertext and see how much expressiveness we could get in HTML itself as a hypertext.

And so I started looking around for better name, and HTMX.org was available, and I was like, well, I mean, come on, you gotta take that.

That's crazy, it's still available in 2020.

Um, and so that and you know, that obviously there I did a lot of documentation rewrites and so forth, and really tried to clean the library up as well.

Um, and I'm much happier with HMX.

I think Intercooler is a great piece of technology.

I'm not, and if you're using it, don't feel like you have to move to HTMX anytime soon.

Um, but I think HTMX is a much cleaner, is a much cleaner implementation of the concept.

Okay.

I'm curious.

So the idea of the virtual DOM came out, because that was that took a while for most people to wrap their heads around.

But then it was pretty amazing.

And but then you looked at that and said, well, let's go the completely opposite way to achieve something similar.

I think that's amazing.

Like because yeah.

So um I've always been a little bit of a contrarian um by nature, and uh that that's good in some ways and bad in others.

Um, but uh you know, I just it really came out of the the original uh concept came out of a situation where I was writing some pretty hairy jQuery code to update a table dynamically, and uh the performance was just atrocious, and so I just almost out of desperation tried rendering it on the client side and then slamming it into the DOM and it was instant.

And so I said to myself, well, self, let's not do a bunch of front-end stuff, let's just try and formalize this notion of you know Ajax grabbing some HTML and slamming it into the DOM.

And it's obviously become much more sophisticated than that at this point, but uh it it came out of that that world.

I just I don't know.

I sometimes I feel like I'm not as smart as some of these other people, and just it's like I can't I can't figure that out.

I'm just gonna do it this way.

Like, because there was this thing that I I was using a long time ago, jQuery.load, right?

Which would get your HTML and it would replace the content of the div.

And I was like, oh, this is quite good, and that I wasn't allowed to use that for a long time.

Yeah, we're bringing it back.

Maybe we'll talk about hyperscript too.

You don't want to you wanna get really, really obscure.

But the performance of that and the the the bandwidth required for that seems to be quite high.

And then all and feet for a number of years I felt as if I'd been swimming against the current of this kind of you you just must do it this way, otherwise you can't possibly compete.

And yet here we are, we've HTMX comes along and you know the the related um libraries that are in the similar sort kind of domain.

And it's like, no, but we can just render the the the HTML on the server and inject it in the DOM.

And that works.

I mean, what uh just at that kind of theoretical level, what what do you think is going on?

And you think that's well I

Um, and some you know, we've we've been down some bad paths.

Uh Google, you know, everyone trusts Google, everyone trusts Facebook, Google at GWT, um, Angular, I think Angular 1.0 anyway, is widely agreed to have been a pretty terrible idea.

Um, so there's a lot of bad ideas that come along.

We just have authority based on where they come out of.

Um we also we're a forward-looking industry.

Um, we don't do a great job of taking what works and building on it incrementally.

Um and that's you know, I think there's some personality traits to like good developers that make that difficult.

You want to be innovative.

Um, and uh there's the the whole job situation, right?

Like being left behind technologically is is a fatal, can be a fatal situation in the tech industry.

And so that puts a lot of pressure on people to look for the new stuff.

Um, so uh you know, but when you look at if you if you're able to take a step back and look at things from a from a little longer perspective, and I don't blame people who can't, you know, someone whose only experience with web development is React and like that entire infrastructure, you can't really, they just they don't they don't have that that longer term perspective on the way things are.

Um and the the you know the original web architecture, I don't feel like it was communicated well.

Um rest and Hadios kind of got tied up in the API community, yes, and uh the web development community kind of lost touch with what you know what the web architecture was.

The web was just kind of this VM slash janky U UI markup U UI markup language that lived almost by accident on everyone's computer rather than an innovative new network architecture, which is what you know originally it was intended to be.

So um, so you know, but uh again, I don't blame people uh uh for I I do blame a little bit the Facebook and Google people, I'm sorry to say, um, just because I feel like they uh they're if anyone had the ability to communicate the original web architecture well to the broader development community, it was those companies.

And uh and I I don't see a lot of that.

Um but you know Fielding's uh got around here somewhere, his uh his thesis, you know, his PhD thesis that outlined the web architecture is pretty impenetrable.

It's not easy reading.

Like, what is this guy talking about?

Well, all right, we'll focus on the practical stuff first, and then maybe we'll talk a little bit more theoretically.

And it sounds like I've again I've I've heard you say, you know, the W3C kind of basically stopped with HTML, which is kind of true.

I mean, it was created and then they stopped it post with forms, and and yet there was all this other information there.

I'm so I guess my question is had anyone else tried to tap into these things?

Because it seems like in hindsight it was just sitting there and everyone just hopped in the JavaScript train and didn't take a solid look at it.

Yeah, I agree.

In Zoolander, there's that that line where he says, Am I the only one who notices this?

And uh, and when I the more JavaScript I saw, the more I was like, man, what about hypertext?

Um so you know, I I don't know what to say other than I'm glad that I was able to to to work on this, and it seems like it's working out pretty well.

Um, I think a lot of people when they when they see it, they're like, oh yeah, that that seems sane.

And um, so there is something there.

I I tried to open an issue on the discussion forums for HTML, for like the W3C, I don't know what it was.

Someone sent me a link.

So these people do browser stuff.

And so I tried to open up a discussion there about extending HTML as a hypertext, but it it didn't go particularly well.

And I understand that, you know, this random guy's saying, hey, we should think about HTML as a extending it as a hypertext, and they're like, Cool, who are you?

The image tag, right?

They just implemented it, everyone went with it, and then all of a sudden they said, Well, we better standardize it.

So if you can just keep pushing, you know, you

get that.

Fair enough.

And I um and I'm I'm I'm I'm more than okay with that.

Um, but yeah, I do you know there is kind of a weird like, wow, why didn't we just do this?

I I'm just one guy.

We've got a small uh but you know, good little community around HTMX and Intercooler.

Um, but you know, there's just there's a lot of momentum.

And JavaScript say well and will about it.

You can do the everything you you need to with it, and so um, you know, I don't know.

You just if you're not if you if you're not convinced, if if the hypertext uh architecture doesn't speak to you, then you know, I I can see why you might be more inclined to look at a JavaScript solution for things.

And the the poor Django templating language has been sat there all the time, but we use it for a bit, but oh, you know, I've got to do it in front of.

But actually, you know, having picked up HTMX and started implementing, it's like, no, I can just create my my HTML template, I can send the server.

I don't even actually need a rest a DRF view, a REST framework view.

I can just do it, and then all of a sudden, I think, right, I need a I don't know, I need a a crud for a related object that is triggered by this drop down.

I just create the the create view, the update view, the retrieve view for that, and it's all really vanilla Django, like the most basic Django in the world, but it's coming to the browser really smooth, in page, quick, and you know, I go and do the lighthouse, the um what is it, the audit thing that you've got in Chrome for the speeds, and it's lightning, you know, it's like yeah, green.

Yep.

Um that's exactly right.

So you can you can rely on old and very proven server-side technologies.

And in fact, as you're probably noticing, the the encoding difference between HTML and JSON is almost nil.

Um so you know, it's uh I think one of the great things about HTMX is that it brings these these tools that are very mature and we have a lot of experience with, at least some of the older web developers have a lot of experience with caching.

You know, you brought up caching, and that's a good example.

Like a well-cached web app can be very, very fast.

And uh that's that can be hard to do if you've got if you're fronting uh an arbitrary uh uh query API in JSON, right?

Like caching that can be very difficult.

Um and uh but if it's if it's just an endpoint with a get, you know you can cache that, and you can use whatever you know mature caching technology you like to make that much much faster.

Um, and that does bring up something that I think is worth mentioning about when you you mentioned building JSON APIs in Django.

Um the your your web apps tend to be kind of needly, like they tend to have very specific needs, like you have to tune a query to make a particular uh UI work quickly.

Yeah, right.

You've got to do joins or group buys or whatever it is on your back end.

You have something very specific for a particular UI to make it work correctly, and that's intention with a more general JSON API.

When you give the when you give out a JSON API to the wider world, if you're you know going that direction, those tend to need to be very general.

And so um you need to have uh you need to have a more generalized uh API.

And the the the reason why we have technologies, what's the I always for I always want to say jQuery, but what's the Facebook query?

GraphQL standard GraphQL, thank you.

I always want to say jQuery, but

we can call it that.

And so um one of the really nice things about using something like this GemX is that those needs get moved back to the back end where they have SQL and they can do whatever damn cool thing they want to do against the database, right?

And then you know, maybe you need to tune the database with uh uh with indexes and all that sort of stuff, but that's that's an achievable engineering goal versus this more generalized JSON front end API.

So I think those are two separate use cases.

Um they have two different technical requirements, and uh you would see this about you know before uh before jQuery slash uh GraphQL came out, before GraphQL came out, uh you would have API developers that were they were just they were in despair because they were constant, you know, you'd be on version 35 of your API before you even shipped one point over your web app because there's so much churn and just small little changes to make your UI work properly.

And actually it's a front-end thing, and it certainly is if you're you know serving HTML and then using something like HTMX to get your interaction on the on the browser, is that you you can write the view, serve the templates, and you're the front end, you're creating it.

And that's the hype that's the that's the architecture of the web, too.

That's which is yeah, yeah, that that's actually how it's supposed to work, believe it or not.

I know, I know, everyone uses JSON now, but it's not actually a JSON isn't a hypertext, guys.

Well, fine, you can add that.

But if if it doesn't have to be your sort of core starting point, it just smooths the development process so much.

And so I and that I I I agree 100% with that.

You should have a JSON API probably, um, and it should be public and it should be rate limited, and it should have all these sort of, you know, that that's you know, for automation purposes, that's great.

Um, but that's not the web.

That's that's probably not for most applications, anyways, not what your web app should be talking to.

Okay.

Because I mean, we're both fanboys.

Yeah.

Um, Adam Johnson, a whole bunch of people I really respect are huge fanboys, but there are some limitations.

I mean, so maybe we just talk about this.

So one is so an easy one is um just maturity of the ecosystem, right?

Like in terms of uh so maybe we could start with that.

Like how where is that at?

And do you see a path for people to add things on?

I mean, because you have fantastic documentation on your on your site, by the way.

I love that examples page where you just go, boom, here it is.

Like you, oh how can it do it?

It's just like right there.

But you can't do everything.

Um, yeah, that's I mean, it's a problem.

I'm just uh you know, I've got there's some people who contribute, but it is really it's a one-man show to a large extent.

Um uh and uh I'm just a dude who lives in Montana, so not Google, not Facebook.

I don't have the uh the resources that they have, and the I just you know, with Intercooler, I I don't want to say I gave up, but it with both of these libraries, they're kind of they're finished.

I think I got the API reasonably correct, and the implementation is probably good enough, so I'm not planning on changing them a whole bunch.

Um, so while yeah, you know, nobody ever got fired for using React.

Um and I you know I understand that dynamic.

Um, there's there's only so much that I can do as a small you know software shop.

Um, and uh I think you intercooler to an extent since it's been around for so long, it's got 4,000 some odd stars on uh on GitHub.

So it's a you know it's a medium-sized JavaScript library, relatively mature.

HTMX is based on it.

HTMX definitely is maturing, it's not as mature and it's it's still uh maturing a little bit, but um you know I would I would say if uh if you're a if you're a maybe a more senior developer and you have some pull in your organization and you really like this style of development, the Discord is active.

Um you're you know, as long as you're not trying to do anything too crazy, you're gonna probably get the help that you need.

But I don't want to present it as that there's no risk.

It's not you're not gonna be able to hire an HTMX consulting firm to come in and uh and help you.

But you know, I'll help you if you jump on HTMX general.

Yeah.

Well, there is

I was just gonna say, um, so Adam Johnson again has this Django HTMX um package, which bundles up a lot of things.

I was just sort of wondering if if you could clone yourself a bunch of times, what would you work on to expand the ecosystem as opposed to working on the backbone?

I I would need to think more about that.

Um I think just just I just advocate, just advocating, maybe trying to explain.

I I just had so little success trying to explain the original, the the like the web model to people, just putting some time in and trying to think about what the best way to reach people is, and then honestly, you know, I I'm allergic to social media, but I'm on Twitter because you gotta I don't know what else to do.

I tried write it for a while, I just couldn't take the trolls, so it was too it was too emotionally difficult for me to deal with.

Um so uh I I think you know a lot of stuff that sort of outside development, which I'm just not great at, unfortunately.

So for me, I'll just probably keep grinding along on this and coming on podcasts, and you know, we'll see what happens.

It's but I've been really happy with as much uptake as it's gotten, especially with the Django community finding it, because Django has just been so underserved traditionally by the front end libraries that are out there, and this dovetails really well with it.

So, you know, uh that's my hope.

Um, but as far as technically, like if I clone myself in, have more engineers, I'd probably just write more tests.

I haven't dug in and seen, but I'm I'm always trying to choose a JavaScript test framework and I never know which one to go for.

Is it Jest or is it this?

Chai and Mocha.

Chai and Mocha.

I mean, this is why people don't use HTMX, right?

I just picked the most popular ones out there at the time I started the project.

Uh so but and I I I I used to use a different one that was more browser friendly.

Yeah, every no the one of the problems I have in in writing a lot of JavaScript is that I try to make everything very browser-centric.

And uh the JavaScript world has moved away from that more towards like a this mixed mode or node-oriented world, and so it's it's actually it's gotten harder and harder to do browser testing, which is for all my stuff, I just want to do browser testing.

Um, and uh so it wasn't a great experience compared to what I was using previously, but that that one had apparently died.

Can I ask?

So, in terms of a limit though, I mean, if you were gonna build Gmail or you know, something super dynamic, do you feel like there's a possibility that HTMX could eventually do that?

Or like where is that cutoff?

Because there is still, you know, oh yeah, a cutoff somewhere.

So I I think Gmail should be built in something like HTML.

So there's no reason for it to be right, like that's I don't know.

Google Maps is definitely over the line.

Um, so uh if the more the more client-side state is required for an app, you know, just so like a 3D game or you know, even a two like a 2D game, this is just not something that's gonna be done well in

Um but Google Maps is a good example um uh of something that wouldn't be done well in it.

On the other hand, the settings page in Google Maps uh would be probably something that could be done very well in your page.

Yeah, isn't that crazy?

I flip the switch and for keyboard shortcuts, and then it's like, oh, I didn't, it's so ridiculous.

Um, so that's the sort of stuff where you know HTMX is lightweight enough that you can use it for parts of your app.

And so there are parts where it probably makes a lot of sense, and then there are parts where it doesn't make a lot of sense, and not just in the more complex world, right?

There may be parts of your app that just the old, the very old simple click on links and submit forms works fine for that part, and you don't need to add HTMX, you don't get much by adding HTMX to it, and so just leave it that way, and you that simplicity is its own reward.

Um, but maybe in some parts of your app you want to do something like active search, right?

Whereas you type the results filter down based on some server-side uh filter, and so okay, then just add a few HTMX attributes just there and implement it just for that spot.

And so so I think it goes both ways.

HTMX can be too complex for some things, you know, proof of concept before you you're really into something, and then it can be too so too simple for other stuff.

Like you're not gonna obviously um in the main write a video chat system or

something like that.

Like that's uh sorry if I interrupted you, Carlton.

Like I feel like WebSockets is something that's there but not being really used in the same way HTTP2, it's sort of like sitting there, but

I I do have to admit those are both much more raw than the Ajax support.

Um, and so uh, you know, I those are I would say more speculative.

Um, but they're there.

Um and you know, it's a hopefully reasonable approach from as far as a declarative HTML-centric uh way of using those technologies goes.

Um, but it's it's definitely a newer, it's a it's a newer uh area of web development, and it's harder to be sure that we got it right.

You can open a long a long request, you just don't close it and you just send a new event when one's ready.

But quite often you don't need that.

Like you don't you don't even need that to leave that connection open and poll.

Whereas you can just make an Ajax request and you get it back.

And then WebSockets that want what you're sending two directional traffic.

Well, quite often you don't need that, it turns out.

Yeah, I know.

Uh I I feel like you can do quite I've done quite a bit with just good old Ajax and maybe some polling.

There's a way to poll in HTMX that makes it pretty easy.

And uh you can accomplish quite a bit, you'd be surprised.

Okay, so

Okay, you got it.

And like for rich things, I've been using Elm for a while, but much closer to the to the HTML stuff.

I've been using Alpine, Alpine.js, because I saw it on the I think it was the Tailwind people, they were like, if you would be using jQuery, you should be using Alpine.

That was kind of how they score it.

I'll give Alpine a go.

And it's it's the same sort of thing.

You just define a few attributes and you know it creates a component and you can you can save a like a an object there, and that object can have methods, and it's just nice, really quite small.

And they they say it's like view, but I wouldn't know having not really looked at view.

Um and that's great for you know when I want to maintain that bit of state.

But you've got this other thing which I'm I'm almost in fear of trying.

It's called um hyperscript, right?

And it's so fresh and new, and it looks amazing.

I'm just terrified of what is it?

What's going on there, and why is it how

That is the appropriate that is the appropriate response.

So uh, what is hypertalk?

Um, well, so uh we we talked about how uh HDMX came out of Intercooler, and uh it was sort of a cleanup of Intercooler, a lot of stuff that I learned and uh while working on Intercooler and things that I wanted to improve about it.

And one of the things that was in Intercooler that is not in HDMX was something called uh the attribute was IC action, so IC-action.

And that was a little uh way to do some client-side scripting, mainly uh in uh in with jQuery stuff.

Um, but it it had this kind of funny uh syntax and it lets you do uh to insert weights, like you could put a weight three three or three hundred milliseconds or whatever in the middle of it, and it was a really simple programming language.

I mean, I didn't admit it at the time, but it was a really simple uh programming language.

And uh so when I created HTMX, I looked at that attribute and was like, you know, this is this needs a better treatment.

This needs a real I'm I'm I'm a programming language person.

I worked on a programming language called Gosu for a long time, which is a JDM, it's an obscured uh JBM programming language.

Um and uh I I just looked at that and said, you know what, if I'm gonna do that, I need to do it right.

This is too janky because uh, you know, Alpine.js exists, and so if you just want to put a little bit of uh of JavaScript in the DOM, which will uh uh remind me, there's a concept I want to talk about uh around that.

Um, you know, you can use something like Alpine.

And uh so uh you know, like I said, I'm a programming languages person, and it's always dangerous when a programming languages person sees a problem like this.

A new language.

And uh so I decided, okay, well what this really is, is this is a programming language that is responding to events, and so I reached back into my memory, deep into my memory banks, and I remembered a scripting language called uh hypertalk.

Um, and hypertalk was a scripting language that was a part of the hypercard development environment on the Mac.

A long, long, long.

This is MIST, right?

Um, and uh it's a it's a uh one of the really unique things about Hypertalk is that it had event handlers baked into the language.

You didn't call you know something.addEventHandler.

You just said on click, do this stuff.

And uh I thought to myself, well, that that sounds like exactly what I need.

Um and uh hypertalk, some people most people haven't heard of it, but some people have experience with Apple Talk, and that experience is not good in general, um, and I appreciate that, but um that both both Apple Talk and Hyperscript are based on HyperTalk.

And uh so basically what I'm doing with this programming language is trying to create a purely front-end oriented scripting language and a true scripting language that allows you to do things that you would do normally, for me anyways, in jQuery.

You might use vanilla JS, but it's uh still pretty ugly compared to a lot of the jQuery stuff.

Um, and so it's that that's what it boils down to.

There's some interesting characteristics about the language that I'm sure we'll talk about, um, but at a high level, it's a front-end scripting language.

It's designed to make it easy to handle events and then do simple things like adding classes to other elements.

So and I think hyperscript is intended as a modern replacement for jQuery.

If you were to ask me, you know, what are you targeting?

It's it's trying to be a modern replacement for jQuery.

Maybe a slightly insane replacement for jQuery.

Just in terms of I mean, yeah.

That's not like you're coming in.

So I I when I came in, I taught like a you know JavaScript web class, and it was like, yeah, do the fluffy stuff.

They're just bringing you into you know the depths of a CS undergrad degree.

So I just I saw that yeah, I was like, man, that's that's legit.

I feel like that's where philosophically I'll probably end up in 20 years is also trying to you know write a new language to solve all my problems, but I'm nowhere near there.

Yeah.

Um if if you learn recursive descent parsing, um recursive descent parsing isn't taught in academia.

I teach it because I don't like the way uh people teach parser generators instead, which is a it's much better for producing papers in academia, um, but but uh but I think it's much worse as far as learning how programming languages actually work.

And so uh it's unfortunate because I think creating a programming language is a mystery for a lot of people, and it doesn't need to be.

Um the parser is actually easier than the tokenizer in many situations.

Like breaking the string up and uh into tokens is that can actually be like the tokenizer in hyperscript is totally insane because of some of the because of some of the syntactic stuff that we support.

And I should mention hyperscript is a is a is much it's it's gonna strike many people as strange because it's more of a natural language.

So you would write something like on mouse enter toggle dot visible on hash help until mouse leave.

And so it's got this English syntax to it that's very can be a little jarring.

It's very easy to read, but can be a little jarring.

And I'm just like, ugh.

And and hyperscript, again, for me, is like that's my fine project.

I don't expect it to be too widely adopted, um, but there's some cool stuff in it.

There's some cool stuff in it.

One aspect that's cool that I kind of alluded to earlier is uh that you embed it directly in your HTML.

Um, and so, like as with Alpine and uh as with Tailwind CSS, you put everything into the HTML.

It's HTML centric in that sense.

And um what that gives you is that when you're curious as to what a button or whatever is doing, you can look at that button and see everything that it's doing there in the HTML.

And that is in contrast with the jQuery approach of adding, you know, over in some other JavaScript file, you would add uh a handler, you know, kind of dynamically.

And so I'm trying to popularize this terminology of uh uh locality of behavior.

Where you you you you're localizing all of the behavior of a particular code unit, in this case a button in an HTML file, on that button so that you don't have to go search around in 15 different files to figure out what that button does and why it looks like it looks like.

So HTMX also has this characteristic where we can just look at the input and see, oh, it's posting to that and then doing something with the results.

And so I'm trying to again popularize this notion of locality of behavior to explain the popularity of libraries like Tailwinds, obviously Tailwinds is the most successful, but uh also Alp by and HTMX and maybe at some point hyperscript.

It's the the fundamental handler of the framework.

And we have this these class-based views, which are great and they're powerful, and they you know let you define standard stuff very simply, but they have this kind of awkward hierarchy.

There's too many of too many class ins classes and too many mix-ins, and if you there's this whole website devoted to making the class high hierarchy browserable so that you can navigate the class-based views.

And it's like that's the problem, is that you've got five files open in the editor.

You can't, but by the time you get to the fifth one and go, oh, that's where it comes from, you can't remember what you were looking for when you started this little search.

And to have everything in the screen in front of you is just uh it's just so important or so empowering.

Yeah, um, he wrote the worse is better paper.

I don't know if you've ever read that, but that's a pretty good CS paper to read.

Yeah, Worse is better.

Um that's about why Unix beat Lisp.

So he was a Lisp guy trying to explain why the Unix and C world beat Lisp.

But he has a quote that I like a lot that says, the primary feature for easy maintenance is locality.

Locality is the characteristic of source code that enables a programmer to understand that source by looking at only a small portion of it.

And so I include that as the sort of leadoff quote in my essay on the HTMX.org website about locality of behavior.

And uh and I think that captures that idea very well.

Like if you if you want to be able to maintain and understand code, you have to be able to sort of see it all in one spot.

The more places you have to go to understand why how something works, the harder to maintain that code uh you're going to find it in.

I I mean I don't see it, but I feel like there must there must be, you know, there must be some downside or potential downside.

Yeah.

Yeah.

I mean it can be it can be overwhelming if you try to do too much, right?

You still you still need to factor things properly.

Um but um but fat to me you you want to factor, you want to pick the right axis to factor on.

Um and so uh pulling something out to a component might be appropriate, but then that component, looking at that component should be understandable just by looking at wherever that component happens to be defined.

So you still need to factor properly, um, there's no doubt about that.

And you know, there there comes a point like we have extract method for a reason, right?

Like you you wanna, there's gonna come a point where there's just too much code in line, and it's time to pull stuff out to a method, and that's okay because you can see okay, this calls that method, and I can hopefully, if my editor is powerful enough, I can control click on that and jump over and look at the definition, and it's got a good name, and I can, you know, I can live at that level of abstraction and still understand what's going on here.

Uh hopefully the method isn't named do it or something like that, right?

Um, so uh there's a danger, yeah.

Do it too.

Yeah, um, do it again.

Uh so you know there uh I but that's to in my mind that's just proper software engineering.

Um, and I think that we we've fallen into uh this idea of separation of concerns a little too by by default, just because that's the way the web was set up almost by default.

And you know, tailwinds I think is the most successful going against that grain.

You know, the the concerns are not separated at all if you're using tailwinds.

And uh that to me, when I first saw it, I you know, my I kind of my shoulders tensed up and it just felt wrong, but uh, but it's quite popular and it's proven to be a very successful way to build website.

No, I refuse.

No, no, and after a little while, it's like hang on, this is quite fun, and then you know, and you create reusable bits.

Maybe it's okay to repeat some stuff a little bit, if that makes it clearer what's going on.

You know.

Right.

And it's like, well, it's actually implicitly goes to get absolute URL in your models.

So it would probably be it would definitely be clear to put that in there, but it's repeating yourself, so that that's attention.

So I would say in that case, maybe so yeah, it it depends.

So we always try to we always try to avoid the saying that in our podcast, but it it depends.

There is a trade-off.

And it's there's no math equation you can use here to figure out what the right thing is, right?

That's unfortunate, it's just what feels right.

I've seen I've seen you talking about it on Twitter or a couple of blog posts, but I haven't had the chance to dig in.

You said something up that hyperscript is um something like async transparent, or that might not have been the exact phrase.

Yeah.

What's going on there?

Um so uh hyperscript it it's like I said, it's a little bit of a meme language.

Um I I whether or not it's used very much in reality is a I mean obviously I want people to use it, but uh but it's definitely very speculative.

But one of the interesting aspects of it is is as you said, it's it's what's called async transparent.

And what that means is that um in hyperscript, if you uh if you do an asynchronous operation, for example, there's a you can say wait three seconds.

You can just that's valid hyperscript.

So on click, do something, and then wait three seconds, and then do something else, uh, add or remove dot class from whatever.

Um and uh you can write that in hyperscript linearly.

So you just write, you know, do action one, wait three seconds, do action two.

And hyperscript runtime will wrap all of that.

Well, the the execution environment wraps all that up and makes it such that you don't need to deal with callbacks.

In JavaScript, to do that, you would use a set timeout and a callback, right?

Um and uh if you were getting really fancy and using fetch or something like that, you might use uh await and you know an async tag on your on your function and then await a fetch, right?

And in hyperscript, you don't need to do any of that.

The hyperscript runtime is responsible for if any expression within the runtime produces a uh a promise, um, which is the JavaScript API for asynchronous behavior like the low-level API for it, um, it will basically await that promise resolving before it continues.

And that happens at the expression level, so that you can write hyperscript basically without worrying about asynchronous.

And so it really uh takes away all that, not all of it, you can't take away all of it, but it in normal day-to-day programming, it would take away the vast majority of explicit asynchronous code.

And that came out of this idea that I when I'm what you know with hyperscript, I'm trying to to um I'm trying to improve the scripting infrastructure of the web.

And your normal front-end script, like script writer, shouldn't have to worry about asynchronous stuff.

That's way, that's like that's just too low level.

You just want to issue a request and then take the results and put it into something or whatever it is, whatever it is that you want to do.

Um, and so uh that's that's what uh that's what asynchronous transparency is.

The removing the need to worry about whether or not a particular operation is synchronous or asynchronous.

You can just write code in the normal linear way, and then the hyperscript runtime works it all out.

And I would say technically that's the most interesting aspect of the language as far as you know programming languages go.

I think that's that's fairly unique.

Um, the runtime is not fast.

I would not write a Bitcoin miner in it, but uh but it does make front-end scripting quite nice if you have to deal with any asynchronous operations.

And there's more than you might think.

Uh, for example, animations like CSS transitions, those are asynchronous, right?

Like if you add a class to something or you you set a particular property on a uh uh like a length property or an opacity property, the transition that occurs is is asynchronous.

You actually have to listen for events in order to do that right if you want to wait until it completes to go and do something.

And so uh Hyperscript has a bunch of infrastructure to make all that work.

And it does allow for some interesting, there's some really interesting aspects to it.

Uh for example, the loop construct in Hyperscript can wait for an event.

And so you can have a for loop, effectively it's a repeat, but you can have a for loop that waits until an event occurs for the loop to terminate.

And there's a good example on the website where uh there's a button, you you click one button and it makes another button start throbbing, and then you click the button again, and the button will stop throbbing.

But rather than immediately like stopping the throb, it'll actually complete the loop and then stop.

And so you get a nice smooth animation completion because the loop isn't you're not can't you're not removing a class or canceling something, right?

You're actually saying you're just sending an event to this other button, and then the loop will complete its animation loop and then come back and check.

Oh, okay, I've received the event, so now I can finish.

So you can have a nice smooth finish to your animation.

Um, so pretty speculative stuff.

Uh, very uh very I don't know, I don't want to say advanced, but

I I highly recommend HGMX to most web developers.

Hyperscript you do have to be a little bit of a limitation at this point anyways.

That's clear

So I have one more question about the the the the general ecosystem the for my own work so I've been working with HTMX I've been working with Alpine I've been you know Tailwind I've been using a a lot more but looking at then these sort of the the borderland where it's like well should I do this in one should I do this in the other and then I'm thinking about interrupt interactivity and I don't have an answer there because I'm still exploring and I'm seeing where the APIs slot together and where they don't and you know what's your feeling on the interop in these kind of sprinkles approach libraries?

So I think HTMX and Alpine pair really well together and you know I would recommend people use HTMX for driving server interactions and then Alpine when you need a little bit more client side interactivity.

Both of those libraries are nice in that they can be incremental so you can start with a basic web app that just is the normal you know Django 1.0 version of the web app and then add um add these behaviors as you know where they add the most value.

One important concept in software development is a complexity budget.

Where do you want to spend your complexity budget in on your app and like the settings page probably shouldn't have any of your complexity budget in it.

And if you use React or something like that you're going to be surprised how much of your complexity budget ends up being dumped into these you know relatively simple web pages.

And so I think that's that's if you're if sort of coming at from a pragmatic standpoint, particularly if you have a technology like Django that's already there and works and has standard patterns I would try and think about it very incrementally.

And there's going to be spots where you need more front end and for those alpine or you know if you're crazy maybe try give hyperscript a try.

Or jQuery's you know defined library for that stuff.

And then the more you you move towards sort of uh server interactions then I think HDMI

Joking aside on that point like I could I could down I mean hyperscript isn't big right so I could add it for one little page and I could use it for one little bit and I could try that out and that wouldn't be that wouldn't commit me in any great way.

some important page in your web app that adds a huge amount of value for your end users and all you've done is included a 10k library and put in you know three or four uh attributes in your HTML so you're not having to rewrite the world in order to get what you want to have happen happen.

I guess one one thing I did I wanted to add is on the you know Google, Facebook and their cultures thing I've I've I've seen a bunch of interviews with the people who created these projects within those companies and I'm certainly guilty of saying well you know it's Google and Facebook they can do anything but most of those creators certainly of React would say they built it to solve a Facebook specific need and they had to fight every step of the way to open source it that Facebook itself was always kind of against it

so that it's almost a little minor miracle that it even comes out and then they get the added I don't know I don't feel sorry for them but everyone's like hey you're the XYZ company why doesn't it do all these things when they're saying you know it's a miracle we even put this out there so it's sort of a cost of doing it within those companies though of course as you said when it comes from those companies it's gonna get all this momentum and and push but it's it's not as if Mark Zuckerberg is saying we need to promote React I don't think.

ed system where the networking infrastructure behaved in a new way it didn't behave the way old thick clients did it was a new architecture where hypertext was being exchanged.

And when that proved not to the UX issues around that became obvious people started doing Ajax and Ajax started off as XML and they took the language from that original model from Lori Fielding's thesis of REST and Hadios and they tried to to to use it in the API world.

And now when people hear REST and Hadios they think they think APIs and it it it it really doesn't apply very well in that world in my opinion because especially once you get a JSON you're no longer you don't have a hypertext and so all of the infrastructure all of the network infrastructure that made a lot of sense when we were describing this hypertext system that the web was the original web was it just it kind of bled into this it just stopped making sense particularly in JSON

it's it's almost in my in my mind kind of cargo culty.

But unfortunately none of the the big software uh companies out there that could could explain this uh do so and it's not in their interest and it's not you know it's this is a little nerdy and I was always annoyed by the guys that were like well your API isn't it isn't restful you know so I get it like how many times in the like early 2000s do were we on messaging boards being you know oh this isn't the third level of whatever

ic it's like already we start day is it

ad so hopefully you know these things do appear to go in cycles and so hopefully we can uh bring people back to this original model for the web.

I think the examples you know you pointed out the examples and I think that's probably the best move I've made was creating that examples page I need to do that for hyperscript as well that just shows here's what you can accomplish with a little bit of uh a little bit of hypertext uh with a little bit of an with an extension to hypertext and uh that it speaks to people a lot more than me sitting around you know explaining why they're wrong about the web I do like doing that sometimes I

really like to give that talk at Google.

Yeah yeah that'd be fun.

Because you've really struck you've really struck a chord in the Django community.

I think even JavaScript has kind of been eclipsed by Python at this point.

Um, and so uh yeah, um, but uh so it's it's I I wouldn't have expected this, and that's kind of the way life goes.

I wouldn't have expected to rewrite it intercore JS either, but then they they shut the apps.

Kept me same for that first couple weeks when it yeah, that was pretty crazy.

As we said, it is it is I'm hearing a lot about HTMX in the Django world, so hopefully this podcast opens it up to even more people.

There's something fancy going on.

Um I try not to be too I I'm a pretty informal person, so I say some pretty silly stuff.

Um but uh the Discord as well, which is you can get on at HTMX.org slash Discord.

Um if you need help, don't struggle.

Um Stack Overflow is still pretty raw as far as HTMX questions go.

Hopefully it's you know a lot of it is simple enough that you don't need a ton of help.

But if you do need help, the community on the Discord uh channel is pretty is very solid.

There's some people that know the line know the infrastructure, know the the library, I should say, very well, and are uh we try and keep it very friendly.

Um so I imagine there'll be more HTMX on there as well.

I need to hold on, let me write this down.

What's it called?

Yeah, you can it's it's what is it?

It's it's not Discord, it's

Um but yeah, you've you create an account and you can I think you can follow stuff and um you can see if you've you know if things that you've commented on have action.

I mean, for example, so I w one of the posts I have is talking about where to put the logic in Django, and that's two years old, and that's had a lot of discussions because it's you know sort of the equivalent of where is the state.

But I but I you know I I opt into seeing when people comment on that.

Was there anything else?

Is there anything else you wanted to shout out while you've got the um of if we covered all the bases?

No, I think you know, again, just uh I'm really thankful that people are picking this up and willing to take a look at an older, you know, way of doing web development, sort of I would say the original way.

Um, and uh the you know, I want to encourage people to just maybe have a little bit of courage and uh and going against the grain because I do think that uh for a lot of web apps uh there's a lot of great technologies that are just laying around waiting for web developers to pick up and use that would simplify things dramatically and uh make both their lives as well as the lives of their users a lot better.

So um, you know, I'm extremely thankful to you guys for this is all JavaScript stuff.

So thank you for talking to me about it.

And I'm uh I'm very happy that it's proving useful and kind of giving Django some new legs, you know, as far as uh being at a Quran.

So thank you.

As ever, we're at DjangoChat.com, chat Django on Twitter, and we'll see everyone next time.

Bye bye.

Cheers.