I'm on the HTMX struggle bus right now

As someone who hasnt done any traditional server rendered stuff i really struggled with htmx so im glad im not the only one. I tried using it with astro as i gave up with the poor experience of templ but even in JS land its been pretty rough and slow going

The entire time I've been using this stack, I've been wishing for some multi-language lsp to exist that would have go to definition for htmx tags, same thing for templ templates. But I wouldn't work on it, because I'm lazy and I don't understand it.

this seems miserable, i guess this is your learning experience for figuring out, devex is worth paying for, be it memory or performance

HTMX is what happens to teams that have someone who refuses to read an article on how to use useEffect correctly

Thanks for the overview. It seems that DX is not that good for making rich UX-friendly frontend 😢
IMHO, it suits the ToDo list like frontend development only.

Excellent video! I'm super excited by htmx and the idea of trying to simplify the frontend, but it's hard to find content on htmx's pitfalls and without that I can't judge whether or not it's a really good alternative to React. I'm looking for people who have used it in projects seriously enough such that the bad parts become evident. Thank you for posting this!

next.js till i die

Thanks!

I think you are using HTMX for the wrong use case. this project seems like a strong case for Next or SPA with an API backend. I see HTMX as any other template language like Jinja or mustache. it is intended for displaying simple stuff which don't need much interactivity. i would actually use this for a landing page that need some dynamic content. Not for this.

You can use css to only show some element if your list has no children.

Templ seems like JSX just worse.

I'm just curious—are you moving faster and writing less code with this stack compared to Next.js?

It's a major step down from nextjs dev experience! It's safe to say htmx is in its infancy

I warned you, friend! You will end up Grepping substrings of those templates, because even Go is a golden treasure in my opinion, the majority of the community are Neanderthals who loves to work with sticks and stones, and that's why there's not enough people to advance with the dev. Tooling like in JS land

could you try pocketbase (extendable with go) + react to see how the DX and everything go? I like htmx, but building a lot of components that react community already had is a bit too much for me.

"...still a lot of developers who use vscode"

Have you tried Svelte/SvelteKit? If you’re after simplicity that’s where it’s at.

JSX/TSX feels great with HTMX. You might like it a little better with Hono or Elysia

I've been slowly prototyping a rewrite of a large web app with the BHANO (Bun, Htmx, Alpine, hoNO) Stack, and here are some of my notes about 15% of the way in:

PAIN POINTS WITH WRITING A LARGE APP WITH BHANO:

- Sharing Alpine state between components - so things like tab switchers can’t be put in separate components anymore, they have to be put in the same component as the view they control (possible workaround - do the tab switcher and the view the switcher controls in one component, then split out the individual components used to populate the view on each tab switch)
- So many other things like that that were no-brainers in React/NextJS that are trickier here. It’s wild how many parts of React you take for granted until you have to write apps without them. As Cody said it feels like going back to Vanilla JS and jQuery DX-wise in some ways ( though as I will say later, Hono using JSX as a templating engine out of the box flattens this learning curve considerably)
- Not being able to use reusable button/input/whatever components because afaik there’s no way to add HTMX directives to reusable components (workaround for me has been to reuse Tailwind classes - put Tailwind classes in a separate file and import them to use as a variable)
- The amount of endpoints using server-side partials for what used to be client-side interactions creates - and you probably won’t want users accessing your partials endpoints so protecting them with CORS rules is more extra overhead
- de-duping duplicate network requests created when partials routes are called, for example this app has a separate backend (also hit by a mobile app) that in this version of the app gets the same request from both the main page and the partials routes in many areas - a separate REDIS cache would be needed for the "frontend" (yes I know BHANO isn't a true frontend framework but we'll call the part that serves the HTML/HTMX the "frontend") to cache and de-dup backend requests
- BHANO code may be less maintainable due to inherent less separation of concerns and less encapsulation due to the way HTMX and Alpine work
- Because HTMX/Alpine-based stacks are so new, resources/ecosystem and a concrete roadmap for doing things are harder to find than they would be for NextJS/React
- Also because Bun is so new we are not sure about how production ready it is.
- Futureproofing: what if there is a feature we absolutely need React, Preact, or some other client-side JS framework for further down the line? This is unlikely with most apps but not completely outside the realm of possibility. The AHA (Astro-HTMX-Alpine) Stack may be a better compromise in this case where we sacrifice some speed and RPS gains for futrureproofing since a client-side JS framework can be added later if needed. My only issue with AHA is sometimes things like JSON responses leak to the client and keeping this from happening would be a priority.

GOOD THINGS:
- Already faster and snappier than NextJS was at any stage of development - page loads happen faster, server side content switches happen faster, everything is faster. Going to look at Lighthouse scores and performance on Slow 3G after first test deployment and I bet all of those metrics will improve.
- Smaller codebase, less dependencies, and less JavaScript being loaded means faster load times and at least theoretically being able to serve more RPS (especially with Bun outperforming Node in RPS benchmarks)
- Since Hono uses JSX as a templating engine out of the box, the DX of using Hono JSX is in some ways very similar to React. React devs will be familiar with many parts of Hono JSX, only a few things are different regarding templating. If you’re willing to sacrifice whatever RPS gains you get from using a Go/Rust based stack for developer velocity BHANO is a good stack.
- Since BHANO is entirely server-side you get a lot of the security gains you get from RSC-based frameworks like NextJS app router (for example, being able to use server-side environment variables for secrets and keeping JSON responses out of the network tab) in a way smaller, faster package.

ngl. this specific framework looks awful to dev with

I don't understand why you're doing a network request to validate a password regex. You shouldn't think of HTMX as a tool to completely replace client-side interactivity. If you are mutating state then you should save the state in a DB and use HTMX to replace the new UI resulting from the state change. Use whatever client library you want for interactivity that doesn't mutate state.

htmx would have been a lot more fun and interesting to work in a world where we only had vanilla javascript or jquery. The fact that we don't have to write a lot of javascript would have been way more appealing then. With the all the frameworks present today and more coming in every day it does feel like one needs to change their mental model when using htmx for anything more serious than a todo list. You need to think to all the html you will return with each request rather than just worry about data, so the entire UI becomes dynamic rather than just the data.

I was in a similar place when i was first switching from Vue to htmx. I’d say dont give up yet and focus on trying to shift your mental model of where state lives, how many states you really need, and what benefits youre getting from making certain trade offs.

I found my time in SPA land with the atomic component mental model atrophied my way of thinking about the server-client relationship. It wasnt until i shifted my focus back to this being a server first that things started to click. For me it was the shift from thinking (incorrectly) of HTMX as a state library like i think of Vue as to just a server response processor that things started to really click.

For me, this stack with sqlc has such a fast write velocity that i never had with vue and nuxt. I define my source of truth in raw sql files. Run sqlc to generate type safe go structs and methods. Handle requests with Chi and return html in the form of full documents or html fragments via type safe Templ. I define different “states” of components in the same Templ file since you can have multiple components in the same file. Its really so few layers and so fast. Very little niche syntax or framework conventions. Just go, sql, html, and tailwind. No dependencies in comparison to JS land. No ORM. No obscure behavior or documentation. Pretty transparent control over the code. I just love it and dont see a reason to lock myself into a framework for my side projects.

As for the rough points around Templ and Air, i sometimes experience cache mix matches with the generated go file, but not too often. Though this is a fair pain point that the templ team is working on. Templ is really young so these rough edges just come with the territory unfortunately. Ive never experienced the go to definition functionality of the lsp going to the generated go file and not the templ file, though i use vim. This js certainly a bug that the team will fix. Annoying for sure though.

At the end of the day, we just type words on a screen for a living. Use what makes you happy and try to be open to trying new things. Cheers :)

I appreciate if you tell us honest opinion after all, without looking at other "influencers" about this crap. Because this getting ridiculous and harmful. I feel sorry for newbies getting brainwashed by folks telling them to use HTMX.

Have you thought or tried using html with python with fastapi and jinja2 for template rendering? I’m curious to try Django next but just want to know if you had any thoughts on it?

This feels like code that I wrote over a decade ago... and the reason why I learned react. That didn't actually feel that simple, what would a medium size app look like? Or am I just stuck in typescript brain and don't get it...

One day I hope it comes back full circle and people would just use jquery again and learn how the plugin system worked.

Honestly sounds like you wanna try pheonix or livewire

Hey Cody! I'm loving your newest videos. I wanted to ask, I saw that you are using Railway for hosting your apps. Any advice on how to backup the databases there?

Same issues here

HTML/CSS/JQUERY/GO is the new radical stack

This ecosystem is still new, but the experience I've had with GoLang and GoLang with Templ is definitely what I want for the future. I am willing to start dedicating my time to contribute to the Templ LSP and to improve the plugin for both VsCode and JetBrains' GoLand. I hope more people will see the potential and decide to contribute to open source, making it better and better! This stack "GoLang, Templ, HTMX, and Tailwind"is amazing. My enthusiasm for building full-stack apps has been completely restored.

I think a lot of the struggles come more from "unlearning" certain patterns that you get used to from those frameworks. For me i find htmx to work best when mixed with different model, so as .net dev it is either with MVC razor for older projects, for blazor for newer ones. Generally doing everything in htmx would be / is in fact pain in the butt, buuut again it is for simplicity. HTMX isn't there to swap entire page loads etc, it's to dynamically update elements on html.

I think there is no need to panic when id not found. Overall nice progress 👍🏻. You tha best

Hey Cody. When I first began web development, I was trying to learn react native. I knew virtually nothing and had a problem with my web socket implementation. I reached out to you on discord and you took the time to help me understand my problem further even though you could almost certainly tell I had no idea what I was doing. A few years later, I'm now working at a company developing mobile apps using react-native. I just want to thank you for remaining passionate and helping people like me understand web dev. <3

I have been writing lots of complex stuff in HTMX. Your issue with the login screen is because you are not using a progressive enhancement approach. The form in the login page should be designed to work without JavaScript, which means the backend should return a redirect response after a successful login. Then you simply add hx-boost to the form element so htmx will do the request and follow the redirect accordingly. Without hx-boost and progressive enhancement mentality, you will struggle. I have been there.

Another issue is that you are not using hx-select. Your swaps are too granular. You don't need to have small pieces of UI that you manually replace here and there. Try to have bigger UI components that you can either swap the whole thing or just a piece of it using hx-select. You are still approaching it from a data-driven approach it seems.

You should always add vanilla action and method attributes to forms so that they would work even if js is disabled or failed. Also, try htmx multi-swap extension, it makes life easier by allowing to pick and swap multiple fragments from a single response.

Which backend technology do yo suggest to learn as a frontend developer to be a fullstack developer? Python , Go or Nest.js itself ?

I doubt Neovim would solve the issue the "Go to definition" issue you described. I suspect it's an issue with the language server implementation of Templ which would affect all editors.

You could also return status 302 with a "Location" header to make the client go to another url. That is what i did. So much fun seeing someone explore the same things i am exploring as well. Except I am using Astro to serve my endpoints. But I also want to find some time to learn some Go. It's on my list of things i want to learn. I do think we have a tend where web dev is going back to basics, and I am excited for it. Awesome video.

Using fasthtml Python framework made me rethink how I understand htmx, and now I've gotten better at it as a result

IDK HTMX seems more complex than React to me! Maybe I've developed React brain 🧠

The series is great! Awesome to see someone proficient at React taking a stab at HTMX without fanboying

And tbh, without a proper LSP, HTMX feels like Spaghetti code for a proper interactive app.

Rails/Laravel/Phoenix have their own solutions. So ultimately it’s up to Python/Go community to carry the mantle on this. Which might take awhile

If ur using the native go templating library to serve ur trmpates, the file extension can be html. I just make mine .html instead of .tmpl and that solves the intellisense issue mostly

I’m so much slower using htmx and everything looks like 💩

just reload the page and use url params to display things conditionally

Honestly most of the stuff here does not even need htmx. This app should work without any js, but the htmx can be used to improve the user experience in specific components.

Please try EHTML