How did we get here?

Oh, right, Facebook.

spa: server: run app.js to generate vdom -> serialize to html -> send client: receive html -> deserialize to dom -> download app.js -> run app.js to generate vdom (again) -> attach event listeners from vdom to dom htmx: server: run app.howl to generate html with htmx attributes -> send client: receive html -> deserialize to dom -> download htmx.js -> run htmx.js to attach event listeners

and for anything that you can't do with htmx, you can use javascript or hyperscript with progressive enhancement, which again only runs on the client

did you all see https://primatejs.com/quick-start/ posted on HN today?

not sure what the value prop is for htmx written in js. Does anyone have a breakdown?

same as htmx written in any other language

lack of context switching?

localization of behavior?

ah I see it's just a router that returns html that happens to be htmx

Is it possible to call an async function in htmx:configRequest?

i.e. modify the request that a form is sending based on reading a file asynchronously

related, got a small mention in #1079191774976802867 recently: and related: The current workaround as far as I know, is to do it in vanilla js: 🟢 form wants to be submitted ➡️ trigger event to vanilla js ➡️ do async thing ➡️ async result ➡️ trigger htmx submit event 🛑 done

Of course, if you don't need to get the result from the async thing, you can just fire it off in htmx as usual. The issue is when you actually need the result.

its not one size fits all in this case, typically: Result not needed (fire and forget): analytics, logging, .... Result needed: captcha, pre-validation, client-side file processing, ...

That's a cool workaround, didn't even consider that, thank you

You're welcome dude, do leave a +1 on the issue 😉 it would be nice to get that convenience in someday.

No, unfortunately not

@proud-librarian-99598 don' you think it's worth a patch? I'll comment on your issue, read the source code and see if I can come up with an extension or something...

> Speaking as a long-time UI guy... The only thing I can imagine being worse than HTMX's design philosophy is then writing another layer of JavaScript on top of it

ikr, compliment and neg all in one lol. good old HN.

> People who like HTMX dislike good UIs, it's that simple.

\> reading HN \> ever

\> Using htmx is reminiscent of the dark times of web development directly over ftp without using a version control system.

there are plenty of nice comments too, i shouldn't focus on the negative

Yeah the rebuttals to the troll were really cool.

where are these quotes even coming from

htmx is universally beloved by Fullstack devs. Frontend devs may not appreciate the simplicity if they aren't able to influence or see the backend.

HN thread:

In the answers I read: "Also, this HTML renderer logic needs to be aware of the rest of my app, so the reverse is true; when I'm going to write some new UI, I have to go put it somewhere random, associate it with a frontend route and backend endpoint it loads from, and then attach all the possible nested user-actions from this HTML." I do not agree with this, in my opinion the end-point should be driving the interaction with the network application not with the client-application consuming hypermedia API. I see those as two different things. In the end it turns out that I write less js in any case by having the state being driven by the interaction with the network application