Carson Gross
===

[00:00:00] Hello and welcome to Pod Rocket, a web development podcast brought to you by Log Rocket. Log Rocket helps software teams improve user experience with session replay, error tracking, and product analytics. You can try it free@logrocket.com. I'm Noel, and today we're joined by Carson Gross, creator of H T M X.

he's here to talk about what H T M X is, why developers are excited about it, why people are talking about it, and what's on the horizon. Welcome to the show, Carson. How's it gone?

it's going great. Thank you very much for having me on, Noel. I'm excited to be here. 

before we jump in, can you tell us a little bit about who you are, and how you got into web dev or are concerned with these technologies now?

I've been doing web development for a long time now. I started web development back when, it was c g i scripts and applets and very early on the late nineties. I just got, I was in the Bay Area. I went to school in the Bay Area and ended up getting a job in the Bay Area, doing kind of early web development.

and so I've been doing this just, it feels like [00:01:00] forever, went through the J two E, like early on web development was Java. it's split into sort of P H P or C C G I type stuff, which kind of turned into P H P once P H P took off. but I, I was on the more professional side, doing consulting work for startup companies.

and that was mainly in Java. And J two e, kind of Erit and J S P and that whole world. so I did that for a long time and actually took a break, from web development for three or four years. it's ironic that now I'm a, an evangelist for, hypermedia because, I didn't like it at first.

I, I ended up building, really a thick client app using something called Java Web Start, which was . a technology that Sun Microsystems back when they, owned Java put out that let you start a swing application on your desktop. And so I was using that to build thick client style applications that connected with sockets and all that.

part of that was [00:02:00] driven by, I didn't really like the way that the web. Worked early on with JavaScript and some of the early stuff that was going on there. so it's somewhat ironic that I've come back, to end up being an evangelist for, for Hypermedia, but it just gives a show.

You never know what's gonna, you never know what's gonna happen in this world. 

yeah, for sure.

I worked for a while, at a, or for a very long time, actually for more than a decade at a, a startup that got real big. That did, again, it was all web development, 

So everything was on the web. And then after that, Started my own company where I did a lot of rails development. 

The first versions of React and stuff like that were starting to come out. And, that was the point when I ended up creating something called Intercooler jss, which was the predecessor to H T M X. so that was my early web development life.

You mentioned it being ironic that you were, hearkening for the simpler technologies at the time, but given the dichotomy of what some of the alternatives are to H D M X and what else is out there, I think that kind of, having that outlook isn't that, surprising at least.

can you [00:03:00] give listeners a. A brief overview of what H T M X is before we kinda dive in a little deeper.

H T M X is a very small JavaScript library, so it's about 14 k. and, you can include it on your page and it's not like, Java script frameworks where you have a build step and all this stuff. it's an old school library in that you put it on the page and it just works and just starts working.

and, what it allows you to do is put attributes on your H T M L elements that will drive Ajax behavior. Ajax behavior, just making requests in the background, H T T P requests in the background, behind the scenes. so typically that's done these days in JavaScript, u using the fetch a p i, usually these days.

usually it's Jss o n that's fetched. you issue a fetch request, you get some j s O back, you. Run that through some processing and produce a new ui. The way that H T M X works is, again, you use attributes directly on your H T M L and the H T M X will inspect that and hook up, event [00:04:00] listeners basically to drive, these H T P requests and the HTT p requests.

In contrast with the JSON a p i, I should say, with the JS a. expects, H T M L back. what HT H T M X will do is it'll take that H H T M L that came back from the server and then insert it into the dom. And so it's very simple. At the end of the day, really what H T M X does?

you add attributes to H T M L, those attributes tell H T M X. And given some event, issue, a request to the server, take the H T M L that comes back, not the J ss n, the H T M L and insert it into the DOM somewhere. That's like the one sentence summary of what H T M X is. And that sounds pretty simple and it is pretty simple.

it's not a huge library, but it turns out that you can do quite a bit, you can make your applications much more interactive with just that simple interaction model than you might think at first. 

I immediately jumped to like old, old is maybe not an appropriate term, but just like [00:05:00] frameworks that used a templating language historically, like Rails. You said you had a rails, background where you'd kind of write, like Ruby Code and This template would then have a way you could like return H T M L, but also like inject data into it to have customized experience for users.

dotnet had one that kind of had this hybrid thing, I think it was like Razor or something, in.net apps. I'm blanking on that, but there's like The P H P equivalent and stuff. Were any of those kind of like a model for H T M X or are those all kind of doing their own like that?

That's not really a fair analogy.

they weren't models, but , that style of server side, M V C is definitely the world that H T M X came out of. and so H T M X, the original version of H T M X was called Intercooler jss, which was released back in 2013, I think. And, and it was, Based on jQuery. and so jQuery had a heavy influence on, intercooler.

Jss and still has, if you look under the covers, has, an influence on h t mx? I would say what directly influenced [00:06:00] Intercooler jss. Was, something called pja X, which was a popular library in the Rails community that did something similar. Not quite the same a p i. but Pja X did this sort of partial replacement of stuff on the screen as well.

And then Turbo Links, which was the. Obviously in the rails sort of mechanism for using Ajax to drive navigation. That was very, and it still is very navigation focused. They have something much closer to H T M X now called Turbo, I

believe. and then also it was influenced indirectly, not conceptually, but syntactically.

by Angular. 'cause Angular was the first place I saw using attributes to drive behavior in H T M L. And really that was like, to me, that's the crux of what happened was seeing angular, oh, they're using behavior, they're putting behavior directly in the H T M L, but then I want to do this P J X thing.

and those two things coming together are what made Intercooler kind of work. 

Yeah, , that makes sense for me. what are the [00:07:00] selling points here? why should devs check out H T M X? What apps is it well suited for? Or what technical problem is it trying to really solve?

I hope your listeners can appreciate, this is a pretty simple tool. At the end of the day, you're issuing, you're saying, okay, on a click or whatever, issue a request, get some H T M L back and then insert that into the dom somewhere. so that sounds pretty simple. And it is, and that's one of the big, that's.

One of the big advantages of this approach is that it is simple, when compared with, for example, something like React or, any of the, thicker client side experiences. You have a very thin client side, in the sense that you don't write a bunch of logic client side, it pushes. Logic back onto the server.

the programming model is very similar to the traditional web 1.0 you might say style. If you built web apps back in, 2005 where everything was a form submission or a link click. And, so the H T M X when you're developing can have that sort of a feel and the. primary [00:08:00] advantages of it are the simplicity of the model, when compared with, a thick client approach or an s p a single page application framework approach.

then there's also these, they're harder to define in, quick. podcast friendly terms, but there's the original model of the web, one of the really nice aspects that it had to, it was this thing called Hadio, which was hypermedia as the engine of application state.

It's a, an acronym that your listeners may have heard. . Effectively when your responses are HYPERMEDIA or H T M L, let's just say html, when your responses are htm, What's different about H T M L than say, a j Ss o n response is that the H T M L contains within it, not only the data to display to the user, but also the actions that are available to that user.

So when you get, a piece of H T M L from some server that you've never seen before, it tells you on that page what you can do. You don't have to guess about a p i endpoints or any of that. There's buttons and links and [00:09:00] so forth in there that tell you what you can do. And, so that's a very powerful, it's a subtle but very powerful aspect of, hypermedia in general.

And because H T M X uses hypermedia, you get that for free. and you get a tremendous amount of. Flexibility. From that behavior, , that style of programming, that, people , would've called restful, 15 years ago. Whereas today, they typically, when they say restful, they mean something like j ss o n unfortunately.

That's how language confusion that I can talk about.

that's a good distinction. 

Yeah, so I think the simplicity and the flexibility are two big technical, a advantages of this approach. and if someone was to ask me, Hey, why would I use this over, something like React, that's what I'd point at.

flexibility is an interesting term to hone in on a bit there. the thing people are thinking about is I. SS s r and how that maybe improves performance because I'm sure a lot of listeners that are not hyper tuned into this space are thinking like, this sounds a lot like, like React server components.

we have these kind of tools like, the stuff [00:10:00] the big meta frameworks are doing, like this felt kits and like the, the things that, like versal and stuff's trying to do with React. what's the relationship there?

Is this a dichotomy that you think about it all or is this not really a fair comparison?

I think there're just two different ways to approach. I don't know if I want, you want to say this, if I want say the same problem. H T M X is really focused on increasing the expressiveness of H T M L and that's it. Like it's trying to bring H T M L up. It's not trying to layer a framework on top of the H T T P interactions that occur.

It's not trying to introduce abstractions that live on both sides of the wire. All it does, for better or for worse is say, okay, what is H T M L? what are, what I would call, what are hypermedia controls? what are the, what's the aspect of H T M L that makes it special? So it's not just a, a formatting language, like Microsoft Word or something like that.

It's the, it's these links and these forms, which are called hypermedia controls. And so what are [00:11:00] those things? What do they do? And what they do is they, allow users to interact with the document in some way. And so then you say, okay, what's the general idea? What, how do we generalize hypermedia controls?

And that's what H T M X does. It lets you hook, in any event, and on any element issue, any type of request, and you replace anything on the screen. Those are the four things that H T M X does. And so in that level, or in that sense, H T M X is very low level. It's very close to what H T M L is. It's much less ambitious than these holistic frameworks that solve, the.

The general web development problem. So it just comes from a very different perspective, and there's disadvantages to that and there's advantages to it. The disadvantages are that it is low level. You have to do more work often something that, might be like just a one-liner and a framework might require some more work on your part in H T M X.

that's just the trade off that you make when you. Make these design decisions. but on the other hand, [00:12:00] some nice things come out of that. for example, H T M X can work with whatever backend, language and framework you want to use, as long as it can produce. H T M L.

H T M X is indifferent. Whereas React server components obviously require JavaScript on the server side. maybe you don't wanna use JavaScript on the server side. Maybe you like. Closure or Java, or.net or whatever OC camel's,

uh, a lot of OCaml users, like H T M X, Haskell whatever the, and if you're in Python, maybe you like flask, maybe you like Django, maybe you like fast, fast a p i.

And because H T M X stays agnostic towards the backend, doesn't try and solve. Both sides of the wire just looks at H T M L and says, Hey, let's make H T M L as expressive as we can, within its original conceptual ideas. I think, that, that opens up this ability to use whatever you want on the backend.

so that's, that, that's another practical advantage I would say. for users of H T M X, they can use whatever they'd like on the backend.[00:13:00] 

it feels like, HT M X is the, I don't know, the opposite, the antithesis of, like a lot of these like heavily opinionated frameworks, this is the only way we can do S ss r. We've been doing s s r for a long time, But there are a lot of niceties that those brought along.

But I think that there is some middle ground here, that kind of HTM X is exploring and getting eyes on and making people think about again, which is pretty interesting. on that note, In the wild are, is there a common stack then that, people are using with H T M X?

Are people usually tying it to a specific thing? Are a lot of people using this with like hosted backends or is it all across the board? you're seeing usage for full stack apps, people self-hosting stuff all the way to these, like software as a service backends and just returning H T M L from them.

Y Yeah, I'm seeing a lot of different backends and that's intentional. So H T M X first got big, I would say in the Jango community. That's where H T M X first got picked up. And part of that is because Jango is a big old, very deep. A lot of people very [00:14:00] passionate about it. It's like the rails basically of the Python world.

It's been around forever and many passionate users, but they didn't have something like Turbo Links or Turbo that was focused on their web framework. And so I think that just timing and. the, everything came together to where the Django developers, when I launched H T M X as the successor to Intercooler jss, a lot of 'em had seen Intercooler jss.

And so it was just ripe to grow there. There was a need, and so H T M X filled that. So initially, H T M X was, definitely. Picked up by the Jengo community since then, however, it's really grown out into a lot of different communities and I try to reach out, I try to go on GO podcasts and anyone who will listen, net podcasts, Python, anyone who will listen because.

, I want H T M X to enable more backend languages and frameworks to participate in the modern web. I'm not a huge fan of JavaScript as a language. it's fine. Obviously I've [00:15:00] written a lot of JavaScript at this point. but I really didn't like the idea that there was gonna be this monolithic culture of JavaScript development in web development.

And you were gonna have JavaScript on front end and. We're gonna have node on the back, we're gonna have react or whatever on the front. because I like the diversity of programming languages and even frameworks within programming languages. I think it's a little harmful for there to only be one thing.

'cause then you don't learn from one another. You don't, grow and languages just have different strengths and weaknesses. Python's really good at ml. . But rust, there's a lot of really passionate rust developers who are asking, how can I get rust on the web?

And, You could produce a J s O n A P I with Rust if you wanted to, but why not, Do a lot more work in rust and use Hypermedia as your front end. And then all these techniques that, work well for other languages translate just as well into rust. I think , it's something that, I don't wanna say it's a focus, but it's something that I appreciate about H T M X is,[00:16:00] I really do want there to be a whole bunch of different programming languages that are using it in different frameworks that are using it.

Now, . the downside to that is that, it's really hard to have a canonical demo of H T M X. and I've run into that with people before who are used to, I just wanna run, like React, a new React app or whatever it is, and just have all my stuff set up for me.

And I just have to tell 'em, look, that's not the way H T M X works. H T M X is really small and focused on improving H T M L, and that's it. You're gonna have to bring your own server here. And, I think that hurts. H T M X sometimes. I wrote a book that, I recently released called, hypermedia Systems, and people, you can go to the website, hypermedia Systems and read it online for free if you'd like.

and in that book I used, flask and Python. , I'm not a Python programmer, and I had never used flask before for anything serious. but I picked that stack because Python is obviously very [00:17:00] popular, particularly with college students these days. So a lot of young people know the programming language.

And then Flask is a very, even though the Jango community is more into H T M X. And flask is very simple. And so it makes it very obvious what the mapping between a request is and the logic. And whereas Jengo is a little bit, because it provides a lot more functionality, is a little bit more roundabout.

And so I felt that was the best combination of technologies even though I wasn't familiar with 'em, to use for that book. I do think that lack of a specific backend that I. To say, Hey, use this, hurts HTM X in some sense, but I also think it's a strength.

I think that is a wise choice and I think that is the kind of the crux of a lot of these tools that are trying to make tech that is a little more agnostic. I think that, there is an interesting philosophical question that happened along this kind of, this migration we had from traditional apps to then s spas and now we're doing this s PAs with a bunch of SSR and stuff.

It's still feels like , for the most part, a lot of these frameworks, the s s R [00:18:00] handling, is still this separate piece where it is getting. Data as data, like it's still J ss o or whatever , it's not hypermedia, it's not a thing that the browser's ready to handle.

so the backends can still be written in this way. We're like, we can write like an J Ss o a p i that then can be consumed by other. Things, ,

is there, an easy answer for that or is there should maybe be an intermediary layer that is in like consuming the data in a server capacity and then writing like H T M L and returning that to the client? Or is there something you'd prescribe for devs that are in that situation where they already have all this data?

From APIs that are returning J S O N currently,

I would go two directions, first of all as an A Json a p i consumer, someone who, where you're consuming a lot of Js, o n, And that's in that situation, if you're just in a position where you have to consume J ss o n, you wouldn't want to stream that. J S O N to H T M X.

H T M X does have a, mechanism for using client side templates, so you can make your request and run it through a client side template. It [00:19:00] just, it's not the way it's supposed to be

Yeah. It doesn't feel like it's really

it doesn't feel right. Yeah. So . It feels like you're using HT MX to use HTM X at that point.

I have had people say, oh, I'm collecting data from three or four j ss o n endpoints to present in my application. And the way to do that, with HT M X is have, a server side app that does that. Coalescing of all that data into a a, a usable HYPERMEDIA response and then issue your H T M X request against that server that does that coalescing of all that data.

now that might not be a good idea because maybe, , depending on how those JSON APIs behave and who controls 'em and all the rest of it, that might not be great. But HTM X really does want to talk in terms of HTML and hypermedia. so that's one side, if you're consuming on the other side, if you're producing.

I hear a lot when I say, oh, you should consider H T M X, is people will say, okay, but my json a p i isn't consumed only by my web app. It's consumed by , a mobile app. It's consumed by a. third parties and so forth.[00:20:00] I appreciate that. what I would say there is that, and I have an essay if you go to htm x.org/essays, there's a whole series of essays that you can read where I'm very boring about this stuff.

But one of the essays talks about splitting your APIs up. in that essay, I. Assert in many cases that the application a p i and the third party or mobile a p, I actually have different needs from one another, different technical needs from one another. And so it's actually an advantage to split them up into separate u r l schemes, separate and maybe even separate servers, because your application a p I.

as people have come to find out when they're building, spas needs to change quite a bit in order to keep up with your front end application needs. And that need for change is something that Hypermedia is really good at handling. And these fixed data APIs, like j ss o n, is, they're not set up for that, [00:21:00] so that's why you have to version it.

backwards compatibility and all that kind of stuff, with a hypermedia driven system, you don't need that. and so if you pull out your app and make it hypermedia driven, you can take advantage of that flexibility of the Hypermedia system. and it's, it gives you all that flexibility.

You don't have to worry about versioning or any of that, nearly as much as you do with J S O N APIs. On the other hand, when you look at like third party. systems that are integrating with you from a via json a I or any data a p i, the needs there are just different. You have, you, you need to be able to rate limit them.

you want to give them an expressive a p i. but that's not so expressive that it can be, taken advantage of. So it needs to be regular, it needs to be well documented. It can't change dramatically. So there's just, it's a very different use case for your system through that a p i.

I think there's a real strong argument for actually splitting them up into two separate projects. Have your system, a p I and your hypermedia, a p i. Now those two [00:22:00] projects could. And could and probably should talk to domain objects sitting just behind the APIs and so you would have your domain logic implemented in some model layer that's reused between those two.

but nonetheless, I think presenting two different APIs, is often a good thing rather than a hassle. 

I think it, it's very reasonable so that you could have your like hypermedia, a p I written on top of like your json a p i internally with some like special privileged access and then it can do its whole thing. And there's like the external one. I don't think it would need to be that much additional work from an architecture perspective.

But I do think that GraphQL. It was trying to solve a lot of these problems as well, right? Like. It's like, like Jason APIs are brittle, their version. there's all this stuff. what if we just made it so the clients could be more expressive in how they asked for data?

And it does feel like GraphQL is maybe a little bit closer on that scale to what? We're trying to achieve with Hypermedia. Do you think that GraphQL is still lacking in that regard because it doesn't have these like kind of verbs baked into the data [00:23:00] that's being passed around? Or is there some other intrinsic kind of shortcoming 

I would actually point at a different shortcoming with GraphQL. and that shortcoming is the fact that GraphQL, I think, is a reasonable response to these problems. Like it's a reasonable, oh, okay. We don't want a version. we need our APIs to be way more flexible.

We don't. Which is what a lot of J S O N APIs do. People complain, oh, J ss o's so much more efficient than hypermedia. And then you go and you look at the actual responses and people are pulling down megabytes of J ss O because they want, two or three fields out of it. And it's like, guys, if that was an a hypermedia response, you just return the table that you were interested in and it'd be way cleaner.

But setting that aside, I, so GraphQL is solving a reasonable problem. the big problem that I see with GraphQL and I, man, oh man, I've been on this, horse for a while now. Is that GraphQL? Yes. It increases the expressiveness that's available on the client side. But any power that [00:24:00] you give to your end developer, your front end developer via GraphQL, you also give to hostile users who can open up a console and start issuing GraphQL queries against your endpoints.

and you would never do that with, for example, a sql. You would never just say, okay, user, here's a sequel

Right, right, right.

instinctive understanding that would be a bad idea.

Yeah.

The reality is that depending on how your GraphQL system works, like that's, I don't wanna say it's effectively what you're doing, but you're getting much closer to that than you might suspect. if you make it possible, to get salary data or even to order by salary data, even if you don't return the data, just ordering by things or issuing queries that bog the system down, there's all these vectors for attack.

That come about when you increase the expressiveness that's available on the client side. this, I think is a strong reason to keep these sorts of technologies, these query technologies on the [00:25:00] server side where you can, to a first order approximation anyways, give people, full SQL access to the database.

Obviously developers can screw that up. There are problems that need to be dealt with. That's been done for, three decades now, and it's not, hasn't proved catastrophic for the most part. that's an area where, or that's, GraphQL is one of these things where I think it's a reasonable response to the problem, but there's another problem with it, which is this security thing that I don't think a lot of people who are using GraphQL understand, or appreciate.

my understanding, and this is via Twitter, so who knows if this is true or not, but my understanding is that Facebook actually whitelists all of their GraphQL query. Like every single GraphQL query is whitelisted in their system. And I think that there's a lot of people out there who are using GraphQL, who are not.

Doing anything remotely like that's pretty intense to go through every single query and waitlist it. And, so they're not, I think there's a recognition that there's a security issue there. I just, I don't see it discussed very [00:26:00] widely. and I think it's inherent this, there's just this inherent problem of you can't increase no matter if it was GraphQL or some other.

Technology, it's very difficult to increase the client side expressivity in the browser where people have access to the console and can do whatever they want, just that's the way it is, without, exposing yourself to security issues.

I think in particular, in a lot of the way that kind of the. I dunno if prescribed, but just the way that people were recommending those GraphQL backends and stuff be established, it would just be like, oh, we added a new field to this table. We didn't even think about it. And it just ends up bubbling out via the GraphQL a p i.

No one even thought about it. So then, yeah, like you said, then you get into this room like, okay, make it so everything has to be explicitly white listed and version. It's now we're just back to a versioned a p I. Again, we have all the same problems we had with JSS O so it's what did we, what did really achieve, Yeah.

that's an interesting point on if we can stay on security for a minute, if devs choose to go use something like a tool like H T M X, I think it is bringing back into their [00:27:00] purview a subset of security problems that are being handled by the frameworks.

Right now. It's like we don't have to worry about cross size scripting if you're using a react quite as much. 'cause there's like enough handholding and stuff where it's like, okay, well. Parse this and react shadow dom and it has all these things that'll help figure it out. But I feel like we could wind up with a lot of these kind of, vulnerabilities of old, maybe for lack of a better term, if we're going back to this rendering mode.

And maybe that's an okay thing. is there like any work being done to make that less of an issue for devs getting into this space for the first time if they weren't used to this paradigm

It's funny, there's definitely a generational thing here because, the younger developers, so the style of attack that you're referring to is, called X S s or cross site scripting attacks. And, bare bones idea, and this is, it's doable in just plain H T M L, is that if you are rendering H T M L, if you're rendering content from a user, As H T M L and you don't escape that content, then it's possible for the user or [00:28:00] for the users, particularly if they're interacting with one another's content to inject H T M L into your app that does malicious things.

you're right that react makes that much harder. it's still doable. There's set inner htm. I, there's ways I.

do it. React, yells like, don't do this unless you know what you're doing. Right?

Yeah. it was an issue, early on in web development and it was solved pretty effectively via templating systems, and just people understanding that they had to escape content that was entered by users. so most server side templating systems, almost all that I've ever.

Experienced with do this, they escape, the content unless you explicitly say, Hey, I wanna insert this directly. And then you have to be real careful about, how you do that. H T M X moves these considerations back onto the server side. And in as much as you're using a mature web framework, traditional M V C style server side framework, it's not as big a deal as people probably think I've seen [00:29:00] people freak out. We've had some pretty funny threads on Twitter where, and a lot of it boils down to younger people freaking out, and then older people like me going like, no, this is a solved problem.

That being said, I do have to say, there was a tweet, three or four weeks ago now. the person, he basically raised this concern, and I do have to say since he did do that and there was all this. all these eyes looking at H T M X, we've gone back and looked at the go base and said, okay, we have tools in H T M X, for example, there's a, an attribute called HX disable that you can put on an element and say, don't do any processing of stuff inside this element.

so that if you have content that you know is dynamic and you wanna make sure that there's no way HTM X will touch this stuff, you can do that. We also, in the latest release, introduced the ability to turn off, making requests, to a different origin. So basically enforcing that H T M X only makes same origin [00:30:00] requests.

a Ajax requests can go anywhere by default, and you can fix that with cores, but cores is when your server gets the request, not what your client code does. Your client code can go out. And so we introduced a config variable that's allows you to say, okay, if you wanna lock this down and not let requests go to any other domain, then.

you can set this to true and when HTM X 2.0 comes out, we're actually gonna make that the default. so we've tightened up our security because of this conversation. around it. I think there, there is a little bit of fud, but at the same time it's a legit issue and there's some education that needs to be done and there's more stuff that we can do.

it's a different style of programming and has its own security issues at the same time. when I'm not being as charitable as I probably should be, I just look at GraphQL and I'm like, you guys are ready to slap GraphQL on, on all this stuff with all the security issues that come with that.

And now you're complaining about , what's a relatively solved problem in terms of web development? . And it is a fair criticism and concern of H T M X and it's something people [00:31:00] should definitely be aware of if they're using HTM X is how are we making sure that we're escaping our, the client content on the server side?

The good news is that almost every server side M V C system does that. So

Yeah. Yeah.

tools already for that.

It does feel a little bit disingenuous to, make some contrived example of look how easy it would be to break this thing. And I'm using none of the tools that anyone in production would ever really feasibly be using.

Like the same thing if you like rip out a bunch of the React internals you can make or react to all kinds of stuff too.

you're just a set internal html a, right? Like it's all doable. but, , I don't want to downplay it. is a legitimate security concern and. There's a great website called oasp that has a bunch of information on that, and you can go to the security section in the H T M X documents, htm x.org/docs page.

There's a security thing that links over there and explains all the things that you need to get right.

if devs are looking to explore this or they've felt some of these pain points that were articulating, but they've got [00:32:00] this giant working code base and it's hard for them to, like, I can't get rid of React. is it doable to have like H T M X exist in tandem with these other frameworks?

Or is it like you gotta pick some isolated versions of the app and you can really only have one, one running there?

, you can scope it down quite a bit. You could have just a single button that's H T M X powered and does a thing and experiment with it. or a single page, for example. I always, when people will say, oh, we've got a giant code base in React, I'm hesitant to recommend. If things are working, I especially, I'm very hesitant to recommend, oh, we're ready in H M X.

It's gonna be so much better. It's not ht, M X isn't a silver bullet at the end of the day. It has advantages and disadvantages just like everything else. and, what I typically tell people when they come from that situation where they've just got a huge react echo basis, maybe HT M X could.

fit around the edges, like supporting admin tools. Maybe you have an admin tool that needs, for example, that if you go to the HTM x.org/examples page, there's an active search example [00:33:00] where it uses HTM X and you type into a text box and it filters down the results as you're typing. And that's a really nice user experience compared to, Particularly the old web 1.0 mechanism where you'd have to, you'd type and you'd hit submit and the page would refresh and it just took forever.

so it's a much better experience. And so maybe you have some admin screens that aren't using React for everything, or if they are, it's not. Super important that a b react. And it's not super fatal if things don't work quite right for a little bit. and those are places where maybe you can start trying H T M X out and see if it fits well.

yeah, that's what I typically recommend to people that are in. that are in deep. Now that being said, one of the sort of f flagship examples of H T M X, an HT M X success story is context. it's spoke texty, but it's, a French company. they were building an app.

And they were failing at building an app in React, and they moved, they decided to [00:34:00] move from React to HTM X and there's a, again, on the HTM x.org/essays page. There's , an essay on this or just really a blurb on it. linking to their talk that they gave a Django Con, where they talk about, we moved from React to H T M X and they had a really good experience.

They dropped a bunch of code and stuff like that. So if your application is flailing, and particularly if you feel like you're a strong full stack developer, like you feel like you have a good strong sense of what the backend can do and the language that you're using, it might be worth at that point taking a look at H T M X as a potential replacement.

It sounds like you thought a lot about, philosophically about like how data should be sitting and like transmitting over the wire for the web.

Do you feel that , the paradigm that H T M X introduces is kinda like putting a patch. Html. do you think that should be part of the web standard? Should the browsers just be able to request an HTML endpoint, like patch, give me the delta here when I make this change.

Because I feel like that's what we're trying to empower here, right? should that [00:35:00] just be native?

Yes, a hundred percent

yeah.

imx is how HTML six should work. I'm sure there's. Decisions that I've made that you might object to as far as whether or not this particular, should we fire an event in this case or whatever. but I think the general idea, and it, the thing is about this concept is it's very old.

it was called trans exclusion, early on. And so it's been around forever this idea like, oh, and iframes give you half of it in a weird, in a really weird. so there's, I feel like this behaviors are around the edges, but again, in my mind, H T M X is a generalization of the concept of hypermedia controls.

It's looking at an anchor tag and a form tag and saying, okay, what's the general idea here and how can we make this. More broadly usable. How can we generalize this idea so that it can be used for more stuff when we're doing application development? and yeah. Yeah, I would love it if the browsers, I don't like having to maintain [00:36:00] this.

I don't dislike it, but it's fun. I like Twitter a whole bunch. I think for sure if I were, if I had the ear of. I don't even know who's in charge of this stuff anymore. I do talk to the, I've got some Chrome developers that I email back and forth with, and they, I think they understand the idea and see the value of it, but man, , if you think about it, H T M L doesn't even have the ability natively to issue a delete.

Or a patch 

Yeah.

and I've seen there's a ticket out there where someone said, Hey, let's fix this. And I think it was the W three C basically said, no, we can't. so there's a lot of barriers, unfortunately. H T ML kind of stopped, like right around like HTML two, I think introduced forms and post.

from a Hypermedia perspective, that's it. . and that's crazy. That was like in the late nineties. And I think it's a testament to how powerful hypermedia is, that really only with forms and links, [00:37:00] we were able to build so much stuff, But it's also a shame that, H T M L has been so hamstrung. they've obviously, HTML five introduced a whole slew of improvements, but all those improvements were around client side interactivity rather than improving the hypermedia infrastructure of the web. little confusing, but, it is what it is.

it works well enough and so it just, there hasn't been as much pressure as maybe there. Could have been, to I improve H T M L as a hypermedia.

fingers crossed. So I guess on that note, what do you think the future of the project is? 

I view it as a very stable, even Intercooler to H T M X, which Intercooler has been around for almost a decade now. was not a big jump. It was basically, saying let's take out. jQuery so that we don't have a jQuery dependency.

we changed the attribute names and so forth, but conceptual is very similar. and I think H T M X 2.0, will probably be out by the end of the year. And I've, just recently decided that it's actually gonna be [00:38:00] even less of a major upgrade than I thought previously. there were some features that we were thinking about putting in.

I just keep coming back to this, let's just keep this as simple as possible. And it has an extensions mechanism and that's what we'll use for the crazier stuff. so we can do more exploratory work and so forth. I think H T M X 2.0 is gonna end up, we're gonna drop Internet Explorer support, which is.

a meme at this point. But, H T M X 1.0 does support, internet Explorer. and we're actually pulling out the old web socket and servers sent event stuff. Most people are using, we have extensions for those now, and we extensions because we didn't want.

H T M X, the core of the H T M X library to blow out. But then we wanted the web socket and service line event stuff to be fully functional. Like we wanted to be able to do more stuff with it without feeling this pressure of oh man, we're making the core library too big for something that most people are not [00:39:00] using.

At least not today. So I think, H T M X 2.0 is gonna be pretty, like 99.9% of HT MX one users, when they upgrade to it, should have no work to do at all. There's been a big focus on backwards compatibility with H T M X and I want to keep that.

I want it to be really stable. it's in contrast with the rest of the JavaScript community, which can be pretty dramatic, even on like minor releases, like APIs will get completely changed and we've tried really hard to not do that. And people sometimes come into the code base and they're like, oh, this sucks.

Like you should do this. And I'm. you're improving things for sure. But on the other hand, that is gonna break a bunch of people's stuff 'cause they're relying on this. So we can't do that. And then sometimes they get a little frustrated and I appreciate that frustration. But , we definitely have a focus on backwards compatibility and not touching things that are working that I think other, you don't see as often, in the JavaScript community.

Anyways. 

yeah, [00:40:00] it's always encouraging to hear. I think all of the downstream consumers appreciate as much stability as they can find. Thank you so much for, coming on and chatting with me, Carson. It's been a

Yeah. Absolutely. Yeah. Thanks all. Thanks for having me. And thanks for putting up with me talking about, about Hypermedia.