Never seen a tool where the people who don't use it seem to make up some of the craziest, most obscure, weirdest justifications for avoidance. It's totally fine if you're not personally down with HTMX!
However, stating that we're avoiding "idiomatic code" is incorrect. Are you claiming React and JSX and useEffect are idiomatic? Really? Surrounding HTML fragments with return() and attributes with braces is idiomatic? These are literally the antithesis of HTML.
Perhaps the real reason we're happy is that we're experiencing a huge productivity increase, lower cognitive load, fewer difficult bugs, terrific performance, and a great dev experience.
Here's some code that I don't find especially idiomatic:
<form hx-post="/test">
<input _="on htmx:validation:validate
if my.value != 'foo'
call me.setCustomValidity('Please enter the value foo')
else
call me.setCustomValidity('')"
name="example"
>
</form>
It has a multiline HTML attribute value and an unfamiliar programming language with the english word me that is sure to be confusing to some who don't speak it as a first language.
i use hyperscript because I created it and like it, but the example could just as easily use JavaScript, the point is to show that htmx respects custom validations
The docs don't seem to suggest using it for non-trivial things without hyperscript. https://htmx.org/docs/
They do suggest being able to use it without learning a lot of hyperscript, but I see the same with Svelte, where you can get by on copying and pasting a great deal. https://learn.svelte.dev/
most of the examples don't have any hyperscript in them
htmx generalizes HTML as a hypermedia, making any element a hypermedia control that can issue any type of HTTP request in response to any event and target any element in the DOM for replacement
that's the concept, improve HTML, and it gives you quite a bit more than plain HTML, but it is intentionally constrained to not go beyond that
for things beyond what that gives you, I am not afraid to recommend scripting: Fielding explicitly included scripting as an optional constraint his description of the REST-ful architecture of the web
A good example of how we like to see scripting used w/ a hypermedia system is the Sortable.js demo, which shows htmx integrating w/ Sortable.js via events, the cleanest way to integrate hypermedia controls w/ client side scripting:
> for things beyond what that gives you, I am not afraid to recommend scripting
I'm not suggesting that you don't. I'm suggesting that it's quite similar to SvelteKit, Remix, and now Next.js, and other form-friendly frameworks in what you'd need to know in order to do a non-trivial full stack JavaScript project that supports progressive enhancement.
The difference is that with HTMX you're not stuck in "full stack JavaScript" land. Any language that can generate HTML becomes a viable full stack option without the headaches of modern JS tools being forced into the mix.
The unfamiliar programming language (which I've never used) seems to be binding some code to some type of validation event. "my" and "me" seem to refer to the input tag. "my.value" probably refers to the value of the input. If it's not foo it calls a setCustomValidity method with the input tag as the caller. Could be some built in method that you can call on any input tag or anything validatable.
Ok I just checked the link and setCustomValidity is part of the HTML5 Validation API (haven't worked on web dev in years).
I can assure you that the first person pronoun is among the first things we learn when studying English and assuming the code snippet does what I assume it does I'd say it's pretty intuitive to learn. Especially if we are comparing it to JS where "this" is not what you'd expect from using it in other languages, but the late-bound called of the function... except in all the cases where it isn't.
In any case, trying to guess how a programming language works is a very bad idea so it doesn't matter how obvious the language manages to be, you still should read the documentation.
I would likely agree, however this example makes heavy use of hyperscript, which is an associated project by the same author, but is distinct from HTMX.
How do you do validation with custom error messages without it? It seems pretty table stakes for forms to me.
Where are the docs that make it easy to avoid hyperscript, if it's usable without hyperscript? This has hyperscript sprinkled in: https://htmx.org/docs/
That was implicit in my question. We aren't talking about writing purely server side web apps here, and it's reasonable to expect something like client side validation, given that this is meant to be an easy way to do full stack web apps. I think it is but not really easier than other major ones.
> We aren't talking about writing purely server side web apps here
Ok, but note that a big part part of the appeal of htmx is that yes, you work mostly server-side. If your use case absolutely needs client side code, htmx might not be the right fit. (But in many cases you don't need as much client-side Code as you might think at first.)
Why do I continue to see people imply that React is the only way of writing frontend web applications with JavaScript? There are plenty of alternatives to React that I would say are far more "idiomatic". I highly recommend taking a look at Vue 3 or Svelte to get a better idea of what frontend JavaScript can be.
React isn't the only way, of course, but it's likely the most popular. Why do you consider Vue or Svelte to be valid alternatives but not HTMX, despite plenty of people endorsing it and openly proclaiming how successful it's been in their projects?
I personally do consider HTMX to be a valid alternative to React, but I also think that a lot of usage / promotion of it comes from people who are misinformed and think that the entirety of the JavaScript ecosystem is React. I consistently see a lot of people use HTMX over React alternatives purely because of a "distaste for JavaScript" or an understanding that everything is or has to be as complex as React unless you're using HTMX.
If people are "misinformed", that's a marketing fail by those other frameworks, despite many years of headstart. How are people even finding HTMX (with a single developer and until very recently, no corporate support) in a marketplace which includes Angular, backed by Google?
Or maybe people are kinda informed, and simply drawn to HTMX because it's easier to learn than Vue, Svelte, Mithril, Cycle, whatever (or they just don't want to try a zillion frameworks) and it works really well and developers seem to love it and recommend it a lot?
It's easy? It works? It feels like HTML? No build steps? No JSON? The primary documentation fits in a single page? Most common patterns (i.e. polling, and then stopping if necessary) are built-in? Because fundamentally, it's just standard HTML forms? The entire dev experience is focused on a single application (backend) as opposed to writing a backend and a seemingly separate frontend project, in a different language (unless you use JS on the backend)? Simply replacing HTML fragments is conceptually simpler than maintaining a shadow DOM? It embraces web standards/APIs (see client validation discussion above)?
> Never seen a tool where the people who don't use it seem to make up some of the craziest, most obscure, weirdest justifications for avoidance
Sure you have: literally any frontend framework post, from React and Vue to roll-up, webpack, and everything in between. Tons of non-FE engineers or engineers that work on small and trivial apps will flood in to say why the lib in question, and usually the entire FE ecosystem, are crazy, rapidly changing, undecipherable, etc.
However, stating that we're avoiding "idiomatic code" is incorrect. Are you claiming React and JSX and useEffect are idiomatic? Really? Surrounding HTML fragments with return() and attributes with braces is idiomatic? These are literally the antithesis of HTML.
Perhaps the real reason we're happy is that we're experiencing a huge productivity increase, lower cognitive load, fewer difficult bugs, terrific performance, and a great dev experience.