stop trying to make htmx happen, it's not going to happen
htmx
201–210 of 291 posts
Re: htmx
#202Heh, the "Memes" section of their Essays page is brilliant: https://htmx.org/essays/#memes
A lot are also missing the point entirely for comedy's sake. Which is admittedly fine for a meme...
While I love making projects with htmx, doing the equivalent for the complicated frontends we've got at my dayjob would not be enjoyable to maintain either. You'd end up with with fragment routes all over the place and will have serious issues finding where which is used, as the routes are all just strings with variable substitutions. Its also annoying to write non-e2e tests for the resulting backend IME, which is totally fine for a lot of applications, but forces you to restructure your code awkwardly to be able to write unit-tests in the backend
Re: htmx
#203HTMX is just HTML. HTMX substitutes a DOM element with the HTML response you get from an on-click HTTP request instead of redirecting to a new page. Claims of HTMX being yet another complexity or yet another JavaScript framework fail to acknowledge this.
no, htmx is (technically speaking) just another JS framework.
Just look how VueJS got started, it began with sprinkled in html and was marketed as the framework for backend devs, as you were just writing html to render lists/objects etc.
And htmx does more then what you're alluding to here, as should be obvious from reading their docs about server-side events, notifications, lazy loading, JS extension api etc
Re: htmx
#204Earlier quoted context omitted.
Mostly, you validate on the server and send html with error messages back. 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.
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.)
Re: htmx
#205Heh, the "Memes" section of their Essays page is brilliant: https://htmx.org/essays/#memes
This is gold !
Re: htmx
#206Hmmmm... no. This: Click Me Should be just this: Click Me This way, no magic would be needed, a lot of indirection and complexity would be avoided and everybody who knows HTML and JS could immediately read and understand it: - When does something happen here? When the button is clicked. - What does happen? htmx.post() is called.
Think of the tags as a constraint. It's quite easy to check that certain constraints are met with tags. It's much harder to check on this ="htmx.(, )" convention. Soon you'll have unconstrained code creeping in (e.g. onclick="!loading ? htmx.post('/clicked', 'outerHTML') : void(0)").
Re: htmx
#207Earlier quoted context omitted.
no differerence at all. jQuery functions like $('.foo').on('click', () => $.ajax(... $('.bar').html(result) )) become unmanageable just as quickly.
So your complaint is not about HTMX, but about using any kind of JS without using a framework like React.
I’d really like some explanation about what I’m misunderstanding, downvoting without explaining anything doesn’t help anyone.
Re: htmx
#208Hmmmm... no. This: Click Me Should be just this: Click Me This way, no magic would be needed, a lot of indirection and complexity would be avoided and everybody who knows HTML and JS could immediately read and understand it: - When does something happen here? When the button is clicked. - What does happen? htmx.post() is called.
Think of the tags as a constraint. It's quite easy to check that certain constraints are met with tags. It's much harder to check on this ="htmx. ( , )" convention. Soon you'll have unconstrained code creeping in (e.g. onclick="!loading ? htmx.post('/clicked', 'outerHTML') : void(0)").
That is what function parameters are for.
If you want a parameter "not if already loading", make it part of the post() function. No reason to make it an attribute on the html element.
Re: htmx
#209Earlier quoted context omitted.
Think of the tags as a constraint. It's quite easy to check that certain constraints are met with tags. It's much harder to check on this ="htmx. ( , )" convention. Soon you'll have unconstrained code creeping in (e.g. onclick="!loading ? htmx.post('/clicked', 'outerHTML') : void(0)").
That is what function parameters are for. If you want a parameter "not if already loading", make it part of the post() function. No reason to make it an attribute on the html element.
No reason to make it part of the post() function either.
Re: htmx
#210Hmmmm... no. This: Click Me Should be just this: Click Me This way, no magic would be needed, a lot of indirection and complexity would be avoided and everybody who knows HTML and JS could immediately read and understand it: - When does something happen here? When the button is clicked. - What does happen? htmx.post() is called.
You are missing the fact that html has very restricted list of events that can be defined in an attribute. Htmx allows to listen on any event, plus some extra features on top, such as event throttling, polling, synchronization between elements. Stylistically I can see the appeal of your proposal and even agree on some ways, but it's not functionally equivalent https://htmx.org/attributes/hx-trigger/ https://htmx.org/…
What would be a simple example of an event that you want to define inline but can't in plain html?
Can you give minimal example on jsfiddle so we can compare different approaches?