Episode 261: Alexander Petros on HTMX and Sustainable, Simpler Tools  ## Metadata - Author: [[Sustain]] - Full Title: Episode 261: Alexander Petros on HTMX and Sustainable, Simpler Tools - Category: #podcasts - URL: https://share.snipd.com/episode/3b51b597-3ed1-49fe-84ef-cb57d8d71243 ## Document Notes ## Highlights - **HTMX Enhances HTML Behavior** - HTMX extends HTML to enable more complex network requests with simple attributes. - This empowers most interactive website behaviors without heavy JavaScript usage. Transcript: Richard Littauer What is HTMX and how is it different than HTML? Alexander Petros So HTMX is a front end JavaScript library. It's about 4000 lines of code. You import it directly and with a script tag into the document. And it adds a couple attributes to HTML. So the idea behind HTMX is that a core missing feature of HTML is the ability to do a wider variety of network requests and do more interesting behavior with the results of those network Requests. So right now, there's basically two ways to make a request from HTML. You have a link, which does a page navigation, and you have a form, which submits some data and then does a page navigation. And if you want to do literally anything else, then you need to use JavaScript. And the idea behind HTMX is that you don't have to add that much to HTML to add a really powerful set of behaviors that remove a huge chunk what people are doing in JavaScript, which is just A handful of HTML attributes. So HTMX adds a couple new methods to HTML. Instead of just post and get, you also get put, patch, and delete. And it also lets you put those requests on any element. So you can do it with buttons. You don't need forms. And it also lets you insert the results of those requests into the document wherever you want. ([Time 0:01:43](https://share.snipd.com/snip/2303ada1-3a31-4e2f-b7cf-01b1f5c2c5f8)) - **HTML Designed for Behavior** - HTML inherently encodes behavior and interactivity through hypertext. - HTMX revives this by embedding behavior directly into HTML rather than relying on JavaScript. Transcript: Richard Littauer So I always think of HTML as the scaffolding upon which a website is built with CSS being the paint and JavaScript being the thing that moves wings around like a Hogwarts castle. You're saying that the scaffolding itself could also do some of the language work. Alexander Petros I think that's how HTML was designed. HTML is hypertext markup language. So the hyper refers to the behavior. Otherwise, it would just be a text markup language and then you could add behavior later. So the hyper is the idea that we're not only encoding what is on the page, we're also encoding what you can do. And the most powerful form of that is the hyperlink. So it's much richer to read a Wikipedia page than it is to read an encyclopedia. Boy, it's been a while since I thought about paper encyclopedias, but that's a richer experience because not only do you have text, you also have images and you have links to other parts Of the encyclopedia. ([Time 0:03:04](https://share.snipd.com/snip/2994e1e8-e969-4dac-8ef2-2ed4d9b67566)) - **Minimal Webpage Example** - A webpage with just text and no CSS demonstrated HTML's power and compatibility. - Browser 'reader modes' build on this by adapting content for diverse devices and accessibility. Transcript: Richard Littauer It is responsive. It is perfect. There are no issues with it. It works in every browser. You don't need anything. And it was literally just text on a page and there was like nothing else. You know what I'm talking about? I do. Alexander Petros It's got a curse word in it that I'm not allowed to say on your podcast. This is an MFing webpage. It has no CSS whatsoever. And there's a number of riffs on that concept. There's a follow-up called better MFing webpage. And that has just like seven CSS declarations and it looks a million times better. I actually think one of the best innovations that browsers have had in the last 10 years is the introduction of reader mode, which says, hey, you've told me, the browser, how this text Is structured. I, the browser, am just going to yeet all your formats into the trash bin and I'm going to put this in a really nice readable format that's adaptive to whatever browser and format you're Using. ([Time 0:04:46](https://share.snipd.com/snip/5bf5ca18-dbe9-4051-8906-b75c74216233)) - **HTMX's Origin Story** - HTMX grew from Intercooler.js, a jQuery extension that was later standalone. - This evolution reflects HTMX's mission to improve HTML without complicated dependencies. Transcript: Richard Littauer Very exciting to be there with you. I do have one question. It sounds like you're just trying to recreate jQuery because jQuery is a really simple, small JavaScript language that does all these things already, doesn't it? If you had to guess off the top of your head, what percentage of websites roughly use jQuery today? Alexander Petros 80? I think it's like in the 70s, according to the main website, you go to figure these things out. So yes, HTMX started life as a jQuery extension called Intercooler.js. And I should clarify, I'm not the creator of HTMX. I'm one of the core maintainers. But nevertheless, I know the history because I'm involved in the project. But Carson Gross, the creator of HTMX, he made a library called Intercooler.js that was a jQuery extension. And then during the pandemic, he said, let me see if I can rip the jQuery dependency out. And he polished the interface a little bit. And that led to HTMLX. It's important to understand HTMLX as the continued development of a paused intellectual idea, which is that HTML is good. ([Time 0:05:48](https://share.snipd.com/snip/baf7fe30-2c8f-4e49-83b9-23469f172f24)) - **Start Simple with HTML Files** - Start building websites with just HTML files to avoid dependency headaches. - This approach allows simple long-term maintenance without complex tools or environments. Transcript: Richard Littauer When you think about HTMX and why it's important that you do this work, why you restart this pause thread of what HTML should have been. Alexander Petros Are you thinking of people like me? Is that like your target audience? Yes, explicitly. There's a previous sustained podcast guest, Julia Evans. She has a blog and she talks about how she wrote it in Hugo 0.3 or something. And now Hugo's on 5.something. And she doesn't need any of the new Hugo stuff. She just needs to get the very, very old version of Hugo running on her laptop so that she can update her website. The blog is about all the hoops she has to go through to do that. But in my head, I'm reading it and going, you shouldn't have to do that. Your website should just be there for you to pick it up. So a big part of my intellectual journey was having exactly that problem where a couple of times I was like, I need a personal website. And I had learned how to make a website in React, or I had learned a little bit about static site generators. And I stumbled multiple times on the hurdle of like, well, how do I get started? What's the right thing I need to install? Am I choosing the right static site generator? Oh, I don't know Ruby, so should I instead I use Gatsby because I know React and I know JavaScript. So there's all these conceptual hurdles. And what finally got me to make my first blog was I just started writing HTML files. I copied manually the styles. This doesn't scale at all right, but it gets you started until you get to a point where you know what higher level abstractions you actually need. And every website that I've written like that, every time I want to come back and update it, I never have that thing that you just described. I never have that moment where I have to reinstall something that I no longer understand. I no longer understand why I need it and it's not really even supported maybe for my current computer. I just have files and I can those files and they work. And I think a lot of people undervalue that. ([Time 0:07:13](https://share.snipd.com/snip/d7107f79-238b-488a-8151-975c139ba4e3)) - **HTML's Longevity and HTMX's Role** - HTML's universal adaptability and longevity make it a stable base for web development. - HTMX adds minimal, standards-compatible features aimed for long-term sustainability and eventual browser-native support. Transcript: Richard Littauer Talks about conflicting standards. There are all these standards. Let's just make another one. Oh no, now you have another standard. How are you avoiding that in building HTMX? How are you not just causing another complicated thing that people are going to have to know? Okay, here's HTMX and here's HTML. Here's why they're important. Alexander Petros Well, first of all, HTML is the hypertext. There are no other relevant hypertexts. There's no other relevant way to share to make websites. Yes, there are other ways to make HTML, but at the end of the day, you're going to have a thing that is in some sense HTML. So that's the universal standard. And there really isn't anything competing on the horizon. So you start from that base point, anything you do on top of that, and I mean, literally anything, I mean, including CSS is a thing you are on some sense on the hook for maintaining and updating Into the future. So the Cambrian explosion of the web was the introduction of the mobile browser. And I don't know, I saw on Twitter a while back, somebody's like the cliff bar website used to be so creative. And it was like, there were cliffs and there was a sidebar and there were people climbing. And now the cliff bar website looks like any other website with a single page layout. And the reason for that is that a bunch of people made a bunch of websites under the assumption that they were going to be consumed on a desktop browser. And then all of a sudden, everyone's websites were consumed on a different type of browser. So they had to update all that. In the talk you referenced, building the 100-year web service, one thing that I learned in the process of researching that talk is that the original web browser was command line and Terminal based, because of course it was. And the interface for clicking on a link in a command line browser is very different because there's no clicking. So they put little numbers next to each of the links and you type in the number in your terminal to navigate to that link. And then it shows you that. So HTML, by describing both the content and the behavior of the page, is the maximally adaptable standard. It can adapt to even non-visual interfaces. A lot of accessibility tools do this, but it can adapt to different formats that we don't anticipate today. Reader mode being another example of that. So with that conceptual frame which is that anything I add to HTML is a thing that I the developer and responsible for maintaining HTMX adds very very little and it does so in a way that Not only do we hope is adaptable in case in the future there is a better HTMX there are browser native tools for doing partial page replacements and the additional HTTP methods. But also Carson and I are working on taking some of the core concepts of HTMX, the most standards compatible ones, and actually putting them into the standard. So in the next five to 10 years, it's possible that there may be people with HTMX sites for whom HTMX is legacy code. It's a thing you don't need anymore. It's a thing that they're on the hook for maintaining. And yeah, there will be a little bit of work required to bring it up to speed with modern HTML, which hopefully includes some of those behaviors, but it's very little work. ([Time 0:09:10](https://share.snipd.com/snip/f08c3f81-6c3f-486a-ad08-bcc80a98546b)) - **Web's Sustainable Software Future** - The web is the most sustainable software platform for decades. - Websites made decades ago still function today on unexpected devices, unlike native apps. Transcript: Richard Littauer Alex, that's awesome. That's really cool. Going to your talk, Building the 100-Year Web Service, tell me about what you envision for 100 years from now with HTMX. Alexander Petros So the title of the talk is deliberately a little provocative because there are a lot of people who will tell you that that's impossible, that software's changing, everything's changing All the time. And I disagree with that for a number of reasons, not the least of which being that's just a super nihilistic way to think about making anything. Nothing matters. It's all going to change. Why try? I don't plan to live my life that way. No, thank you. Second of all, I don't think it's true. The standards XKCD comic is a pretty great example of why in the web space in particular, I don't think that's true because there was one standard 30 years ago and it's still the standard Today. People do different things to make it, but CSS gets better. There used to be people who did CSS preprocessing libraries and now those are largely unnecessary. So the web is, I think, going to be the most effective delivery mechanism for software for the next couple decades. And I talk about a couple of reasons why in the talk. I mean, just look at it. If you made a website 20 years ago, that website not only is still around, probably, but it's displaying on devices that you didn't anticipate. That's a huge win. That's not true. There are iPhone apps that I downloaded when I was a kid that no longer work on modern iOS devices because the developers gave up. They're like, I don't want to keep paying the fees. I don't want to update this to the new SDKs. The web has a different set of values and those different set of values lead to much more sustainable software. So I think we can look at the software ecosystem right now and say, oh, if I wanted to make a thing and I wanted it to be around for a really long time and I wanted to be useful to the widest number Of people, obviously, I would put that on the web. And that is a very powerful paradigm for understanding software and understanding software that one might build for a very long time. ([Time 0:12:15](https://share.snipd.com/snip/c7386654-9ba4-4311-9c77-f17dfd35d42b)) - **HTML Enables Interactive Data** - HTML with HTMX offers interactive and manipulable data, unlike static formats like PDF or DOCX. - Such interactivity underpins most web application use cases today. Transcript: Richard Littauer Yeah. Alexander Petros It's like incredibly important. And basically just a text file at the end of the day, A Unicode text file. Yeah. Richard Littauer So Unicode text file. So I'm curious, HTMX, por qué no docx, etc, etc, etc. Alexander Petros Are worthwhile for archival data. There's a bunch of interesting ones in there, including, by the way, the SQLite database file format is standardized. And the Library of Congress is like, yeah, you want to give us data in the SQLite file format? That counts. I did not know that. SQLite's very proud of this. It's prominent on their website. Annoyingly, HTML is like a secondary recommendation to like find if you want it to be HTML. And I understand, I think where they're coming from, which is that HTML is a slightly different goal. It's not really a data cataloging or preservation format. It's more of an interactive data format. And a big part of HTMX thought, a big part of what brought me to the project is Carson, the creator, has done a lot of writing about hypertext, REST, a lot of kind of highfalutin theoretical Talk that I think many web developers dismiss as being overly academic and not relevant to what they do, but has opened my eyes to the strengths of HTML as a concept. And what HTML and REST are good at is giving you data and then giving you kind of embedded within that data, describing to the user, here are ways that you can change that data. So that means that if I have a bank account and I am seeing in divs or paragraphs or whatever, what my bank balance is, I'm also seeing buttons that are like, send the money to someone or Put the money into a different account. So every time the server responds, it's not only telling you, here's what the state of your application is. Here are ways that you can change that state. And if you really boil it down, that's 95% of what people are doing on the web. ([Time 0:14:50](https://share.snipd.com/snip/21c85dc7-c1dc-49e3-ad5d-da9f5f634be8)) - **Prefer SQLite over Docker** - Avoid heavy reliance on Docker for local development due to overhead. - Use SQLite instead to simplify development and speed up iteration. Transcript: Richard Littauer You're trying to figure out how to get HTML to be better. I totally approve of that. But why don't you just use a Docker container like everyone else? Like what's wrong with you? What's wrong with using NPM? And just having like a package manager, doesn't that solve all these problems anyway? Alexander Petros Docker in particular, I have a bit of a beef with because I totally understand what it's useful for. And I've come across many web services that I was put in charge of maintaining where the first thing I said was we got to Dockerize this because whatever solution we have to keeping the Local Redis and the local Postgres and the local web server and the local static file server together is not working. Docker, let's do it. However, because Docker has now become the boat that we all sail in together, I think it's kind of easy to forget how nice the development experience is when you don't have that thing. And I didn't actually talk about this in the 100-year web service as much as I was like. I didn't talk about Docker at all. But a big part of why the recommendation that I have is that you start with SQLite as a data storage method is because it is dramatically easier to develop with SQLite on a number of levels Than it is with any other data format. It's just like off the top of my head. There's no additional process running. So if you know JS web server and you have a SQLite file, you don't have to start all the Docker stuff to develop. And the seconds that you get back doing that, they add up real quick. They don't have that moment of like, well, here's 10 seconds for the Docker to warm up. Oop, the daemon's not started. All this stuff that like we are used to because it's necessary to maintain the kinds of services that we've created in the last 10, 15 years. You can actually resolve that by not building that way. ([Time 0:17:40](https://share.snipd.com/snip/3438dbc8-219f-4d25-9460-29b1ec8651e4)) - **React Solves Org Chart Problem** - React primarily solves organizational complexity for large teams like Facebook. - Most developers don't need such complex frameworks for their projects. Transcript: Richard Littauer At all. Which brings me to my next question, which is industry, best practices, et cetera. There's a reason we have React. There's a reason we had Angular. There's a reason we have Vercel. If I'm going to build a performance... I hear you, but let's imagine for a minute that I am working with tens of thousands of people and they all need to use my website. Does HTML really deal with the things at scale? Like can you make Signal the app in HTML? I would argue no. So isn't what you're talking about, all the tools you're saying, you can do it simpler. Isn't that just saying, well, ignoring all the hard, difficult problems that you already have? How are you not preaching to the choir? Alexander Petros This is the Sustain Open Source Podcast, right? How many open source projects have tens of thousands of developers at their command? There's not a lot. I'll give you a more comprehensive answer. I'm going to shout out my friend, Aram. I'm sorry if I pronounced your last name wrong, Aram, but Aram Zuckershaw. I worked with him at the Washington Post. He's still there. He's a big open source guy, kind of introduced me to a lot of the web standard stuff. He told me something that I didn't understand for years. It was before I was involved in HTMX, which is that React solves an org chart problem for Facebook specifically. And the org chart problem that Facebook has is there's a website, facebook.com, where there are about 10 different business units that are displayed to the user when you open facebook.com. There is the marketplace, there is the friend graph, there's the news feed, there are sponsors, there are posts from your friends. There are a bunch of different things happening. And what Facebook needs to solve is they need a lot of people to be able to work on what is fundamentally one.com/website. So what React does is it lets you repeatable, reusable, and ultimately packageable across different business units in your organization. And I think that doesn't result in a better website is basically what I'm saying. At some point, there was maybe a point where before web browsers had the capabilities that they have right now, where you could push the limits of what was possible in the DOM to push those Limits in a way that was necessary for businesses. But I think that most people don't have that problem. It's like a cliche to say, you don't have Google's problems. You don't have Facebook's problems. But React primarily solves the problem of how do I get lots of developers to coordinate on one website? And it turns out that actually breaking your website down differently can lead to a different set of problems that are ultimately more manageable than the problems that React causes. ([Time 0:19:20](https://share.snipd.com/snip/db41ac09-4c07-4d1c-86db-fade7f509b5c)) - **Diverse Origins of Open Source** - Open source frameworks come from different models: passion projects versus corporate-driven tools. - These models produce fundamentally different software with distinct motivations and goals. Transcript: Richard Littauer It's a protocol. Can you tell me about whether you see one of those being more important than the other or does that match your understanding of how open source works? Alexander Petros Yes. And my interest in protocols is even more than I've talked about publicly because I'm working on activity pub stuff on my free time too. I think that's very interesting. There's two things going on with open source. I actually don't typically think about open source this way, but it's definitely true, which is that why does Facebook open source react? To be honest, I don't fully know, but I think it has something to do with what you're describing, which is it benefits them to have a bunch of people dependent on software that they control And can get out freely and share with people. The ecosystem is valuable and they need it anyway. So they might as well benefit from that in some way. That is very different from where something like HTMX comes from and where there are open source software projects that are passion projects, and maybe they succeed to the extent that They become sustained projects via donations, via sponsors, maybe a business model where they host, what have you. And then there are open source projects that are like, we're a big company. We made a thing. You can have it if you want. And by the way, we have tools that you're going to need if you want this to work for you. Those are both open source, but they're very, very different models and they produce very, very different software. ([Time 0:22:40](https://share.snipd.com/snip/36875ec7-6b7c-4528-8292-c5b4c9f71e4d)) - **Balancing Passion and Funding** - Alexander funds his open source work via freelancing but is seeking a salaried role. - Passion projects often don't pay enough to sustain long-term development alone. Transcript: Alexander Petros For all this work? I'm not. Just straight up, I do it because I want to do it. Passion projects are the best. There would be more that I could do if there was a way to make money from it. But as a freelance software engineer, kind of the bet I made by going freelance was that I could take the efficiencies that I had discovered via HTMX, and I could take a little bit of my Work from that project and make websites for people in a way that was cost effective and thereby make money. And that worked sort of for a little while, but I got tired of it and I am in the process of taking a job. So I don't think that the passion project, we're making good software because we want to advance the industry in some way. I don't want to be negative, but I don't really think that super works. Carson, the creator is a professor and he has a job and he used to work in the industry. I mean, they're just, that's part of why talking about open source is one concept. It's a little misleading because there are two, if not many more kinds of things that could be happening when you talk about open source. ([Time 0:24:40](https://share.snipd.com/snip/b6fae0f7-fe25-40ef-8c87-b5db8f4f683e)) - **Challenges in Web Standards Work** - Web standards development is dominated by large companies, making volunteer contributions challenging. - This system can be frustrating and lacks sufficient public funding and stakeholder balance. Transcript: Alexander Petros And also going a little insane. Sometimes I tell people that capitalism is very clarifying. And that's a value-neutral statement. But within a business, there is a very clear hierarchy. There's a very clear set of incentives and there are clear decision makers. And outside of the business, as the business interacts with other businesses, there's a clear structure by which decisions get made in those interactions. And what protocols and standards, because they have so many volunteers and they are trying to contribute to something that is maintained by companies. I mean, we don't need to be coy about it. The browsers and the HTML standards are the biggest companies in the world. So you have a system where volunteers say, this is what I think is the right thing to do. And they get frustrated because they either run out of time or they run out of energy or there just isn't interest or there, and it feels unfair. And I don't think that is the fault of standards people. It's not the fault of the browsers. It's just a system that is frustrating. And until the U S government jumps in and says, we're going to fund a web standard browser or the European union says it's important to us to be able to be stakeholders in the html conversation We're going to devote 500 million dollars a year to making a competitive web browser then the resources to do that well comes from companies and companies have their own incentives And that just is what it is so it's a very frustrating process if you don't come at it from the right perspective. ([Time 0:26:24](https://share.snipd.com/snip/1f6c3d4d-c38f-4d30-a1ef-d2e693ed4dbd)) - **HTML's Future in Information Sharing** - HTML's many-to-many communication paradigm remains unmatched for global information sharing. - No foreseeable replacement matches HTML's scale and adaptability for the next century. Transcript: Richard Littauer I'm just curious, have you thought about the 1,000 year approach to the work that you're doing? 100 years is enough, I think. Alexander Petros Yeah, I think that's sufficiently ambitious. Earlier on, we talked about how there's this idea that everything is always changing and we live in the most changing time of all times. And there are ways in which that is obviously true, but I don't think that means that we can't plan for anything in the long run. There were movies a hundred years ago and there's movies now and the movies look a little different, but that's a thing we still do. And at a high level, it used to be that if you wanted to talk to a lot of people, you had to write a book or a pamphlet. So in 1500 or so, they found a way to make it really easy to make pamphlets and news. And then we had kind of a new form of mass media. And then it got even easier with the radio and television. And we were able to reach kind of a one-to or few-to relationship with media that persisted for a little while until the internet came along. And now we have a many-to relationship where anybody can talk to anybody basically at scale. And I don't really know from an information standpoint, what could come after that? I'm sure something, something I can't envision. Maybe we're just beaming our thoughts to each other all the time. And that's a degree of simultaneity and openness that's unimaginable to us now. But if we're going to be creating things that anybody might read around the globe, I think that that's a paradigm that's just going to exist for a while. And I don't see anything on the horizon like HTML that can do that many to many or like websites really that deliver behavior and data as cost efficiently as HTML does. Totally possible something comes along, but I'm just looking at the horizon and I'm not seeing it. ([Time 0:28:22](https://share.snipd.com/snip/3660b8e4-ab96-4665-9f0b-85eb95b28abe)) - **Protocols Need Viable Business Models** - Protocols must align with viable business models to sustain usage. - HTML currently lacks financial incentives, limiting broader adoption and innovation. Transcript: Alexander Petros I don't disagree. You talked about protocols earlier. I know you're half kidding. I was joking. But I want to take that joke and I super agree with the joke, which is that business models and protocols interact in an interesting way. And it's interesting that we used to use RSS for all sorts of things, right? We used to use RSS to share. You could subscribe to newspapers, you subscribe to blogs, audio, what have you. And now a lot of people think RSS is dead, but it's not dead. It's podcasting. And that's because podcasts were able to find an economy of scale that worked for them, that made money, that used RSS and the many attempts to enclose the podcasting ecosystem in a proprietary Format. You publish a podcast, I don't. I know it's sort of annoying to publish to all the places, but it's still kind of RSS and you can follow with RSS and it's open that when you have a direct relationship with your listeners. And that's because podcasting as a concept found a business model where RSS worked. And that's better for everybody involved if you can make that work. It turns out it doesn't work for text. So when we talk about protocols, we have to think about what kind of business model shopping works on HTML. Why would you have a store on HTML versus a store in an app? Well, because no one will take 30% of your profits. So there are businesses that work on protocols. And if you can make those protocols useful enough that they make money, people will stay on them because they like having that direct relationship. So as a frame of mind for thinking about how to make protocols more useful, how to make the internet more open, how to give people more control, think about how to make it worth somebody's Time. And right now, HTML in many respects, doesn't do that. I like blogging because I love writing, but it doesn't make me any money. If it did, then it would be worth more people's time. More people ([Time 0:30:21](https://share.snipd.com/snip/e4f21122-7834-4990-98e6-93c70eeab038)) - **Better SQLite3 Unlocks Simplicity** - Better SQLite3 is a fast, synchronous Node.js library that reshaped Alexander's database understanding. - It helped him realize simpler, durable paradigms for server-backed websites. Transcript: Alexander Petros Am a huge fan of a Node.js library called Better SQLite 3. It's by a fellow named Joshua Wise. And this library, I think, gets the interface for building a database from Node.js perfectly. It's synchronous, it's super fast, it's got a great API. And SQLite is one of the things that unlocked my understanding of what would be a better, simpler, more durable paradigm for making websites that have a database backing. And BetterSQL Lite 3 in particular is an interface for Node that helped me understand, here's the way that this should connect to the server logic. So it's totally free. There's a Patreon for sponsorship, and I would definitely check that out. Really unlocked something for me, and it's a great library. So shout out to Joshua Wise. ([Time 0:34:09](https://share.snipd.com/snip/23dc1463-aff9-47e9-8c01-a1ed1e3e5cad))