HTMX + Go Is All You Need (Next.js Is Overkill)

[00:00:00]Most web applications are pretty simple under the hood.

[00:00:02]Several forms, a table, and several buttons that access the database. To render all of this, the standard stack first loads the entire React runtime and JavaScript bundler, then hundreds of npm packages, a build step, and a hydration pass to show you a list of strings. One real company looked through all this crap and did something most teams only joke about. They removed React. Their code base was reduced by 67%. And somehow the app came out faster than before.

[00:00:31]It was replaced by a 14- kilobyte library called htmx, which runs on a simple Go server. No packager, no node modules folder.

[00:00:40]A single compiled binary that sends the finished HTML directly over the wire. So, here's the statement I really want to test with you today. For about 90% of the applications we build, Next.js is redundant. Not wrong, just unnecessary.

[00:00:54]Like renting a construction crane to hang one picture frame.

[00:00:57]Let me show you why, with real numbers from a company that actually made the leap. Start with what these apps actually are. You log in, see the list, click a button, the row changes in the database, and the page shows the new state. This cycle is the entire product.

[00:01:12]To be clear, React has earned its place. It was built for truly complex interfaces. And for them, he is wonderful.

[00:01:18]The problem is that somewhere along the way it became the default file for everything, including the settings page with four fields and a save button. So what exactly is htmx? This is a single JavaScript file of about 14 kilobytes in size, added with zero dependencies. It has been stable in version 2 since 2024 and has about 48,000 stars on GitHub. This is not a shiny new framework. This is boring, finished technology at its best, and the idea behind it is old.

[00:01:48]Finally done right. HTMX grew out of a library called intercooler-jez, written over a decade ago by a developer named Carson Gross. The whole philosophy is to extend plain HTML with the capabilities it has always lacked, instead of replacing it with JavaScript. That's how simple it is in practice. You take regular HTML and add a few attributes that allow any element to make an HTTP request on its own. A button, a form, a link, a regular div, any of them. You write htx get for a button or hx post for a form and point to a URL on your server. When the user clicks, htmx runs this request in the background and the browser never performs an abrupt full page reload. Here is the entire function in one line. For the like button, you write hx post, which points to /like, and hx target, which points to the counter.

[00:02:39]The user clicks on your Go server, returns a new counter in HTML, and HTMX places it in place. No fetch call, no state interception, no re- rendering. Now here's the part that changes your entire stack. The server does not respond with a JSON data block. It corresponds to a small piece of already rendered HTML, a ready-made fragment of the page. HTMX takes this snippet and inserts it into the page, exactly where you told it to. No client-side rendering, no rehydration, no second copy of your app's state sitting in the browser and losing sync with the server. And it's not limited to replacing one field. A single response can update multiple parts of the page at the same time.

[00:03:19]Cart total, product list, and a small notification—all from a single request. This covers a surprising amount of what we typically handle through React. Place the two processing loops side by side, because that's really the whole argument, the React way.

[00:03:32]The browser requests JSON, the server sends the raw data, and then the browser performs a second task, converting that data into HTML that a human can actually see. You have created a screen twice in two different languages. The HTMX method simply removes this second task. The server sends ready-made HTML, and the browser displays it. You render the screen once on the server in whatever language you've already written, and the browser becomes a browser again.

[00:03:57]You also get back a few things that the heavy stack took away. This server-side HTML rendering works before any JavaScript is loaded, which is better for slow phones, weak connections, and search engines that want to read your page. And this single change eliminates an entire category of work.

[00:04:13]There is no JSON API for design and versioning. There is no client storage for synchronization.

[00:04:18]No megabytes of JavaScript to package, ship, and debug at 2am. Now HTMX needs a server that can generate HTML quickly. And that's exactly where Go fits like a glove. You compile a Go program into a single static binary file. There is no runtime to install on the server, no interpreter, no dependencies folder. You copy one file to your machine and run it, and go already supplies everything that stack needs in its standard library. The net/ http package is a true production- grade web server. The html/template package renders your pages and automatically shields them from injection attacks.

[00:04:54]You can put all of this together without using any framework. And imagine what the deployment will be like. With a heavy stack, you install node, rebuild the lock file of hundreds of packages, run a build, and hope the versions match. With this you compile one binary file and copy it. It behaves the same on every machine because it doesn't contain anything external.

[00:05:14]There is also the part that Go is famous for – Go procedures. A single Go server can support tens of thousands of simultaneous connections on conventional hardware, as each one requires a few kilobytes of memory instead of a full operating system thread.

[00:05:27]It stays fast under load without much thought on your part. And this efficiency is reflected in the bill. A compiled Go binary runs in idle mode with a few megabytes of memory. So a small, cheap server that would struggle to be overloaded with a heavy node stack can comfortably run the Go version.

[00:05:42]Fewer machines, smaller instances, lighter hosting line each month. So the entire architecture fits into one sentence. Go renders HTML. HTMX replaces it with a page. That's the whole point. Two moving parts, and you can hold them both in your head at the same time.

[00:05:58]None of this matters if it only works on weekends in the task demonstration. So, here are the results of a real production business. A French SAS company called Context took their entire React frontend and ported it to HTMX, and their engineers stood up at a conference and read out all the numbers afterwards. Start with a headline they weren't expecting.

[00:06:17]Their frontend has shrunk from about 21,500 lines of code to 7,200. That’s a 67% reduction. 2/3 of the frontend code simply disappeared.

[00:06:27]The number of dependencies is the part that made me smile.

[00:06:31]They reduced JavaScript dependencies from 255 to 9.

[00:06:33]That's an entire MPM supply chain that you no longer have to test, patch, or worry about breaking on some random Tuesday morning. And speed manifested itself where you feel it every day.

[00:06:45]Their web creation time was reduced from 40 seconds to five. And first page load time, the time it takes your users to rate you without even saying a word, has dropped from 2 to 6 seconds, down to 1:2.

[00:06:56]Even the browser itself has become lighter.

[00:06:58]Memory usage per page went down from about 75 megabytes to 45 because there was no longer a heavy client framework sitting in each open tab with its own full copy of the application. But I promised receipts, not a promotional offer. So, here's the score. Their Python backend grew from about 500 lines to 200 as rendering work moved back to the server. The complexity did not disappear without a trace.

[00:07:22]She moved to a place where it was much easier for their team to reason. Now, I can already hear your objection. What about rich interactivity?

[00:07:30]Fair question, but HTMX encompasses a lot more than people think.

[00:07:35]Inline editing, real-time search with filtering as you type, infinite scrolling, instant form validation - none of this requires you to write your own API by hand, where it really ends is the other 10%. A design canvas like Figma, a document editor like Google Docs, a spreadsheet, an interactive map, a game, anything where the browser is a living application, not a stack of pages.

[00:07:57]The transmission to the server with each keystroke is too slow. So this job really needs React, and it makes every kilobyte count. So honest framing was never a confrontation between HTML and React. This is the coordination of the tool with the application form, the dashboard, the store, the internal tool that sits above the database.

[00:08:15]Send HTML from a Go binary, real- time collaboration. Reach for a heavy framework intentionally because you really need it. And this is not a fragile experiment that you will have to rewrite next year. HTMX has been stable for many years. Version 4 is already in development, and the lack of dependencies without having to update every 6 weeks is a real advantage, not a weakness. So, here is the straight answer the title gives you. For most of what we build, forms, tables, buttons over a database, HTML over the wires, served by a Go binary, that's really all you need. 14 kilobytes, one language, one small process for deployment. A heavy stack is a real tool for solving a real problem. It's just needed much less often than the default settings suggest. So before you install 200 packages for table visualization, stop and ask one honest question.

[00:09:07]Is this program really a document, or is it a living canvas?

[00:09:10]Answer directly, and for the most part, the boring stack wins with less code, fewer bugs, and a lower hosting bill. These are cloud codes and I will continue to offer them to you.