|
|
|
|
|
|
by evilduck
810 days ago
|
|
|
Yes, those are incredibly trivial. Front end development jobs do those tasks every day non-stop, and I'd confidently hand any of those to a junior developer to accomplish in pretty much any front end framework/library/toolset or however you want to accomplish the most basic data driven DOM manipulation. IMO you don't have a non-trivial example on your website at all and even these that you've linked are showing that it's going to get verbose, messy and magically coupled through unchecked identifiers and labels quite quickly. I've done a couple of small htmx PoCs and it's.... fine? I don't hate what you're doing I just think it's super overhyped and when anything grows in complexity over a year or more it's going to be about the same as any other jQuery spaghetti application we used to build as an industry. Long term maintenance of a htmx app feels like it would be about the same as a KnockoutJS app that leaned heavily into "apps written in attributes" (data-* vs. hx-*, but it's just special syntax you have to memorize either way). KnockoutJS was fine then too, we could build infinite scrollers and inline row edits with it almost 15 years ago. |
|
|
https://htmx.org/essays/a-real-world-react-to-htmx-port/
Comparisons w/KnockoutJS (and old angular) are pretty superficial: Knockout is a reactive framework whereas htmx is hypermedia-oriented, they scale differently. htmx tends to scale well when UIs are well factored on the server side:
https://htmx.org/essays/when-to-use-hypermedia/