The Truth About HTMX | Prime Reacts 

I've been doing things the way HTMX does it for about 15 years now and have never touched react. Apparently tech is cyclical, and if you're a lazy boomer long enough you become the hipster.

as a dev in poland i can confirm that i am in poland and i sleep half the time

As a frontend developer, waiting for the backend team to make api changes is how I find time to watch these videos. Why change that?

"Let the man cook." Pauses every 15 seconds 😂

About the "nobody did single page apps before jquery" - Fun fact, I was writing arcade game clones, and single-page apps back with IE4 and NS4. I pulled data in using hidden s, and DHTML for animation. I wrote a bunch of games, Galaxians, Tempest (using VML), Frogger, Pacman, Pengo, Donkey Kong etc all using the original arcade graphics and running at full framerates :) I then got a cease and desist from Nintendo and had to take a bunch of my games down. This was over 20 years ago...

How does he manage to make a reaction to a 12 minute video last 50 minutes. Truly a talent many RU-vidrs would like to reach the 10min mark for multiple ads.

How does Prime fit 40hr/week at netflix, streaming for a ton of time, being a dad and going to the gym into his schedule?

This is a really profound video for me who's just new to these stuff. Really awesome!

There are quite a few points about the "backend defining the actions" or "it's already done on the backend so why reconstruct on the frontend" but the crux of this is poor contracts between front and backend. Almost all of my experience has involved multiple clients talking to a source of truth e.g. multiple native apps, machine to machine integrations, web apps and microfrontends. When you have to serve multiple clients the contract is the most important thing, not whether you use a backend first or frontend first framework.

One thing I like doing depending on what i'm building, is to build a backend in rust with axum and askama, then load htmx and twind from a cdn; that way you're basically guaranteed to never send more than around 20kb of js + css to the client, then all your ui is just declaratively embedded in your html template.

1000% agree with Prime's diagram around <a href="#" class="seekto" data-time="1860">31:00</a>. That's exactly it, the point I have been wasting time making on Reddit for years. Having a full client-side state based on JSON is unnecessary duplication of state.

This is my favorite reaction. Video of yours! You make your points eloquently, and with a modicum of screaming :-)

Im so glad I discovered HTMX on your channel. I never liked the complexity of frontend frameworks. Or why Frontend even requires so much work since logic and state should always be on the backend. I just want to display the stuff that is already there.

I once got asked in an interview "class components or hooks" I was like: "class components are more straight forward, useEffect and useState are bloating the code and make it harder to read". I started coding in React in 2016 and.. I did not get the job, I was still loving componentDidMount etc but understood what the market was after and the direction that react was going towards. I ended up loving hooks, but now I am doing Svelte.

I totally agree. Am willing to take a solid look at htmx and how it would fit into my little mindset

for me no other js library was exciting to me like JQuery of old it will always be my sweetheart she never complains about your setup never argue with you about your build preporcessor or packages. i curse the days i switched to React because it was "cool" and "new girl in the bloc" but now HTMX is like my mistresse reignited my love for simple CDN libraries that have the same montra "CODE LESS..... DO MORE"

Just my 2 cents, I think that while state management is a good concept, using a single word "state" to shoehorn every single value/variable/cache/element into a single concept and then trying to say general things about that (and only that) can also be counterproductive. In prime's example of the game of life, it might make sense to talk about the "client state" for things like what the currently alive cells are, while at the same time acknowledging that things like managing your "savegames" bring with them the challenges associated with managing such state for which ultimately the backend is the source of truth (assuming for the moment that thats where the "savegames" are stored). It would be counterproductive to either require all the state to be a reflection of what the backend knows, while at the same time it might overcomplicate design if what savegames the user sees in their "html" cannot simply be seen as a reflection of the data in the backend

We all know the proper way to synchronize state is call GET /entire-application-state every time a user interaction happens and also in a 50ms polling loop in three different places. Make sure you're calling this server side and on the client and hydrate redux with deep copies of the response so that spontaneous renders are constantly happening.

When he gave the example of todo on client state (optimistic update) which is actually sort of better with the use of react query in react but htmx seems really good to avoid duplicacy in the first place.

Personally I think the way that Phoenix liveview does things is the best way. It's a two-way binding between your elixir app and the so-called client which is effectively just a web socket. You actually don't even need any HTML in your project (outside of the root template). The state is maintained by the processes and elixir has some extremely powerful fault tolerant tools to keep things synchronized. As such you can just have a single process with the state and you can use the pub sub to proliferate the state out to the clients, It's inherently simple.

Wait a minute this looks like what I did (used to do?) with C# and XAML for UI. I always wished it was like that for the web too. Never got the hang of react. State management seemed so complicated and stressful. Nice, HTMX. Gonna check that out. I was actually floored with the other demo that you did a video on. The article loading thingy

You remind me of Uncle Reco. "If Falcor ever took off I'd have been someone!" "I bet that I could throw this API over those mountains."

I basically wrote a super simple version of that when I made a pretty bad web server framework in Rust. I really love htmx so far.

so, htmx is just lightweight good old frames. amazing innovation

this is my issue with React mainly too. I did a lot of es6, jquery etc, and dabbled in few frameworks a little bit. I've come to the field late, graduaded like not too long ago from uni. And looking at a lot of the web dev stuff, i feel there is a lot of dev glasses what i could say. I fully understand why React is used, since writing anything in plain JS/Jquery when it's complicated and animated interactable element can get painfull and hell to manage, but at the same time, i aggree fully with Prime, with that React abstracts soo much to the point where you start to think "React" instead of thinkg webdev. Another thing i feel is there is just this emotional burden that makes people feel certain tase on frameworks where despite very often them being good at the same things, they will tribal to gating something. I don't have strong attachements to it or Angular, but at the same time i don't understand the Angular hate since both generally feel "simmilair enough" to me(would probably feel the difference on something more complicated, not arguing there), and it's hard to not think, it;s the issue of if somethings a hammer, everything becomes a nail.

An htmx backend seems cool! Really snappy and intuitive for its purpose. But eventually in your business growth it is time to build a mobile app. With a backend spitting out html instead of data, how do you handle that with an iOS/Android/Cross platform app? I might not get the whole picture here, but it feels like kind of a technical lock in to build a backend that focuses on producing html documents like back in the days.

"HTML/Template and Go" at <a href="#" class="seekto" data-time="2952">49:12</a>, where should I be looking for templates (any site recommendations)? Also is go referencing the language or just getting started with HTML/Template?

OMG, how did I miss HTMX? Trend of near always connected will continue. Solutions over the past several years always felt like temporary fixes to me until offline is a thing of the past. Will have to try this. One of my old mentors told me when PHP vs ASP was a debate that we moved from thin clients + server -> move it all to desktop with thin server -> back to thin client, but now it's the browser and not the full system that's the "thin client". I feel like after he pointed that out that it's still playing out, just at a slower pace than we had figured.

What's good about React isn't React itself; it's the ecosystem around it. It's become very difficult to create modern UI components with accessibility without using something like RadixUI. Tailwind is creating Catalyst to compete and it's React-based. For example: a dropdown that responds to keyboard events and changes its orientation in case it's getting hidden. Good luck doing that with HTMX without a lot of custom JS.

I was doing htmx 10 years ago with my own attributes "my-post" "my-get" instead of "hx-post" "hx-get" and engineers were shouting bad practice 😃 Programming is just fashion.

are these (this and the last vod) reuploads? or did I just watch the live and forget?

In his story about music service, it sounds more like his company had especially bad team of backend devs, or their backend stack was bad for their use case. In no way a technology change can singlehandedly make one Theo backend dev replace 8 backend devs.

Love your version and a better explanation, business logic stays on the backend just use the front-end to display the actions in progress. Based on a high speed network it's great.

Absolutely, using React since 2013 is way different than using it since 2018. The shit the rest of us have had to go through. Dark times for the frontend world that made me miss jQuery every day. I avoid React as much as I can because of that 2013-2014 era.

You will love the paper "Out of the Tarpit". BTW, that paper inspired Clojure. Highlights state management as top priority issue in Software development.

Fantastic video guys, I totally get why you want to use HTMX now. I'm 100% sold and will use this technique from here on out, my biggest struggle was going to be learning how to get JavaScript libraries that were designed for the client to work on the back end and then send it to the client.

Very nice take about how you see it as a state problem, even I with not much web dev knowledge can 100% agree HTMX seems to reduce state sync problems and how you described it with the delete button was nice!

An interesting angle here is that the amount of traffic to serve a given number of clients can be substantially reduced if you send protobuf to a wasm frontend as compared to html/x for every click.

Great explanation, thanks for this

Hahahaha, that burn on Web 3.0! Nice job!

I prefer the Astro approach where everything is HTML (to the client) untill you want an escape hatch. Everyone wins in this approach.

Damn that dudes handsome, should have just let him do the vid

Disclaimer, I'm currently mostly a frontend React dev but I also had a lot of experience on Java/Kotlin backend. I haven't used HTMX but it sounds a lot to how we structure the code at my place of work in the sense that the BE isn't just an endpoint to get data but it actually tells us what we have to render and then we just render it, the biggest problem that I've encounter with that approach is that it creates a very tight dependency on both ends, we in the frontend cannot change anything before it going through te backend so we usually have to wait for them to finish their implementation or have to agree beforehand on one and then start coding; and the backend cannot change anything that affects the frontend (returns, endpoint interfaces, types) without getting our approval first, or else it could break the frontend.

"Managing the state is the only problem you have" the sums up my life.

Great to see HTMX finally reinventing Ruby on Rails! It just took 19 years. We are back to square one.

<a href="#" class="seekto" data-time="2230">37:10</a> : What technique to employ heavily depends on your use case. Having a throbbing (probably long 😏) loading bar is not always the best solution. Although it is the clearest and most understandable in terms of what is happening, it comes at the cost of responsiveness. If you have an app that needs to work in a low/none reception area having to wait for a Server response can be quite agonizing. Think of a package delivery service that needs to take in signatures in a Village at the ass of the world.

As a person learning to program, I didn't realize things didn't work like htmx and it just makes the most sense to me for things to work that way.

HTMX is interesting and looks to be pretty powerful itself.....gotta build a toy project in it sometime, great video!

i have made this point before <a href="#" class="seekto" data-time="2640">44:00</a> htmx is really good if you have lots of permissions and logic and not everything as public. i totally understand this, i have worked on projects where people just keep asking for dumb permissions on who can see what with lots of backend logic. validations and syncing can be a pain, but if I just had htmx back then, everything would have been 1000x simpler. i mean i would literally need 0 js. literally. i wanna use it. but if you have everything as public why spend time querying the db, generating the html then sending the html. while client can just query the db and generate the html itself. run the logic itself, invalidate bad data itself, and never ask for a permission. why not just have a dumb server. so i agree

I didn't understand what you meant by caching. What would be an example on frontend state resulting in a caching problem that server state would solve?

I went from PHP frameworks with vanilla JS to jQuery, to React, to Vue (I choose to not count Angular 1 and 2 as memorable), only to now be happy to get back to vanilla JS inside of a project based on Shopify Liquid.

I used a framework called Vaadin a lot 10 years ago, it took gwt to the next level by having all the states to the server. Gotta check it again to see what they become after 10 years.

One thing I don't like about this channel is when it's comparing apples to oranges. I understand comparing technologies that do the exact same things. However, in this case React and HTMX can serve different purposes, and both offer capabilities depending on the use cases. Just choose the tools that are specific to what you working on. It's good that we have all these different options.

Django Unchanged

What about when we want to keep some state when network goes down, but we want to keep the app seem like working as there is network connection. And sync up the state in two place to sync when network becomes available?

What is that app that they used for the schemes?

For years, I've contemplated diving into the world of React, Vue, and similar front-end libraries/frameworks. However, it often appeared that these tools required a substantial amount of setup and configuration compared to what I could accomplish with Django sessions in conjunction with Ajax or HTMX. Strangely enough, I've consistently found that my web applications and sites remain just as snappy and interactive as those built with React. It's possible that I might be overlooking some key aspects, but I can't help but wonder if the perceived complexity of these front-end libraries is sometimes unnecessary for achieving impressive performance and interactivity on the web.

I think that the components+reactive direction is good. React is just a part of an evolution towards that direction.

This is one of the best video of the last time ...

Lots of projects don't even need htmx. Screen rerender can be blazingly fast for admin panels like Djangos cms. Hyper interactivity is over-rated.

Doing web dev since ~2005. Had some adventures with (P)react, vue and other technologies. Always went back to mostly hypermedia because it burns less time/money. Currently my apps consist of native custom elements, hypermedia and some sprinkles of js modules here and there. BTW i mostly code PHP - take that fancy framework kiddos 🎉

So what you are saying is that we need to write our server code in HTML!

What graphics editor is that guy using in the video?

Lmao, as an old school laravel dev who just wrote a robust and expressive templating engine for Nim, and also just discovered HTMX… I’m so stoked haha

Man I so agree with this. It's so nice to not have the JSON layer ie from frontend to JSON to backend to JSON to frontend. In between things can go wrong. And just to sync state and data, you need things like redux, RTK query, sagas, react query, for navigation it's react router or whatever solution etc. React has been relying on so many 3rd party libraries that try to solve bridging the gap between Fe and be. And these are just not simple libraries, they're whole concepts to learn to even use right. But a stack like HTMX, Alpine.js, Tailwind and maybe Go for the BE can potentially get you so far

Failing optimistic updates are an edge case, not the majority case. Which one should we optimize for? If an optimistic update fails, you can recover from it by keeping the previous state until the server responded. Or by refetching the state. Libraries like TanStack query have both strategies built-in. Or you just wait for the server depending on the case. Then there's all the client-only state that the server doesn't even know about. Like the tree expansion state of a tree view that every client has its own instance of. Why do that through the server?

With SvelteKit you can also avoid future state and you can use the same server state reflection by load function. But HTMX have other issues - concatinate server response, in the worse case we a re back to server templates.

@<a href="#" class="seekto" data-time="104">1:44</a> “Django Unchanged”. Classic.

The problem with the practice of front-end frameworks like React is you're offloading more of the work that can be better handled by specially-built server software onto clients that are a lot worse in processing power and have to do a lot more HTTP transactions to make up for not repeating yourself a bunch of times in backend services. Progressive enhancement should have been the goal, but there's a lot more thought necessary to implement it properly, and companies loathe paying any kind of debt, especially tech debt.

What about 3rd parties using the same API as your client app? With HTMX your API doesn't exist?

<a href="#" class="seekto" data-time="2178">36:18</a> in and feeling pretty dang good about rejecting "Optimistic UI" from the Meteor days. Long live server state!

Would you say HTMX is a quicker, easier option to Svelte in combination with a backend language like Go?

I dont tend to agree with theo but I thought he presented a well thought out take.

I think that`s way too many 80s porn mustaches in one 50 min video that isnt a 80s porn!

How does this play out in applications with web-based _and_ mobile frontends?

What coffee do you drink? Where do I get it?

As a dev working backend, Prime is so right about the insanity of maintaining states on client and server. Also something like HTMX will win purely because for every front end app there are like 10-20 backend services. Ultimately any backend server that needs some small UI to interact with it will adopt something like HTMX

Video games are not an example of server state. The game analogue would be sending the whole game down to the client (HTML analogue). Once you exit the game, there would be nothing left on your PC. Instead, games are pre-installed with gigabytes of data. Clients only exchange minimal data with the server. Some information is exchanged between clients directly instead of the server. Games will typically also have a lot of state and processing that happens on the client (games can be GPU and CPU intensive). The client only talks to the server to persist or load data, just like SPAs. Some singleplayer games are completely offline. The problem with server state is that raw state is not the whole app and visualizing it is something that fits better into the client and needs to be done close to the user.

The Django roast was my favorite. It's always been Django, it will forever be Django. I watched Theo's video first before this one and I thought "why does this guy think that there's any change over time in the web framework in Python land??"

Having frontend as a pure reflection of the backend state is good, but there are certainly usecases for frontend states approach as well, e.g.: - applications that don't have backend state (e.g. excalidraw) - applications that have a lot of interactions that making a call to the backend on each interaction is impossible, in which FE acts as an aggregator to batch the state changes before sending it back to the backend I do agree that majority of usecases don't actually require a frontend state.

htmx seems cool for many use cases. What I like about frameworks like nuxt is that you write your components once, you get an amazing template engine, code splitting is done for you. I can totally see it working with nuxt server components.

Spaghetti code, but _inside_ HTML? That's a recipe for success

Where do you work?

What about the cost though? With a nowadays stack we make the client do lots of calculations instead of our server (rendering) and minimize the cost by providing a minimal API. Am I missing something?

I agree with your core analysis and the problem which Htmx solves, and on paper it makes 90% sense - Until you try to build large apps with 100s of views and modern UX. Your current low-res experiments with Htmx is fine, now try integrate different clientside view components, transitions etc. into your Htmx on the client and see the mess you create. Its also very weird to hammer the server for every bit of html hydration - with SPAs or even Island architecture you can do a lot in the client and only at the end send the Json data back to the server. Your "greyed out delete" scenario is also moot, because it works even better in a clientside app, where your store/model is reactive on the DOM, so when your server responds after delete the store/model is updated. Htmx is fine for small apps with minimal UX expectations.

Those guys look like the brunette twin and the blonde twin 😂

i understand why the detached front end and backend is a pain ... BUT in the real word you have mobile, a client facing API and web all sharing the same service. Its much more convenient to have the one API. You do not want your whole service down because web pushed a mistake.

Most modern applications fit more into the pattern: - Have a backend with some clean (well defined) API - Having (multiple) applications using these API (Mobile, Web, Other services...)

ReactJS devs thinks everything is a nail.

The issue with React is that managing states is complicated... and nobody wants to maintain the same logic twice in both the backend and frontend, but they feel forced to because our backend is used to responding just with just some basic data, so you have to derive state changes yourself when building the UI in there. Anyway, writing components(or declarative templates) is way nicer in most cases, so you'll end up writing them in the backend as well. Also, writing simple transitional states, like graying out something while the request is incomplete, seems to be the same effort for both HTMX and React, so I see no validity in your point around that. The real issue is that people write too much logic in client code, and have too much trouble managing states. Making Frontend a whole mess in the long term. HTMX is nice for simpler UIs and I give you that. But if people just focused on writing better backend code that can return decent state changes for the frontend, then having a Frontend framework wouldn't give us so much pain. However, if we do want to provide state changes from the backend, why not just provide HTML?

I made a webpage with EJB and JSP tags once. For some reason I have long since suppressed I ended up having to serialize objects and send send them to the back end as cookies

The htmx approach of swapping html seems similar to couple of frameworks from the functional world that have been around for quite a while ocsigen from ocaml Something from haskell that had a name with "monad" in it. Something catchy like "mmonad"

HTMX should become basis for HTML6 spec, with but built in signing/checksum for requests from browser to prevent XSS attacks. HTML6+XSS protection based on HTMX will make webdev accessible for the noobiest noobs and truly allow everyone to "learn to code"!

The difference between these two viewpoints is what you optimize for: The smallest possible interaction delay versus keeping state purely on the server. The first benefits the user. The second is an ideological take. You can't have all state on the server AND minimal latency. What is more, the code I've seen from HTMX proponents and examples like the connect 4 app or the game of life demo looks like a couple steps back to me.

How would the API look like if I have to support web and mobile apps? Would it be supporting HTML and JSON responses both via the same endpoint?

What if you have state across mutiple components in the view? Can you use HTMX for that as well? Example, you are on a page deleting your todos but you also have a total count of todos in your navbar. Now that count would be off unless you re-render the whole page?

The ultimate solution to state synchronization will be the use of CRDTs. And as soon as I'm done implementing them all in Python, I'm going to port the library to Go and then Dart. It will be beautiful. Edit: with CRDTs, any number of online and offline state updates are guaranteed to eventually converge to the same state once all updates are applied, regardless of the order of those updates or the number of times they are applied. CRDT updates are commutative and idempotent.

It feels a bit backwards to move in the direction of htmx. I always thought offline-first (using CRDTs) was the next thing. But it does make a very old approach of writing webapps much easier.

For my personal use cases I basically need Static Single Page Applications that update once in a blue moon. And for work use cases we see iOS, Android and Web as three platforms; literally no server side rendering (not even for SEO). HTMX sounds nice and I'll probably never use it :D

thanks for uploading this videos :D