Why you should choose HTMX for your next web-based side project - and ditch the crufty MPA and complex SPA

Date: 2024-02-23 | create | tech | htmx | mpa | spa | hamstack |

I build a lot of side projects so I'm always on the lookout for technologies and paradigms that allow me to build them faster and cheaper at a similar quality. For the last several months I've been experimenting with building web apps with low-js tools like HTMX and Alpine.

In this post I'll share why I think HTMX is a great choice for building web apps faster and cheaper and why it's now a core part of my tech stack - The HAM Stack.

MPA vs SPA

MPA vs SPA

Multi-Page Apps (MPA)

In the beginning we had Multi-Page Apps (MPA).

  • Each URL goes to a web page
  • This web-page is rendered server-side and sent back to the user
  • If you need to update something on the page (because a user changes something or it needs to refresh) then the full page needs to reload

This works fine but it gives a very slow / clunky feel because you need to reload EVERYTHING any time one thing on the page changes. For an example of this - think of a State government website, most of those are still old-school MPAs and they feel old and clunky compared to most modern apps.

MPA Pros and Cons

  • Pros: Simple to build
  • Cons: Feels slow and clunky due to refreshes

Single-Page Apps (SPA)

To solve this, Single-Page Apps (SPA) were created.

  • A URL loads a large JS payload containing a bunch of app logic
  • This JS takes over page rendering
  • It uses internal state to determine what the page should look like and does data transfers behind the scenes so it only needs to update the parts of the page that need to change

This feels better to the user because changes feel faster. The page only updates where it needs to and we don't need a full page refresh to change data. Most apps / websites today feel like this because it generally provides a better user experience.

  • Pros: Rich "modern" user experiences
  • Cons: Complex at scale - dealing w data transfers (graphQL was built for this), abstractions, and app logic payload sizes

So in general:

  • Multi-Page Apps (MPA) - Simple to build but hard to get rich "modern" user experiences
  • Single-Page Apps (SPA) - Complex to build but can achieve rich "modern" user experiences

MPA vs HTMX vs SPA

MPA vs HTMX vs SPA

Image inspiration from u/Abhilash26 on r/htmx.

HTMX has been around for several years but has really gained mass hype in the past year or so. The hype is not unfounded - it often allows you to build modern web apps faster and cheaper than a SPA.

HTMX essentially extends HTML so that it can do partial page reloads.

  • Any element can specify how it can retrieve up-to-date data and when it should do that
  • The element can then specify what to do with the new data - replacing itself or other elements on the page

If we look back at the MPA vs SPA comparison, we can see that the lack of partial page reloads is really the main thing holding MPAs back. So adding this capability into an MPA largely allows you to get most of the rich "modern" user experiences of a SPA with the complexity level of an MPA.

HTMX for Side Projects

The goal of a side project is often just to build the thing. You likely don't have a team of engineers or warchest of VC-money to do so - it's just you and your computer.

So lowering the cost of building - in time and money - is crucial to making a side project successful.

From my perspective, HTMX provides a great balance between allowing you to build modern apps with very low complexity (and thus time and money cost). Thus it's become a core part of my tech stack - the HAM Stack.

Next

If you liked this post you might also like:

Want more like this?

The best / easiest way to support my work is by subscribing for future updates and sharing with your network.