Transcript: htmx - Carson Gross

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 htmx let's talk 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

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

And so one step into the mindset of HTMLX 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 the hypertext that

with that 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 there's another way to improve the way HTML

works maybe you don't want only anchor tags and forms to submit to make server

requests 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

restful types of actions that you want to use and so taking all those and making surfacing them in

html is sort of what uh what htmx does yeah okay and and just as an example a form i was working

on last week he just um 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 the 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 as as anything really it was yeah it's just one

example yeah exactly so you can have a 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 is necessary for that yeah but i mean literally i didn't write

any javascript it was just some a few html attributes so that was cool so let's swing

back to so with htmx in play so it's this this cool library and you talked about building it um

working with rails and but rails has um well for my history it was pjacks and then turbo links and

then the hotwired stuff and so i found htmx in the few weeks after the um hotwire announcement

where they had the nice website and there was a lot of hype and someone mentioned adam johnson

mentioned hdmx i was oh what's this check that out as well yeah 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 links 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 links 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 i think 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 um the people who are developing and so dhh really likes magic like he

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 interpoler 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 automating 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 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 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 it's great until it doesn't

work right and so you know there's a that that first week can feel real 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

as often is pretty useful, especially with editors being as good as they are these days.

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 Livewire as well.

That's another example. And in both of those cases, Hotwire is 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 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 in the backstory side of it is why um when there

was intercooler is there now htmx what's the story there between the change in the libraries

um so uh last summer i had ht 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 IntercoolerJS 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

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 IntercoreJS,

And I have to say, I've gotten quite a lot of grief on the Internet

when I try to talk to people about this style of development,

particularly in the JavaScript communities, which is 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 compared with whatever.

And 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 a better name,

and htmx.org was available.

And I was like, well, I mean, come on, you've got to take that.

That's crazy. It's still available in 2020.

Um, and so that, and that, you know, that obviously 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 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.

Um, 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 uh 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 um by nature and uh 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

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 uh 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 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

is 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 oh this is quite good and then i wasn't

allowed to use that for a long time but why not i know why not yeah we're bringing it back maybe

we'll talk about hyperscript too you want to 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 um kind of uh abstract question

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

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 is going on and you think well i think i you know i think there's a sociological

aspect to it too 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.

So there's a lot of bad ideas that come along.

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

We also, we're a forward-looking industry.

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

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.

And there's 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 it, 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 that entire infrastructure.

You can't really, they just, they don't have that longer term perspective on the way things are.

And the, you know, 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 directly 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 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

in zoolander there's that that line where he says am i the only one who notices this

am i taking crazy pills crazy pills and uh and when i the more javascript i saw the more i was

like man what about hypertext so you know I don't know what to say other than I'm glad that I was

able to to work on this and it seems like it's working out pretty well I think a lot of people

when they when they see it they're like oh yeah that that seems the same and 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 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 really um 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 you yeah you get it 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 intercooler's 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's and intercooler 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 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 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 and you can cache it pretty easily too

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

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, I think one of the great things about HTMX is that it brings 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 that can be hard to do if you're

fronting an arbitrary query API in JSON. Caching that can be very difficult. But if it's just

an endpoint with a get, you know you can cache that. And you can use whatever mature caching

technology you like 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. The

But your web apps tend to be kind of needly.

They tend to have very specific needs.

You have to tune a query to make a particular UI work quickly.

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

You have something very specific for a particular UI to make it work correctly.

And that's in tension with a more general JSON API.

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 you need to have a more generalized API.

And the reason why we have technologies,

what's the, I always want to say jQuery,

but what's the Facebook query?

GraphQL.

Standard, GraphQL, thank you.

I always want to say jQuery.

We can call it that.

We can call it that.

The reason why GraphQL is becoming so popular

is because 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 endpoints

for all their little needs in the app.

And so one of the really nice things

about using something like HGMX

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 jQuery slash 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

constantly you know you'd be on version 35 of your api before you even shipped one point over

the web app because there's so much churn and just small little changes to make your ui work

and 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 got to have these fields and it just the the the feedback cycle there is just so painful

and slow and difficult that you you just like ah 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 django a back end or a 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 the on the browser is that you yeah that's 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 that's which 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 um 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

so while yeah you know nobody ever got fired for using react and i you know i understand that

dynamic there's there's only so much that i can do as a small you know software shop and i think

intercooler to an extent since it's been around for so long it's got four thousand 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

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

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

that 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 hgmx 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 something super dynamic, do you feel like there's a possibility that HTMX could eventually do that?

Or where is that cut off?

Because there is still a cut off 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 clients I'd 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 yeah well but you can do websocket stuff right like that's uh sorry if i interrupted you

carlton like you can 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 yeah there's websockets and

also server science events um support and hcmx i i do have to admit those are both much more raw

than the ajax support um and so uh you know 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

way of using those technologies goes um but it's it's definitely a newer it's a it's 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 service center 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 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 pull whereas you can just make an ajx request and you get it back and then web

sockets that one where you're sending two directional traffic well quite often you don't

need that it turns out so yeah yeah yeah i know uh i feel like you can do i've done quite a bit

It would just get a little AJAX and maybe some polling.

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

And you can accomplish quite a bit.

You'd be surprised.

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.

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.

Um, 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, 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?

You're right to be terrified.

That is the appropriate, that is the appropriate response.

So, uh, what is hyper talk?

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 in with jQuery stuff but it had this kind of funny syntax and it

lets you do 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 programming language and 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 will remind me there's a concept i want to talk about

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 yeah exactly 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 HyperTalk.

And HyperTalk was a scripting language

that was a part of the HyperCard development environment

on the Mac, a long, long time ago.

This is Myst, right? This is what Myst used.

Yeah, Myst was written in HyperTalk.

And 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 I thought to myself, well, that sounds like exactly what I need.

And HyperTalk, 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, select something, and then add a class.

animate it or remove it from the doc more 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 do you know write a new language to solve all my problems but

i'm nowhere near there yeah yeah it's it's actually believe it or not um creating a

programming language is easier than it sounds 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

people teach parser generators instead which is a it's much better for producing papers

in academia but I think it's much worse as far as learning how programming languages actually work

and so 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. The parser is actually easier than the tokenizer in many

situations like breaking the string up 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 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 it can be a little jarring it's very easy to read but it 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 no i know and and hyper script again for me is like 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 like as with Alpine and as with Tailwind CSS, you put everything into the HTML.

It's HTML centric in that sense. And what that gives you is that when you're curious as to what

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 you've got a great post on that for that for this

mode, right, 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 obviously tailwinds is the most

successful but also alpine htmx and maybe at some point yeah 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 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 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 if i remember if i'm

remembering correctly yeah um he wrote the worst is better paper i don't know if you've ever read

that but that's pretty good cs paper to read yeah worse is better um 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 lead 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 um htmx and um 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 right you still

you still need to factor things properly um but um but fat to me you want to factor you want to

pick the right axis to factor on.

And so 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 comes a point, like, we have extract method for a reason, right?

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 um so uh there there's a danger yeah do it too

do it again uh so you know there uh but that's 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 um 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 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 it really grows on you so yeah my

first couple of hours with tailwinds just like i can't do this no i refuse no no and after a little

why 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 and 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 so we always try to

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

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 might 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 hyperscript it's like i said it's a

bit of a meme language. Whether or not it's used very much in reality isn't, I mean, obviously

I want people to use it, but it's definitely very speculative. But one of the interesting

aspects of it is, as you said, it's what's called async transparent. And what that means

is that in HyperScript, if you, if you do an asynchronous operation, for example, you

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 a wait and, you know, an async tag on your function

and then a wait, 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 hyper script basically without worrying about it.

You don't have to await this.

You can just put a fetch.

Yeah, you can put a fetch right in the middle of a function and just keep writing the function the normal linear way without having to do an await or make the function asynchronous, so on and so forth.

And so it really 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 with HyperScript, 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 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 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, you know, programming 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, 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, 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.

So pretty speculative stuff.

Very, very, I don't know, I don't want to say advanced.

Pretty cool if you've had them, if you've experienced these issues at all.

That's super cool.

Yeah, 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 of a web developer at this point anyways.

i was going to ask like 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

so i have one more question about the the general ecosystem for my own work so i've been working

with hcmx 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 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 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 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

and so 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 um i would try and think about it very incrementally um and there's going to be spots

where you need more front end um and for those alpine or uh you know if you're crazy maybe try

give hyperscript to try um or jquers you know the fine library for that stuff um and then the more

you you move towards sort of uh server interactions then the joking more sense as well 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 any uh again i think

one of the strengths of alpine um and uh hgx and hyperscript to an extent is that they're they're

they're incremental uh you you don't have 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 happen that's very cool 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 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 Hadeos, and they tried to use it in the API world.

And now when people hear REST and HADEOs, 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 kind of bled into this.

It just stopped making sense.

Particularly in JSON, it's almost, in my mind, kind of cargo cult-y.

But unfortunately, none of the big software companies out there that could explain this do so.

It's not in their interest.

This is a little nerdy.

And I was always annoyed by the guys that were like, well, your API isn't RESTful.

So I get it.

like how many times in the like early 2000s were we on message 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 we 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 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 uh if uh if you're going down that road

so hopefully you know the 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 um 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

speaking of which i mean you've um there are a few people giving talks at the um django 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 channel 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 is kind of an eclipse 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 gas 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 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 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's 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 infrastructure know the library i should say very

well and are uh we try and keep it very friendly yeah there's also there's um django has a forum

forum.jangoproject.com, official forum that is not as used as it should be, but

the discussion is completely top-notch. 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 it's discourse the other one um but yeah you've you created 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 uh alerts

for when someone mentions htmx just so i can jump in and help if possible too but thank you so much

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 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 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 make both their lives

as well as the lives of their users a lot better.

So, 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 very happy that it's proven useful

and kind of giving Django some new legs, you know,

as far as being a tier one web developer.

No, it's really exciting times.

So thank you.

Yeah, thank you.

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

Bye-bye.

See you next time.

Bye-bye.

Cheers.