How HTMX allows you to build modern web apps faster and cheaper than bloated client-side SPAs

In this video we explore how HTMX enables modern app development simpler, faster, and cheaper than the popular SPA frameworks like React, NextJS, and SvelteKit

Chapters

03:05 - Most apps are simple CRUD
06:15 - Modern apps are just sites that feel fast
12:15 - HTMX allows partial page reloads, making apps feel modern

Links:

About me: I'm Hamilton - a Technomancer. I build Simple Scalable Systems to make the world 1% better.

Connect with me:

# Support

Supporters get:
* Full source code access from courses / tutorials
* Exclusive discounts on products / courses

Plus you help me to keep experimenting / sharing!

[carlosluisquesada]

Great! Now let’s solve state management for micro interactions server-side in a way that scales.

[arimill]

Don't forget the creator of htmx has stated you don't axe all JavaScript from your site. It's intentional to keep JavaScript to its original domain space - dynamic front end stuff like click and drag etc...

[viktorasmickunas]

CRUD apps usually use grids. For that you still probably need some UI framework component. Is it easy to hook a Javascript UI library to HTMX?

[Schmarter]

Looks interesting for apps that don't need any offline mode.

[sadiulhakim]

The main problem i face with HTMX is it accepts HTML as api call respose. Suppose i return a list of posts from backend and there is a button on each post. When i click on that button it sends a get request to the server with the post id. How do you do that in HTMX?

[ankitpradhan]

`Most apps are simple CRUD`. Well yeah, frameworks were not built for 90% of stufs on the apps, but for the 10% which was the pain in the ass.
`Most apps are just sites which feels fast` That is what user needs most of the time,
`Large initial SPA payloads?` then you are a newbie trying to learn the frameworks, You never load all your bundle at once, Well thats even true for vanilla level
`Complicated state management` Well if you make it complicated then YES,
`More bugs?` duh, it will be buggy no matter what you use
`Large data flow surface area to maintain / process` YES the 10% of headache which will occur no matter what you use,

`Without any baggage SPAs bring`, But it does bring its own baggage, doesn't it?

[paulholsters]

Most apps are simple crud? That I doubt. A lot of business webapplications are very complex crud, with a lot of business concepts and business logics involved. I agree it is for those type of applications we need these SPA frameworks, but for simple websites with little to no crud operations they are indeed overkill. Especially if you don’t want to use a UI library. But yes in a way they all are about CRUD. And just display data seems a little oversimplifying things here. A lot of the heavy lifting is done by specialized UI components. But htmx for sure is great!

[laztheripper]

I *could* send a small json payload to the client and let it update the 10 or so spans worth of html by itself, but why not have the server do the extra work for no reason, and then replace half the page's html because the bit of data affected most of the elements on screen, right? Oh and, there goes all of your event listeners and state, oops.
htmx works if you have a REALLY basic app that can afford replacing homogeneous sections of the markup at once, but most sites don't, and they certainly don't need to push that work to the server, where you have to pay the cpu and memory costs instead of the client.
Now imagine what happens if you compose your requests and responses so that you aren't making as many requests, yeah, smart. But then you can't cache that return because 2-3% of the data used while rendering it is user specific.
There's a cost benefit calculation you have to make for yourself any time you pick a technology, and htmx has (many) costs.