Transcript: htmx - Carson Gross (Ep95 Replay)

Hi, welcome to another episode of Django Chat, a fortnightly podcast on the Django Web Framework.

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

Hello, Will.

Hi, Carlton.

Hello, Will.

And this week, we're very pleased to have on us Carson Gross, who is author of the very,

very, very super exciting HTMX library.

Hello, Carson.

Thanks for coming on the show.

Yeah, thank you.

Very excited to be here.

very excited to see uh the Django community taking a taking a look at htmx yeah no I mean it's it's

been a a real revelation so um for the for the audience let's let's go back a bit and can you

give us all 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 sure um so I actually I've I have to admit I've never done

any serious python development at least not in anger um but I've been programming for a very

long time. I programmed in Java just forever. And I started doing web application development back

in the late 90s, and just right when things were starting to get going. And I always kind of

was in the Java world until probably around 2005. And then I started picking up Rails

and started doing a lot of Rails development.

And I still work on Rails in a basic startup that I work for.

It's not a startup anymore, but a software company that I founded

with a couple of other people that's based on Rails.

And so the original library that turned into HTML is called Intercooler Gas,

and I built it sort of in the Rails with a Rails backend,

against a Rails backend.

I've heard you say that you built Intercooler because you hate JavaScript, but now you're

an expert in JavaScript because you're bearing the burden for the rest of us.

Does that still hold?

Yeah, there's the irony of me not wanting to write any JavaScript is that I've had to

write an awful lot of JavaScript to do so.

And I still, I write in a very idiosyncratic way.

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

And I don't use the newer stuff.

HCMX is IE11 compatible.

My understanding is that IE11 is being formally destroyed here in a few months.

But I've always coded.

I found a way that I like where I can write JavaScript without creating too many bugs.

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

So when normal, you know, quote-unquote normal JavaScript developers come and look at my code base,

they are often very confused.

I have found that other people coming from outside the JavaScript community find it fairly approachable,

but it's definitely not the standard way to write JavaScript.

Can I ask you about intercooler then?

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

so let's talk about briefly what htmx is and then we'll cut back to the history yeah so htmx um a

good way to think of it i had you know a good way to start in on it is uh you know when you've got

a normal web app with anchors and forms right we're just writing a normal vanilla web app um

the the problem that you run into from an interactive standpoint is that every time you

click on a link or submit a form you're going to do a full page reflection so you get that clunky

you know full screen 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 do do more stuff as a hypertext

And so, replacing parts of the screen is one, maybe responding to other events, not just

click and submit is another way to improve the way HTML works.

Maybe you don't want only anchor tags and forms to submit to make server requests, right?

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

And then, you know, I also, the last kind of component in there is making all of the HTTP actions available.

So it's not just getting posts.

Most web apps, unfortunately, are hamstrung by the defaults in HTML where it's really, it's only easy to 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 surfacing them in HTML

is sort of what HTMX does.

Yeah, okay.

And just as an example, a form I was working on last week,

he just took on the, it was just a select box

that took on the change event.

And when you triggered the change,

it would go and fetch some related data

and put that straight into the page.

You know, it was a couple of data attributes

and a Django view on the back end just waiting there.

and that was it, and it was as nice as anything, really.

It was one example.

Yeah, exactly.

So you can have an app that has the nice features we've come to like

from the more extensive front-end frameworks like React,

but hopefully without all that heavy weight,

without all the coding infrastructure that's necessary for that.

Yeah, but literally I didn't write any JavaScript.

It was just a few HTML attributes, so that was cool.

So let's swing back to, so with HTMX in play, so it's this cool library,

and you talked about building it, working with Rails.

But Rails has, well, for my history, it was Pjax and then Turbolinks

and then the Hotwire stuff.

And so I found HTMX in the few weeks after the Hotwire announcement

where they had the nice website and there was a lot of hype

and someone mentioned, Adam Johnson mentioned HTMX.

I was like, oh, what's this? Check that out as well.

it's in the same space so how did you what how come you came to write intercooler rather than

going along with the yeah just using turbo lengths would have been a little bit easier for sure

in particular pjx i mean i used pjx back when that was the the big option um and uh turbo

lengths 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

thing it just needed more it needed more of a formalization um the turbo links and hotwire

both kind of have a magic they reflect i think both libraries reflect the personalities of the

the people who are developing that and so dhh really likes magic like he wants things 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 interplay 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 um and you you understand what's

going on it's not just automatic yeah okay and so it gives you more control and again i think it's

that it's just a philosophical difference i was trying to think more let's go with the grain of

html and take it further rather than let's just make it all work magically that's kind of a good

answer for a django podcast because quite often people say well what's the difference between

django and rails and one answer to that question is that django you kind of do it it's not quite

so auto magic you know rails gives you the full controllers and the ajx 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 you know there's a bit more flexibility perhaps or you know yeah who know you know you

can i think also you you uh you understand the tool a little bit deeper you have to be careful

with uh too much magic because you can you can have sort of a a helpless feeling when it doesn't

do what you want it to do right yeah it's great until it doesn't work right and so you know there's

that that first week can feel real it can feel wonderful but then later on when you need a little

bit more flexibility or you're trying to understand why something isn't working exactly the way that

you want being a little bit more explicit i think is often is is pretty useful especially with

editors being as good as they are these days um it's i've kind of moved away from you know trying

to minimize everything and 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 a live live wire as well that's another example and in both of those

cases hot wires the same way in that it requires web sockets there's a server side component to

using it that is necessary and htmx does not have that explicitly i've been trying to focus

just it's purely extending html it's hypertext and therefore um it's not it doesn't make any

specific requirements on your backend so it can be used with anything and django is a great example

of something that can be used with okay so then i have one more sort of question from the history

and the backstory side of it is why um when there was intercorder is there now htmx what's the story

there between the change in the libraries um so uh last summer i had hd uh intercooler excuse me i

did i think i created it back in 2013 so it's been around for quite quite some time 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, all the jQuery infrastructure, and last summer, you may recall that the world

kind of shut down, and so I was sitting around and thinking, all right, what do I want to

do with myself to keep from going insane, and it always bothered me that HTMX, it didn't

at the start, but it increasingly bothered me that 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 JavaScript. And along those same lines, one of the things that

always bothered me when I tried to tell people about Intercore.js, and I have to say I've gotten

quite a lot of grief

on the internet when I tried to talk

to people about this style of development

particularly in the JavaScript communities

which is, it's understandable

but

the library

was being compared with

React.js or whatever

the big JavaScript library

of the time was, initially it was

what was Google's? Angular

Angular, yes

thank you, so it was compared with

angular it was whatever and um and i 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 got to take that that's crazy it's still

later for 2020 and so that and you know that obviously I did a lot of documentation rewrites

and so forth and really tried to clean the library up as well I'm much happier with it

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 but I think htmx is a much cleaner is a much cleaner

implementation of the concept okay can I on the history I'm curious so 20 because 2013 when you

first started on intercooler i remember i think it was around was it 2012 when react 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 uh my my company the company that i run is called big sky software and our tagline is that

We find hot new industry trends and then do the opposite of that.

So I've always been a little bit of a contrarian by nature.

And that's good in some ways and bad in others.

But, you know, I just it really came out of the original concept came out of a situation where I was writing some pretty hairy jQuery code to update a table dynamically.

And 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 it came out of 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 like i can't i can't figure that out i'm just gonna do it this way yeah this you know

all great truth start off as blasphemy so you know who's to say i mean but is is it blasphemy

i have to whisper like because there was this thing that 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

well, this is quite good, and I wasn't allowed to use that for a long time.

Why not?

I know. Why not?

Yeah, we're bringing it back.

Maybe we'll talk about HyperScript, too, if you want to get really, really obscure.

Well, let's save that for a minute, because I wanted to ask just a more sort of kind of abstract question,

because everyone's been telling me that the modern web has to be done with, you know,

javascript on you know server sends out the thing it gets rehydrated back on the client and

all of these things but the performance of that and the the bandwidth required for that seems to

be quite high and then all and but for a number of years i felt as if i'm 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 htmx comes along and and you know the the related um libraries that are in

the similar kind of domain and it's like no but we can just render the the html on the the server and

inject it in the dom and that work i mean what just at that kind of theoretical level what do

you think's going on and you think well i think i you know i think there's a sociological aspect

to it too that you just have to be cognizant of which is that you put first of all the industry

is prone to trends there's no doubt about that um and some you know we've been down some bad paths

uh google you know everyone trusts google everyone trusts facebook google had quit um angular i think

angular 1.0 anyways 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 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. So, you know, but when you look at, if you're able to take a step back and look at things

from a little longer perspective, and I don't blame people who can't, you know, someone who's

only experienced with web development is React and like that entire infrastructure, you can't

They don't have that longer-term perspective

on the way things are.

And the original web architecture,

I don't feel like it was communicated well.

REST and Hadeos kind of got tied up in the API community.

Yes, it did.

And the web development community kind of lost touch

with what the web architecture was.

The web was just kind of this VM slash,

janky ui markup 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 again i don't blame people uh for i i do blame a little bit the

Facebook and Google people, I'm sorry to say, just because I feel like they, if anyone had

the ability to communicate the original web architecture well to the broader development

community, it was those companies. And I don't see a lot of that. But, you know, Fielding's,

Fielding's, I've got it right here somewhere, his thesis, you know, his PhD thesis that outlined

to love architecture it's pretty impenetrable it's not easy reading so yeah and even the o'reilly

books that are meant to be a gloss on that they're quite impenetrable yeah so you know i feel i i

often early on i would like go into rest and hideous in these talks very early and i could

just see the eyes glazing out 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 so on that i wanted

to ask about so when i was learning the web i remember being like why do i need all this

javascript and it sounds like i've again 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 i think it makes me wonder at times you know there's that uh in zoolander

there's that that line where he says am i the only one who notices this am i taking crazy pills

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 the same and um so there is something there i i

tried to open an issue on the discussion forums for html for like the w3 i don't know what it was

someone sent me a link these people do browser stuff and so i tried to open up a discussion there

about extending html as a hypertext but it didn't go particularly really 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 the way you get it in is like with the image tag 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 yeah yeah i know i i think i'm not gonna i doubt

i'm gonna work on chrome anytime soon and i'm fine 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 yeah i mean i did

i mean integral is old it was 2013 so it's been around a while but it's you know it can be hard

to sell i'm just one guy we've got a small but you know good little community around hdmi and

intercore um but you know there's just there's a lot of momentum and javascript say what we will

about it you can do everything you need to with it and so um you know i don't know you just if

you're not if you're not convinced if if the hypertext uh architecture doesn't speak to you

then you know i can see why you might be more inclined to look at a javascript solution for

things okay well just from a django point of view like for you know a decade or more we've been

building um apis with django rest framework and you know the clients have been coming and hitting

that and 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 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 yeah 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 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 and you can cache it pretty easily too yeah yeah yeah that's one really great thing

about htmx 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 like in terms of size or size it barely notices it and it can often feel

faster because you just you don't have a lot of javascript living between the html and the actual

dom itself so you know it's 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 brought up caching, and

that's a good example. A well-cached web app can be very, very fast, and that can be hard

to do if you're fronting an arbitrary query API in JSON, right? Caching that can be very

difficult um and 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 to make that much much

faster and that does bring up something that i think is worth mentioning about when you mentioned

building json apis in django um the your your web apps tend to be kind of needly like they tend to

very specific needs like you have to tune a query to make a particular 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

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 reason why we have technologies what's the i always i

always want to say jquery but what's the facebook graphql standard graphql thank you i always want

to say jquery but we can call it that we can call it that the reason why graphql is becoming so

popular is because if you uh if you try to build an api without a powerful expressive query language

like that in json your front-end developers are going to ask for like a thousand different end

points for all their little needs in the app and so um one of the really nice things about using

something like htmx is that those needs get moved back to the back end where they have sql and they

can do whatever damn fool thing they want to do against the database, right? And then, you know,

maybe you need to tune the database with indexes and all that sort of stuff. But that's an

achievable engineering goal versus this more generalized JSON front-end API. So I think those

are two separate use cases. They have two different technical requirements. And you would see this

about you know before before jQuery slash GraphQL came out you would have API developers that were

they were just they were in despair because they were constantly you know you'd be on version 35

of your API before you even shipped 1.0 of your web app because there's so much churn and just

small little changes to make your UI work properly. This is awesome actually because we you know

worked on teams where i've been on the back end of that conversation and it's like you know twice

weekly meetings on you know we need this end point it's gotta have these fields and it just

the the feedback cycle there is just so painful and slow and difficult that you you just like

you come in here with us and you write the end point and you know then there won't be the problem

right and yeah it's like we've talked about from episode one of the podcast we've talked about is

jango a back-end or front-end um thing 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

on the browser is that you can write the view serve the templates and you're the front-end

you're creating it yep exactly and that's the that's that's the architecture of the web too

oh that yeah 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 json isn't a hypertext guys so but then it's easy enough to add

oh we actually we do want a json representation of this data for some other use case well fine

you can add that but if it doesn't have to be your sort of core starting point it just

smooths the development process so much yeah exactly and so 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

but that's not the web that's that's probably not for most applications anyway it's not what

your web app should be talking to okay so can i ask about some of the limitations because i mean

we're both fanboys um now 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 yeah uh so maybe we could start with

that like how where is that ad 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 oh can it do it it's just like right there but you can't do

everything right um yeah that's i mean it's a problem i'm just 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

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 intercooler to an extent since it's been around

for so long. It's got 4,000 some odd stars on GitHub. So 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 still maturing a little bit. But I would say if you're 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

get anything too crazy you're going to probably get the help that you need but i don't want to

present it as if there's no risk it's not you're not going to be able to hire an htmx consulting

firm to come in and and help you but you know i'll help you if you jump on htmx general yeah

well not yet well there is so there's yeah i'm sorry to interrupt i was just going to say um

So Adam Johnson, again, has this Django HTMX 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?

You know, that's a good question. I would need to think more about that.

I think just, just, just advocate, just advocating, maybe trying to, I just had so little success trying to explain the original, 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 reddit 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

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 and have more engineers i'd probably just write more tests

can i ask what you use for testing i haven't dug in and seen but i'm always trying to choose a

javascript test framework and i never know which one to go for is it just

okay fine but i just picked whatever the pot mode 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 yeah because it's what is

the cypress now i think is the i think is the hotness um is that the new cool one uh so but

and i i i used to use a different one that was more browser friendly yeah i mean one of the

problems i have in writing a lot of javascript is that i try and make everything very browser

centric and uh the javascript world has moved away from that more towards like this mixed mode or

node oriented world and so 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 one had apparently died okay can i ask

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

Or where is that cutoff?

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

Absolutely.

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

There's no reason for it to be, right?

I don't know, Google Maps.

I don't know what a good example is of something.

Google Maps.

So there you go.

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 going to be done well.

And so flight simulator with the, they got the whole world digitized.

Yeah.

But Google maps is a good example, um, uh, of something that wouldn't be done on, on

the other hand the settings page in google maps uh would be probably something that could be done

very well yeah isn't that crazy you always have to like click the save button at the bottom and

i forget that every single time i flip the switch and for keyboard shortcuts and then it's like oh

i didn't it's so ridiculous yeah you didn't yeah 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 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 HTMLX. You don't get much by adding HTMLX to it. And

so just leave it that way. That simplicity is its own reward. 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're really into something and then it

can be too simple for other stuff like you're not gonna obviously um in the main right a video chat

system.

Well, but you can do WebSocket stuff, right?

Sorry if I interrupted you, Carlton.

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. Yeah, there's WebSockets

and also ServerSenseEvents

support and HTMX.

I do have to admit those are both

much more raw than the AJAX

support.

I would say more

speculative, but they're there.

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

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

I think it's interesting with both.

I mean, server-centered events is when you just need to receive a stream of, you know, asynchronous events from the server.

You don't need to send any data back.

So they're perfect.

You can open 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.

You don't even need to leave that connection open and pull,

whereas you can just make an AJAX request and you get it back.

And then WebSockets, that one where you're sending two-directional traffic,

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

Yeah, yeah, yeah, I know.

I feel like you can do quite a bit.

I've done quite a bit with just good old AJAX and maybe some pulling.

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

And you can accomplish quite a bit.

You'd be surprised.

Okay, so you...

I was just going to ask about HyperScript, Carlton,

because I know you...

So you ask the question because I'm...

Well, because this leads into HyperScript.

So it's a...

It's a more elegant way to do it.

Okay, you go ahead.

So, Carlton, I've been using...

So you talked about state, client-side state

and maintaining state.

And for rich things, I've been using Elm for a while.

But much closer 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 described it.

And I was like, okay, I'll give Alpine a go.

And it's the same sort of thing.

You just define a few attributes, and, you know,

it creates a component, and you can save, like, an object there.

And that object can have methods, and it's just really quite small.

And they say it's like Vue, but I wouldn't know,

having not really looked at Vue.

And that's great for, you know, when I want to maintain that better state.

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

It's called 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?

You're right to be terrified.

That is the appropriate response.

So what is HyperTalk?

well so we talked about how htmx came out of intercooler and it was sort of a cleanup

of intercooler a lot of stuff that i learned and 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 htmx was

something called the attribute was ic action so ic dash action and that was a little way to do

some client-side scripting mainly uh in uh in with jQuery stuff um but 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 300

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 a programming language person i worked on a programming language called

gosu for a long time which is a jv it's an obscured jvm programming language and i just

looked at that and said you know what if i'm going to do that i need to do it right this is too

janky because you know alpine js exists and so if you just want to put a little bit of

JavaScript in the DOM, which

reminds me there's a concept I want to talk about around that.

You know, you can use something like Alpine.

So, 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. Yeah, exactly.

And 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 hyper talk and hyper

talk was a scripting language that was a part of the hyper card development environment on the mac

a long long this is mist right this is what mist used yeah mist was written in hyper talk

and it's a one of the really unique things about hyper talk is that it had event handlers baked

into the language you didn't call you know something dot add event handler you just said

on click do this stuff and I thought to myself well that sounds like exactly what I need

and hyper talk some people most people haven't heard of it but some people have experience with

AppleTalk. And that experience is not good in general. And I appreciate that. But both AppleTalk

and HyperScript are based on HyperTalk. And 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 still pretty ugly compared to a lot of the jQuery stuff.

And so that's what it boils down to. There's some interesting characteristics about the language

that I'm sure we'll talk about, 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 because my sort of gloss on jquery was always select a thing do a change it you know

select something and then you know add a class or animate it or remove it from the dom or yeah

yeah exactly so and i think hyperscript is intended as a 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 can i can i just add

so currently you're you're a college professor teaching compilers classes right just in terms

of i mean yeah that's not like you're coming in so 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 anyways i just i saw that and 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 write a new language to solve all my problems, but I'm nowhere near

there. Yeah. Yeah. It's actually, believe it or not, creating a programming language is easier

than it sounds. If you learn recursive descent parsing, recursive descent parsing isn't taught

in academia. I teach it because I don't like the way 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 into tokens is that it can actually be like the tokenizer and 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 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 that's one of the things that

terrifies me because i spent a long time with apple script like trying to automate my mac to

do something or other with its supposedly english syntax and i'm just like yeah yeah no i know and

And HyperScript, again, for me, that's my fun project.

I don't expect it to be too widely adopted, 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 that you embed it directly in your HTML.

And so, as with Alpine and as with Tailwind CSS, you put everything into the HTML.

It's HTML-centric in that sense.

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

a handler you know kind of dynamically and so i'm trying to popularize this terminology of

locality of behavior for this mode, where 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 you 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 tailwinds is the most successful but also alpine htmx and maybe at some point

i think the the thing that comes up with there on in django is we have these things called class

based views where you know your view is um like the thing that turns an html request into an html

response it's the the fundamental handler of the framework 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 classes classes and too many

mix-ins and if you there's this whole website devoted to making the class hierarchy browsable

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 it's just so important or

so empowering yeah they're richard richard gabriel uh who's a famous lisp developer

yeah um he wrote the worst 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.

That's about why Unix beat Lisp.

So he's 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 read-off quote in my essay on the htmx.org website about locality of behavior.

And I think that captures that idea very well.

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 how something works, the harder to maintain that code you're going to find it.

Do you see a potential? Is there a potential downside to putting so much just in HTML, both with HTML and these other projects?

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.

you still you still need to factor things properly um but um but fact to me 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

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 want to there's going to 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.

Hopefully the method isn't named do it

or something like that, right?

So there's a danger.

Yeah, do it too.

Do it again.

So, you know,

but that's, in my mind,

that's just proper software engineering.

And I think that we've fallen into

this idea of separation of concerns

a little too, 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 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 can't 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 it really grows on you so yeah my first couple of hours would tell you

just like i can't do this 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 yeah so you know i think that

you still have to you still need to be a software engineer but i think you can let go a little bit

of separation of concerns for its own sake and maybe let go of don't repeat yourself for its

own sake maybe it's okay to repeat some stuff a little bit if that makes it clearer what's

yeah no i mean definitely there's some there's times where you you know you might have three

lines in a view that strictly it's boilerplate but it's much better there because it's it's

visible forever than it is abstracted some hook on some super class you know right yeah and that's

actually even just with the generic class-based views in django um someone brought to my attention

they're asking a question they're like where is the success url on was update and delete 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 it's

attention so i would say in that case maybe you know so yeah it it depends and so we always try

we always try to avoid that saying that in our podcast but it depends there is a trade-off

there's a trade-off and it's no 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 well i wanted i wanted to ask you

about um one more thing about hyperscript 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 that hyperscript is

something like async transparent or that may not have been the exact phrase yeah what's going on

there yeah that's thank you thank you for bringing that up um so hyper script 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 it 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 what's called async transparent and what that

What that means is that in HyperScript,

if you do an asynchronous operation,

For example, you can say, wait three seconds.

That's valid HyperScript.

So on click, do something, and then wait three seconds,

and then do something else.

Add or remove that class from whatever.

And you can write that in HyperScript linearly.

So you just write, do action one, wait three seconds,

do action two.

And the HyperScript runtime will wrap all of that,

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 setTimeout and a callback, right?

And if you were getting really fancy and using fetch or something like that,

you might use await and, you know, an async tag 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 promise,

which is the JavaScript API for asynchronous behavior, like the low-level API for it,

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 you don't have to await this yeah you can just put a fetch

yeah you can put a fetch right in the middle of the function and just keep writing the function

the normal linear way um and without having to do an await or you know make the function

asynchronous so on and so forth and so it really uh takes away all that not all of it you can't

take away all of it but 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

And so that's what asynchronic transparency is,

that 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 program languages go.

I think that's fairly unique.

The runtime is not fast.

I would not write a Bitcoin miner in it, 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.

For example, animations like CSS transitions, those are asynchronous, right?

Like if you add a class to something or you set a particular property on a length property

or an opacity property, the transition that occurs 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, 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.

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

And so, you can have a for loop, effectively, it's 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 there's a button.

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 stopping the throb, it will actually complete the loop and then stop.

And so you get a nice, smooth animation completion because the loop isn'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 pretty cool if you've had

them if you experience these issues at all or that's super cool yeah it's it's it's it's an

interesting technology again much more speculative than htmx i highly recommend htmx to most web

developers hyperscript you do have to be a little bit at this point anyways i was going to ask you

know how on the scale of one to ten how advisable is it like that you're lunatic right so that's

fine that's that's clear that's clear you know it works it works so i have one more question about

the the general ecosystem 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 lot more but looking at then the sort of the

the borderland where it's like oh 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 yeah um well i i think you know htmx

and alpine are a solid a solid combination um because alpine gives you sort of 90 of what view

80 to 90 of what view gives you plus the jquery aspect of you know you get that locality of

behavior that you want the jquery doesn't really give you but you can do your front end scripting

in a sane world so i think htmx and alpine pair really well together um and uh 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 and 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 like one one important concept in software development is a complexity budget you know where

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 um and uh so uh i think that's that's if you're sort of coming

at it 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 fronted um and for those alpine or you know if

crazy maybe try give hyperscript to try um or jquers you know to find library for that stuff

um and then the more you you move towards sort of uh server interactions then i think

joking aside on that point like i could i could i mean hyperscript script 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 yeah yeah exactly it's not

And again, I think one of the strengths of Alpine and HTMX and Hyperscript to an extent is that they're incremental.

They don't require you to buy into a huge ecosystem to get the first thing done.

You know, with HTMX, in any event, you can add three attributes to your web app and have an active search filter on some important page in your web app that has 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 attributes and you reach them out.

So you're not having to rewrite the world in order to get what you want to have happen.

That's very cool.

I guess one thing I did, I wanted to add is on the, you know, Google, Facebook and

their cultures thing. 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 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 um 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 going to 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 yeah yeah that's true and there's so much randomness in the

world you know like it's just it makes sense and then in one spot and then someone picks it up and

you know one thing you can look back on historically is picking up and maybe this will

let me nerd out a little bit, but the idea of REST and HADEOs in the API community, right?

Because we started, REST and HADEOs was a description of the web. It was a description

of this hypertext-based system where the networking infrastructure behaved in a new way. It didn't

behave the way old FIT 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

Roy Fielding's thesis of REST and HADIS, and they tried to use it in the API world. And now when

people hear REST and HADIS, they think APIs. And 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 i mean 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 were we on messaging boards being you know oh this isn't the third level of whatever

we have we have that in python with pythonic it's not pythonic it's like oh really it's that day is

it yeah yeah exactly exactly um but you know it just it's it's funny how this stuff works out so

um you know people hate adios without even understanding really what it is um at this

point and you know if you're using a json api yeah of course you hate it because it's not hypertext

so hypertext can't be the engine of application state or it's going to be real hard to make it

the engine of application state if you're going down that road.

So hopefully, you know, these things do appear to go in cycles,

and so hopefully we can 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 a little bit of hypertext

with a little bit of an with an extension to hypertext and that 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 well you should come to a django con

and give it there that would be funny yeah that'd be fun speaking of which i mean you've um there

are a few people giving talks at the um jango con that's just coming up on htmx and so we'll put

that that will those talks will be before this show comes out so we'll put the links for those

in the show notes as well um because you've really struck you've really struck a chord in the

community yeah and i'm very excited to you know it's just like i never would have expected it

like i said i've probably written 100 lines of python in my life um if i do start another

project i'm going to take a hard look at django though just because the community is obviously

you know python has just grown leaps and bounds 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 wouldn't have expected this and

that's kind of the way life goes i wouldn't have expected to rewrite it intercooler js either but

then they they shut the yeah it's well it's it's good that you managed to make use of the

confinement time yeah yeah kept me sane for that first couple weeks when it yeah that was pretty

crazy so thank you so much for taking the time and agreeing to come on our our django podcast to uh

to talk about this as we said it is i'm hearing a lot about htmx in the django world so hopefully

this podcast opens it up to to even more people yeah and i want to encourage people to uh you know

there's an htmx account on twitter um which it's just me something fancy going on um i try not to

be too 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 discord um if you need help don't struggle um stack overflow

is still pretty raw as far as

htmlx questions go hopefully

it's you know a lot of it's simple enough

that you don't need a ton of help but if you do

need help the community on the discord

channel is pretty

very solid there's some people that

know the

library I should say very well

and we try to keep it very friendly

yeah there's also there's um jango has a

forum.jangoproject.com

official forum that is not

as used as it should be but

people that a discussion is completely top-notch um so i imagine there'll be more htmx on there as

well okay is there a way on that forum to listen for htmx questions i need to hold on let me write

this down what's it called forum.jangoproject.com yeah you can it's it's what is it it's it's not

discord it's it's um the discourse the other one is discourse the other one 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 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 yeah i'm trying to on all these platforms

set up alerts for when someone mentions htmx just so i can jump in and help if possible

too but was there anything else was there anything else you wanted to shout out while you've got the

um have we covered all the bases oh well i've got you here no i think you know again just i'm really

thankful that people are picking this up and willing to take a look at an older you know way

doing web development sort of I would say the original way and the you know I

want to encourage people to just maybe have a little bit of courage and and

going against the grain because I do think that for a lot of web apps 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 make

both their lives as well as the lives of their users a lot better so yeah 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 I'm very happy that it's proven useful and kind

of given Django some new legs you know as far as being really exciting times

thank you yeah thank you as ever we're at Django chat comm chat Django on

twitter and we'll see everyone next time bye-bye see you next time bye-bye cheers