Hypermedia at Scale with Carson Gross

🎧 New Señors @ Scale Episode

This week, I spoke with Carson Gross, creator of HTMX and principal at Big Sky Software, the LLC he runs his open source work and consulting through. Carson has been programming for more than 30 years.

He started in HyperTalk on a family Mac, dropped out of computer science at Berkeley, got a job writing Excel for an industrial engineering company, worked on a JVM language called Gosu, ran a Rails startup, and built Intercooler.js in 2012 because he refused to use Angular 1 to put a form into a database. When COVID hit he moved from California to Montana, and he now teaches computer science at Montana State University, where he runs the systems, databases, software engineering and compilers classes.

In this episode, we dig into whether you need a JavaScript framework at all, why a link is already a small programming language, how REST came to mean the opposite of what Roy Fielding wrote, what changed in HTMX 4 and why there was never a version 3, and why his exams are now written in pencil.

⚙️ Main Takeaways

1. Intercooler started as a refusal to use Angular 1 for a form

• The moment: He had a Rails startup in 2012, Angular 1 was the hot thing, and he looked at what it took to get data from a form into a database. "No way, no way, no way am I doing all this to get a form into a database."
• What he kept from Angular: Putting behaviour in attributes on the element. jQuery's approach, with scripts in one file and CSS selectors hooking behaviour into markup somewhere else, meant "you never knew what the hell a button did."
• The method he found by accident: jQuery had a function that took a URL and an element, issued a GET, and put the response in that element. "We're allowed to do that. We're allowed to use Ajax to issue a request, and it doesn't have to be JSON or XML."
• What Intercooler was: Attributes in the HTML, an Ajax request, HTML back instead of data, inserted straight into the DOM. That combination fixed a performance problem at the startup.

2. HTMX is Intercooler rewritten without jQuery, to stay sane in lockdown

• Intercooler's reach: He open sourced it and got around 5,000 GitHub stars, "which was a big deal at the time."
• What COVID changed: "In order to avoid going insane," he took Intercooler, which sat on jQuery, and rewrote it in plain JavaScript because browsers had standardised since 2010. That rewrite is HTMX.
• How stable it has been since: "It is Intercooler with slightly different attributes."
• The second thing that happened: He took a teaching job and moved from California to Montana, releasing the first version right before the move.

3. Hypermedia is links and forms, and they are control logic inside your document

For people who have only built SPAs, this is how he explains it. He starts from the two controls every browser already has.

• The definition: "The web is built as a hypermedia system. That's what the web was built on." Links and forms are hypermedia controls.
• Why a link counts as code: "A link is a little programming language that says when a user clicks on this, issue a network request and take the response and load it into the client." One string with a relative URL drives all of it.
• Forms go further: They mix network programming with paragraphs and images in the same markup. "It's a markup language, but it's definitely mixing control information with content."
• Separation of concerns, rejected: Splitting logic into a JavaScript file has bothered him since the jQuery days. "Hypermedia is explicitly not separating concerns." His answer to people who want it separated: "We've had logic in our web pages forever. That's what a link is."
• Ted Nelson's version: The man who coined the term defined hypermedia as media complicated enough that you need a computer to consume it. Carson's working definition is content plus networked control information in one document.

4. Many sites do not need HTMX either

A strand of the HTMX community argues for less than HTMX, and Carson agrees with it.

• Who makes this case: Alex Petros, on the HTMX core team, argues that government websites should use the hypermedia model with as little on top of the platform as possible. "Don't get fancy, don't get crazy, use the web the way it was designed to be used."
• Why permanence matters there: Build on links and forms and "you're building a more permanent web presence." "There's not gonna be a web ten or whatever. The web is what it is, it works the way it works."
• The upgrade train: Frameworks put you on a track where features break and get replaced, which the core web APIs have not done since they shipped.
• His book opens the same way: The first real chapter of Hypermedia Systems builds a web 1.0 app with no HTMX at all, so you see what the web was designed to do before you see what HTMX fixes.
• On younger developers: "Links and forms are pretty pedestrian. A lot of young web developers don't even understand them very well, unfortunately."

5. REST came to mean the opposite of REST

I asked why everyone builds RESTful interactions, and he corrected the premise before answering.

• The correction: "First of all, I'm going to correct you. They're not REST. It's not real REST." What most of us mean by REST is JSON APIs behind a React frontend.
• Where the term comes from: Chapter five of Roy Fielding's dissertation, describing the network architecture of the web Fielding had helped build while working on Apache. It is a hard read and he never expected the term to travel.
• The constraints: REST, short for representational state transfer, is a set of constraints a distributed system has to satisfy. One of them is that you have to use hypermedia.
• Why JSON fails it: "JSON is not a hypermedia. JSON is data. And so JSON APIs almost can't be RESTful." People have tried to turn JSON into a hypermedia, and none of it stuck.
• How the drift happened: The word detached from the constraints. "It turned into this general term for good. And so whatever's good is RESTful."
• The vocabulary he wants: "I would prefer the term JSON APIs to RESTful APIs." The gory details are in his essay How Did REST Come to Mean the Opposite of REST.

6. The industry left hypermedia because the web was clunky

As Carson tells it, links and forms never gave people a great experience.

• What people wanted: Highly dynamic interaction with a server, and links and forms could not give it. Full page refreshes reset your scroll state, and pages used to flash white while images filled in.
• The tool on the side: Ajax, then fetch, let you pull JSON and "start doing crazy stuff."
• What that turned the browser into: "Now we use the browser often as more of an application platform rather than as a hypermedia client."
• Where HTMX stands: "HTMX wants to go back the other way and say, look, let's try and use it more like a hypermedia client."
• The flexibility he wants credit for: Tell someone in 1985 that by 1995 "they would be using the same application to access their bank and their kids' grades and their online shopping," and they could not have conceived of it.

7. HTMX generalises the link and the form

• The generalisation: A link means an action issues an HTTP request, gets HTML back, and places it in the viewport. HTMX gives you attributes to control which event triggers the request and which element gets the response, with no full page refresh.
• The precedent in plain HTML: iframes. You can target an iframe from a link and load a new document into it, "but it's pretty clunky, like a lot of things in the web infrastructure."
• What becomes easy: Active search that filters as you type, and infinite scroll, "which my understanding is going to be outlawed and it probably should be." The examples page at htmx.org/examples shows the patterns.
• The claim: Patterns people associate with React-style applications "suddenly become doable using the hypermedia approach instead."

8. Which apps HTMX is a bad fit for

Latency and local data are where he draws the line.

• The rule: "I wouldn't try to build a 3D game in it. Although people have."
• The reason: Interactions that need low latency and local data to feel right are "not something that hypermedia is set up for."
• How much of the web that covers: "The vast majority of web apps are not like that." He uses a lot of React apps and thinks most of them could be far simpler.
• The example that annoys him: Proton Mail's web client, where "stuff doesn't work." His view: "An online email client could be done in hypermedia so well."
• Doom: Someone at Big Sky DevCon, the local conference, built it with CSS and HTMX. "It's doable. It wouldn't be my recommended."

9. HTMX has no opinion about your backend

Carson spends part of this answer talking people out of HTMX, because sometimes plain HTML wins.

• The React contrast: React is tied closely to Node and JavaScript backends. HTMX is not. "We're not gonna fight about what the best programming language is. If you like Rust, cool. If you like Zig, also cool." Perl and Ruby get the same answer.
• Alternatives: "There's lots of good alternatives to HTMX now."
• View transitions: Browsers can animate between full page navigations today. "If all you want is nice looking navigations, you don't need HTMX for that, so don't use it."

10. Why there was never an HTMX 3

He kept the no-version-3 promise on a technicality.

• The promise: "I had said there would never be a version 3 of HTMX," because the library had been stable for so long.
• What changed his mind: He wrote fixi, a minimalist library on fetch, "90 lines of code that gives you 87.5% of HTMX or whatever," with nothing built in beyond the core and scripting for the rest.
• What fixi taught him: The JavaScript async model. "Try catch makes a lot more sense. I'm a Java guy, so I can understand this." Rebuilding HTMX's internals on fetch would make it easier to maintain.
• Why it stayed on XHR: HTMX 1 supported old Internet Explorer, which had no fetch. And XHR has upload progress events that fetch, the last time he looked, does not. "XHR has functionality that fetch does not, believe it or not."
• The email that restarted it: A kid emailed asking to work on HTMX with him. "This has felt like my whole life, a random lightning strike comes in and it's like, okay, I guess that's what we're doing now."
• The loophole: "There won't be an HTMX 3, but we can have an HTMX 4."

11. What is different in HTMX 4

The API is nearly identical to version 2. Most changes are internal; attribute inheritance is the one you will notice.

• Explicit inheritance: In HTMX 2, an attribute on a parent applies to every child, so one hx-target on a wrapper covers three buttons. He copied that from CSS. In HTMX 4 you add :inherited to an attribute to opt in.
• Why he reversed it: "Attributes that are far away can affect the behavior of other attributes," especially once templates get included from other files. Explicit inheritance makes it "visually obvious" when you read a codebase.
• History restoration: The back button is built into HTMX, and the way pages get restored is simpler now, which makes third party JavaScript conflicts less likely.
• Event names: Names that had drifted across several conventions over the years now follow one.
• The goal: "This thing is going to be maintainable and it makes sense and you can reason about it for the next fifty years or whatever."
• The licence: BSD Zero, "so it's basically public domain," which is why he says users rather than customers.

12. He expects AI to shrink HTMX's audience

• What he expects: "I think AI is gonna be very hard on HTMX." He has seen AI recommend HTMX to people, and he has watched community members leave.
• The reason people leave: One told him, "I don't use HTMX anymore. I use React because the training set on it is so big." Carson's reaction: "I get it, totally."
• React's advantage here: A huge ecosystem, shadcn and the rest, that makes a UI look good fast.
• His position: If vibe coding is how things get done, "HTMX is probably a little bit more of a niche technology, but that's okay. I'm fine with that. I don't make any money on it."
• What he wants taught anyway: "Kids should learn how traditional web apps worked, even if they don't build them anymore." His comparison is the internal combustion engine: you may never buy one, and it is useful to know how it works.

13. Drive the AI yourself

Carson uses AI to write code, and this is how he thinks it should be used.

• The failure mode: People treat the model like a report. "You should be driving the AI rather than being a manager, like a technical manager."
• What he asks of you: Review the code. "For the most part, you should be writing the code in a lot of cases. And certainly understanding it."
• What he has seen go wrong: "Even good models will make bad architectural decisions to take shortcuts, and things can spiral pretty quickly if you're not on it."
• The rule he applies to himself: He has to know how things work under the covers, because he treats that as the engineer's job.

14. Pencil and paper exams with one handwritten page

I did not expect this from the creator of a JavaScript library.

• The problem: "Any AI worth its salt can solve most undergraduate computer programming problems." So homework no longer tells him anything about what a student can do.
• How homework was graded: It made up 60 to 70 percent of the grade, because he wanted students writing code. "My assignments are no longer worth much." He keeps telling students to do them, because that is where you learn how programming works.
• The transition: Last year he moved grading to pencil and paper quizzes. Students come in without computers or phones. "If I see smart glasses, you're out."
• The notes rule: One page allowed, handwritten only, because a typed page would be AI generated. "The knowledge goes in through your eyes and out through your hands, and then in through your eyes and out through your hands again."
• How students took it: "They hated it at first, but by the end of both semesters last year, they admitted, I learned a lot more." Students with poor handwriting complained the loudest, and he sympathises because his is bad too.

15. Teach assembly on a 16-bit machine with a visual debugger

The systems class he teaches at Montana State runs on emulators he wrote. Students step through their assembly on them and see the whole machine state at once.

• Why 16 bits: 64 bits is too much data to see on a screen. "Sixteen, okay, it's four groups of four. There's a symmetry to it. I can see what's going on there."
• The two machines: MTMC, a 16-bit teaching computer at mtmc.cs.montana.edu, and an even simpler 8-bit one. Both use an x86-like assembly so the jump to real x86 is smooth.
• What the tooling shows: A step debugger with highlighting between C minus minus, a simplified C, the assembly it generates and the machine state, all in one view.
• His teaching philosophy: "A visual debugger is one of the most important teaching tools that I have available to me." Some people can close their eyes and picture registers and memory. "I certainly didn't."
• The Sussman anecdote: Gerald Sussman at MIT said in an interview that at some point in the 1990s computers became too complicated for him to understand and he no longer knew how to teach them. Carson's response: "If that guy can't teach it, what is the average person?"
• The aside on modern CPUs: "Assembly is a bad high level programming language at this point." The instructions you send are suggestions that get broken down and reoptimised.

16. Things are never as bad or as good as they seem

This was his closing advice, and he says he struggles to follow it.

• The rule: "Things are never as bad as they seem and things are never as good as they seem." In two weeks you will not care about either.
• For learners: He tells them not to use AI for the exercises and to figure out how to program, because computers are going to stay important. His essay Yes And on htmx.org goes deeper.
• On their circumstances: "You guys have been screwed to some extent." Property is expensive, US tuition is horrific and cannot be discharged in bankruptcy. The younger generation "is gonna have to be tougher in a way than my generation."
• On their chances: The good young programmers he sees are solid technically and have a better head on their shoulders than he had out of school. "That generation's gonna end up being a pretty special one because of it."
• Perspective: "Computers are still pretty cool. There's still a lot of cool stuff to be done. So don't let the negativity get you down."

🧠 What I Learned

• A link is already control logic in your document: one relative URL tells the client to issue a request on click and load the response. Hypermedia means mixing that control information with content on purpose.
• REST as Roy Fielding defined it requires hypermedia, and JSON is data, so most APIs we call RESTful are JSON APIs.
• The industry moved to JSON and JavaScript because full page refreshes reset scroll and flashed white, and Ajax gave a way around it. The browser became an application platform instead of a hypermedia client.
• HTMX generalises links and forms: any event can trigger a request and any element can receive the HTML response.
• HTMX is wrong for anything that needs low latency and local data, 3D games included; he thinks an email client is not one of those.
• Sometimes the right answer is plain HTML with view transitions, or links and forms with nothing on top, and the HTMX team will tell you so.
• HTMX 4 skipped 3 because of a public promise, moved its internals from XHR to fetch, and makes attribute inheritance opt-in with :inherited.
• XHR has upload progress events that fetch lacks, so HTMX kept XHR through version 2.
• The size of the React training set is why some people drop HTMX, and the creator accepts that it may get more niche.
• When homework stops showing mastery, he grades on pencil and paper exams with one handwritten page of notes, and keeps assigning the homework anyway.
• A 16-bit teaching machine with a visual step debugger makes assembly learnable because you can see all the state at once.
• Chesterton's fence: if you cannot explain why something is there, you are not in a position to remove it.

💬 Favorite Quotes

"No way, no way, no way am I doing all this to get a form into a database."
Carson Gross

"We've had logic in our web pages forever. That's what a link is."
Carson Gross

"JSON is not a hypermedia. JSON is data. And so JSON APIs almost can't be RESTful."
Carson Gross

"It turned into this general term for good. And so whatever's good is RESTful."
Carson Gross

"There won't be an HTMX 3, but we can have an HTMX 4."
Carson Gross

"If all you want is nice looking navigations, you don't need HTMX for that, so don't use it."
Carson Gross

"The knowledge goes in through your eyes and out through your hands, and then in through your eyes and out through your hands again."
Carson Gross

"Things are never as bad as they seem and things are never as good as they seem."
Carson Gross

🎯 Also in this Episode

• Learning BASIC on a neighbour's Apple II, then HyperCard and HyperTalk on the family Mac, "the internet before the internet" with cards instead of pages
• Dropping out of computer science at Berkeley after sitting down at a Sun workstation with a blank grey screen and a three-button mouse, finishing in industrial engineering, and becoming the department's guy who could program, in Excel
• Gosu, the JVM language he worked on after grad school, where he learned recursive descent parsing, and how Kotlin ended that era of JVM languages
• Lead Dino, the affiliate management startup for Shopify and BigCommerce he co-founded, six to eight people at its peak, sold after the co-founder dynamics went bad
• Big Sky Software's motto of doing the opposite of the industry, and his admission that he is "a contrarian to my detriment at times"
• Why he teaches databases as how to use them rather than how to implement them, and assigns Worse Is Better in his software engineering class
• His cat interrupting the recording
• Book picks: A Philosophy of Software Design by John Ousterhout, The Master and Margarita by Mikhail Bulgakov, The Brothers Karamazov by Dostoevsky, and anything by G. K. Chesterton
• Chesterton's fence, and the Grug Brained Developer site where he wrote it up

Resources

More from Carson:

• htmx.org: the library, the examples page and the essays
• Hypermedia Systems: his book, free to read online
• How Did REST Come to Mean the Opposite of REST: the essay behind takeaway 5
• Yes And, on htmx.org: his essay on what younger people should do if they want technical careers
• The Grug Brained Developer: his software engineering site, Chesterton's fence included
• fixi: the 90-line fetch-based library that led to HTMX 4
• Carson on GitHub
• MTMC at mtmc.cs.montana.edu: the 16-bit teaching computer from his systems class

Tools & concepts mentioned:

• Roy Fielding's dissertation, chapter five: where REST and its hypermedia constraint come from
• Ted Nelson: coined the term hypermedia
• Intercooler.js: the jQuery-based predecessor to HTMX
• Angular 1 and jQuery: the libraries Intercooler was built in reaction to
• XHR and fetch: the old and new request APIs, and the upload events only one of them has
• View transitions: the browser feature that makes plain page navigations look smooth
• HyperCard and HyperTalk: where he learned to program
• Gosu: the JVM language he worked on
• Alex Petros: HTMX core team, advocate for hypermedia government sites
• Big Sky DevCon: the Montana conference where someone ran Doom on CSS and HTMX
• Worse Is Better: the paper he assigns
• Chesterton's fence: do not remove it until you can say why it is there

Books mentioned:

• Hypermedia Systems: Carson's own book
• A Philosophy of Software Design by John Ousterhout
• The Master and Margarita by Mikhail Bulgakov
• The Brothers Karamazov by Fyodor Dostoevsky
• G. K. Chesterton's collected works

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 58 minutes on hypermedia as the web's native model, what REST meant before it meant everything, where HTMX fits and where it does not, the HTMX 4 changes, and teaching computer science when the homework can solve itself.

If you maintain a React app that could have been forms, or you are deciding what to teach a junior who has never sent a request without a framework, this one gives you the original design of the web and a line on when to use it.

Happy linking,
Dan