3 ms·
While I love both Go and Alex, my experience with HTMX has always ended up being disappointing. I think the best way to put it, when I'm working with HTMX it f
by overflowy 3mo ago
While I love both Go and Alex, my experience with HTMX has always ended up being disappointing.
I think the best way to put it, when I'm working with HTMX it feels like the complexity of the codebase is growing at a 2:1 rate compared to the app itself. I always end up with some weird edge case that I can not come out of without some weird hack.
I get why people dislike Node packages, HTMX feels like it's an overcompensating response to that. But the time you save by not having to wrestle with JSON is tripled when you try to make the app actually look or feel good. It takes me 2 minutes to slap together a Mantine template [1] and tap into some of the best UI components, then I can embed the built static assets and end up with the same single Go binary.
[1] https://github.com/mantinedev/vite-min-template https://github.com/mantinedev/vite-min-template
- yawaramin 3mo agoWhat's an example of a UI that you built with Mantine that you couldn't with htmx?
- fhn 3mo agothey never said "couldn't". they said "feels like the complexity"
- yawaramin 3mo agoOk, what’s an example of the complexity growing at 2:1 rate with htmx but not with Mantine?
- overflowy 3mo agoBasically any data grid that implements multiple AND/OR filters at column level, sorting, reordering, infinite scrolling, virtualization for handling large amounts of data, etc. Also handling basic pending / error / retry states (things that I take for granted with React Query).
- yawaramin 3mo agoYeah, a data grid is a good example of a complex hyper-interactive component. There are people out there who have made them with Web Components, which can be dropped in and used in htmx projects when used correctly. Re: request states, handled very nicely out of the box by htmx with a little knowledge of attributes like hx-indicator and JS event handlers to handle htmx error events.
- michaelchisari 3mo agoI've found that my whole design philosophy has to change to work with HTMX. That's not a dig, it may even be a good thing, but it's a significant shift. The designs become much more native to the web and much less inspired by mobile apps.
- appplication 3mo agoAgree, tbh. If I’m doing frontend I’m just using svelte nowadays. It’s quite nice.
- dhamidi 3mo agoI understand the sentiment. Rails was my introduction to hypermedia and it was convenient and easy, so experiencing friction when building with Go/HTMX came as a surprise. After a few attempts I learned that abstractions are important :D Without a component builder and reversible router is indeed pretty painful (and Rails just ships with these things so you didn't have to worry about it). The biggest benefit for me personally is that computation and data live in one place, which carries you very far. Also, machines like hypermedia: LLMs are great at using and testing hypermedia apps because they are self-contained and the cycle time is lower because you don't need to wait for JS. And yes, no easy off the shelf component library makes starting harder.
- abdullin 3mo agoI’m struggling myself a bit with the components and routers in HTMX/go. Can you recommend any source code or reading on that topic?
- dhamidi 3mo agoThere's vuego: https://github.com/titpetric/vuego https://github.com/titpetric/vuego And my own version (I learned of vuego only after): https://htmlc.sh https://htmlc.sh Not a fan of html/template and tmpl myself, because HTML should be treated as tree and not as strings, but everybody has different preferences. For routing I now use my own library in all projects: https://github.com/dhamidi/dispatch https://github.com/dhamidi/dispatch It's relatively easy to generate your own nowadays, I mostly go through the Ruby on Rails guides and mix and match the pieces I want for go and turn them into libraries :)