Any practical experience using #HTMX over #react for #js web dev?
-
-
@cwensel Not react, but I used Angular to make a pretty big app. Once I discovered #htmx, there was no going back. Welcome to the party
Htmx is a big shift in how you think about the web. It returns control to your server, so you’ll need a really good HTML rendering engine for your server-side environment.
And, ignore the JavaScript naysayers who say it’s slow, won’t scale, whatever. Htmx performs fantastically, and has been far easier to organize than anything I did in JS.
-
@benpate nice! Thanks for sharing
-
@cwensel @benpate Don't let the horse tell you. There are always several tools to do a job well. #htmx is good for many things, but sometimes it makes sense to move more logic to the client side. I already have Angular and React etc. used too for large projects. These frameworks or libraries can make sense. Currently, however, I also use htmx for one project and #alpinejs for more complex things in the same project.
But it always depends on the -
@leobm @cwensel Oh for sure. Use the right tool for the job -- and there’s plenty of areas where htmx is totally the wrong tool.
I think I’m saying the same thing as you, just from a different angle. I’ve met lots of devs who can’t see past the Angular/React/Vue to even consider anything else.
I’m building primarily in htmx, with various JS tool to augment the things that should obviously be done in the client (like playing music. Who plays music on the server??)
-
@benpate @cwensel Ok, as has already been said htmx is a really interesting approach. However, you should use a good template engine, even if you can create something like components in it (i.e. your own tag where you can set attributes). What I personally find important is to also think about the paths for http requests. When you work with json, you think in terms of resources, which is not really the case with htmx anymore. I haven't
-
@benpate @cwensel found a really good approach yet. I'm trying to think along the lines of atomic design. So in (atoms), (Molecules), Organisms, Templates and Pages. And then to reflect this in the URL path. But perhaps there are better approaches. I simply comitted myself to something like this.
In any case, I had to rethink things a bit compared to the "classic" frontend applications with JSON API. (I have never used graphql seriously before)
-
@leobm @cwensel Yes, this is solid advice.
The server side templates don’t need to be too sophisticated. For me, standard #golang templates have been plenty, though many gophers like the Templ library.
My routes are pretty simple. Each “object” has a list of additional methods/routes that they can load, so there’s only two levels of hierarchy and I’ve never felt like I needed more. There are a few odd widgets that I add in, but in my app they’re usually more trouble than they’re worth.
