4 ms·
Your attitude to call out where htmx might not be the best solution, makes me respect the project even more. It's refreshing to see this compared to lots of oth
by hencq 2y ago
Your attitude to call out where htmx might not be the best solution, makes me respect the project even more. It's refreshing to see this compared to lots of other projects that always seem to claim to be the best solution for everything.
I'm curious in particular about the call out around drag-and-drop. Is that something you agree with? Is drag and drop difficult with htmx and if so, is that something you plan on tackling?
- recursivedoubts 2y agoThere is an htmx demo on drag-and-drop (in the reorder sense) using Sortable.js here: https://htmx.org/examples/sortable/ https://htmx.org/examples/sortable/ Like most of the examples on the htmx site it is pretty bare bones (we keep it that way to focus on the concepts) but it's a reasonable demonstration of the integration. Whether that is good enough of course depends on your use case If you want an integrated and polished ecosystem that's something htmx isn't going to provide: it's a library focused (mainly) on one thing: generalizing hypermedia controls. So, when you want client side functionality like this, you are going to have to glue things together a bit. I completely understand the desire of having an integrated ecosystem to avoid doing that.
- hencq 2y agoThanks! That actually seems very smooth. Trying out htmx has been high on my list for a while when I finally get time to do a little personal side project. Real life keeps getting in the way, but this is a good nudge. The appealing thing about htmx to me is that it seems like it should be very easy to keep everything in your head.
- mthoms 2y agoDoes it support nesting?
- recursivedoubts 2y agohere htmx is integrating with Sortable.js for drag and drop functionality via events, so whatever Sortable can do, htmx can respond to: http://sortablejs.github.io/Sortable/ http://sortablejs.github.io/Sortable/
- mthoms 2y agoI'm kinda familiar with Sortable, but haven't looked at it in the past several years. I'll have a look again, thanks!
- spirobelv2 2y agoafter having used both: sortablejs is better than reactdnd. that being said: htmx makes it too hard to quickly add a fat frontend to a page when necessary. The points about the react ecosystem are very valid, even if drag and drop is an exception. The network effects of react and others are hard to beat. Its probably even more npm as a whole than just react. wrote myself a framework with bun that solves this for me: https://github.com/spirobel/mininext https://github.com/spirobel/mininext still get the pure html+css feeling like with htmx, but can throw in a big frontend when needed. https://x.com/spirobel/status/1827231794934247674?t=moRzsWIPysnOcc6LeIYlQQ&s=19 https://x.com/spirobel/status/1827231794934247674?t=moRzsWIP...
- DevX101 2y agoI've never seen a project highlight a negative use case in detail. This is a first.
- giraffe_lady 2y agoIt's not quite the same but SQLite has a page where they clearly present its limitations and how to identify the situations where you should choose something else. https://www.sqlite.org/whentouse.html https://www.sqlite.org/whentouse.html
- recursivedoubts 2y agoWe have a similar essay up on when to use htmx/hypermedia: https://htmx.org/essays/when-to-use-hypermedia/ https://htmx.org/essays/when-to-use-hypermedia/ I think it's a good idea for any software project to have something like this so that people know when it's a good fit and when it isn't.
- abrookewood 2y agoHave to agree - it's certainly refreshing to see someone acknowledging that their technology isn't going to work best in every case.
- giraffe_lady 2y agoAh cool! I've used htmx and like it but I hadn't seen this before.
- dannyobrien 2y agoMe neither. In the 2000s, Tor did something similar (a "what Tor can't do" page) and prominent linked to it on the front page, which definitely improved the project's reputation with a coterie of infosec professionals. It might not have helped with wider adoption though. People would send me the link saying "Look at all of these bad things about Tor", and it would be links to Tor explanatory pages. It was around that time that I realised that when trying to give people an intuition for what software many Internet professionals trust, the list of "green flags" I identified was, in fact, the exact opposite of what the majority might guess as being good signs. "Large list of attractive sounding features" vs "Lists problems with the tool as prominently as benefits" ; "Sold and marketed by a large well-known company" vs "Developed by a small, volunteer team" ; "Free to download" vs "Costs money"; "Modern, professionally-designed website" vs "Looks like it was built in 1997", etc, etc.
- x0x0 2y agoI've used hotwire a bunch, and with minor differences, I think the list of things that htmx is not good for is spot on. I don't think I'm explaining this well, but maybe this will help someone: Hotwire / htmx are about server-side rendering and making that work more smoothly with the client. eg fewer page navigations, more rapid update of the client, etc. But it's still, through and through, server render with server state. It works well as long as the server is always the source of truth. The things that it isn't good at, such as drag and drop or complex, multi-state forms on the client side, are basically because you temporarily have a split source of truth: the client is the source of truth with complex state. That said, my strong suggestion would be to use Hotwire or htmx for 95% of your project even if the main interaction loop is done in react. Your app will still likely have tons of crud around user management, settings / config, onboarding, etc. You can make all that work more nicely. edit: in case it wasn't clear: for the things that are in the hotwire/htmx wheelhouse, the tech works really well. It's a fantastic improvement.
- rikthevik 2y ago> 95% of your project even if the main interaction loop is done in react The trick is to be very honest with yourself (and team) about how much complex front-end UI the application actually _requires_. Using React where it isn't necessary is very expensive in the long run. The older I get, the more the grug brained developer makes sense.
- Aeolun 2y agoThe more I work with React, the more I realize I just don’t have the motivation to learn and keep up with more than one way of doing front-end. Using it everywhere is working out pretty well for me. Sometimes it’s not the best choice for the app I’m working on, but it’s always thr best choice for me.
- Freedom2 2y agoAgreed. Too often you'll see HN's claim that PHP / Java / MySQL are the best choices for everything, where often times they are blind to specific problems and use-cases that other developers are trying to solve.
- ksec 2y ago>Too often you'll see HN's claim that PHP / Java / MySQL are the best choices for everything. Either this is missing /s or this is trolling, right?
- freedomben 2y agoIndeed. Even if hn were a monolith and all had the same opinion, it certainly would not be a pro PHP, Java and MySQL position.
- BestHackerOnHN 2y ago> It's refreshing to see this compared to lots of other projects that always seem to claim to be the best solution for everything. Agreed 100%, hencq!
- porridgeraisin 2y agoYour effort did not go unnoticed :-)