<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>
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
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/
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:
https://htmx.org/examples/sortable/
we have a chapter on client-side scripting in hypermedia systems here:
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.
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/
In the example above, if you need custom validation logic, you could handle the HTMX:validation:validate event with any normal JS event handler.
Of course, it's up to you to decide how much effort to put into client-side validation that can be easily bypassed.
If you really need client-side, yes, of course you have to script it. If hyperscript is not to your taste, you use a bit of js.
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.)
Me/my is rarer: Reminds me of VB
it's based on HyperTalk, the scripting language of HyperCard:
with some Web-specific syntax thrown in to make things cleaner:
add .visible to <section.fade-in/>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 language 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 learn the documentation.
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?
But isn't HTMX one of said zillion frameworks? What makes it any different?
Here's polling in Svelte: https://stackoverflow.com/questions/61391174/how-to-do-polli...
and in HTMX:
hx-trigger="every 2s"
Maybe Svelte has an easier way, but Google isn't directing me straight to it, which is all part of the "easy to learn" aspect.
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.