When I decided to rebuild my portfolio, I knew I wanted to avoid the traditional single-page application (SPA) route. If you are curious about the overarching stack choices behind that decision, you can check out my post on Why I Chose Go + HTMX + SQLite Instead of React for My Portfolio. But a major part of that architectural shift came down to frontend philosophy.
Touch on the modern reality of frontend development. To build a simple dynamic button or form submission, developers are expected to spin up a Node.js ecosystem, configure bundlers, manage thousands of npm dependencies, and ship hundreds of kilobytes of JavaScript just to render text on a screen.
It feels like we've over-engineered the web. Here is why I ditched the heavy JS frameworks for HTMX, and how it completely changed the way I build web apps.
The SPA Hangover
For years, the default answer to "making a website dynamic" has been reaching for React, Vue, or Svelte. Want to handle a form submission without a full-page reload? Spin up a component. Want client-side routing? Install a router. Before you know it, your simple portfolio has a 500MB node_modules folder, a complex build pipeline, and a bundle size large enough to download a lightweight operating system.
We turned document-based hypertext into native-app emulators. For a massive, deeply interactive canvas application like Figma, that complexity is justified. For a portfolio, a blog, a CRM, or an internal dashboard? It's an administrative nightmare.
How HTMX Reverses the Architecture
HTMX takes a radically different approach by completing HTML as a hypertext. Instead of building a decoupled JSON API and writing client-side code to parse that JSON into DOM nodes, your server simply returns small HTML fragments.
You augment your standard, semantic HTML with a few hypermedia attributes:
<button hx-post="/projects/like" hx-target="#like-count" hx-swap="outerHTML">
Like Project
</button>
With just those attributes, HTMX intercepts the click, makes an AJAX request, expects HTML back, and swaps it directly into the DOM element with the ID #like-count. No manual JSON mapping, no virtual DOM diffing, and zero build step required.
Real-World Wins in the Portfolio Workspace Switching to HTMX paired with my Go backend brought several immediate advantages to my development workflow:
Zero Build Pipelines: There is no Webpack, Vite, or Babel to configure. I drop a single script tag for HTMX into the header of my Go templates, and I'm done.
Blazing Fast Performance: Because my application's state is queried directly from the database (which you can read more about in Yes, SQLite Can Go to Production), handing HTML templates straight back to the browser means instant rendering times and tiny payloads.
True State Management Simplicity: State lives on the server, right alongside the database. I don't have to manage complex client-side stores, synchronization bugs, or cache invalidation strategies.
Where HTMX Isn't a Silver Bullet
To keep things grounded, HTMX isn't the right tool for every single scenario on the web.
If you are building an application that requires heavy offline capabilities, complex continuous animations, or intense real-time client-side data processing (like a browser-based code editor or a collaborative design tool), a heavy client-side framework still holds the crown.
However, for 90% of the web applications developers build—CRUD apps, SaaS tools, dashboards, content sites, and portfolios—HTMX handles the interactivity effortlessly while keeping your codebase lean and maintainable.
Summary
Moving away from JavaScript bloatware gave me back the joy of building for the web. By letting HTML do what it was originally designed to do, my portfolio stays fast, lightweight, and incredibly easy to maintain. If you haven't given hypermedia-driven development a spin yet, try building your next side project without an npm install—you might be surprised at how freeing it feels.