Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Htmx – high power tools for HTML

htmx.org

Post reply on HN
Print view View original

31–40 of 175 posts

Re: Htmx – high power tools for HTML

#31

Post by recursivedoubts »

gavinray wrote: post #24
recursivedoubts wrote: post #10

hello, I'm the creator of htmx (and originally intercooler) I just released 0.0.4, so htmx is still very young, but it's got a decent test suite: https://htmx.org/test/0.0.4/test/ there is a nice extension mechanism: https://htmx.org/extensions/ and some very rough docs on how to pull off pure HTML animations: https://htmx.org/examples/animations/ happy to answer questions

I've heard of Intercooler before and saw htmx on Github trending a few weeks ago. A question about this example: https://htmx.org/examples/inline-validation/ This paradigm revolves around sending validation requests to server-side endpoints, is there any reason to put that load on the server rather than validate it on the page prior to submit with JS? Or scalability issues? Not being antagonistic, genuinely curious b…

I'm not dogmatic about it. Some validation has to be done on the server side (e.g. unique emails) and any validation has to be redone on the server anyway since the client side isn't a trusted computing environment, but I can see doing both.

Re: Htmx – high power tools for HTML

#33

Post by recursivedoubts »

XCSme wrote: post #26
apineda wrote: post #22

Earlier quoted context omitted.

What else would you send?

Not to send data, but receive data and update the UI accordingly. I looked a bit through their examples and it seems that they expose a way to update the UI with the response from the AJAX calls, but probably server has to return the entire HTML code?

yes, responses are expected to be in HTML

but you can use the client-side-templates plugin if you want to run responses through a client-side template engine:

https://htmx.org/extensions/client-side-templates/

Re: Htmx – high power tools for HTML

#34

Post by dgut »

gavinray wrote: post #24
recursivedoubts wrote: post #10

hello, I'm the creator of htmx (and originally intercooler) I just released 0.0.4, so htmx is still very young, but it's got a decent test suite: https://htmx.org/test/0.0.4/test/ there is a nice extension mechanism: https://htmx.org/extensions/ and some very rough docs on how to pull off pure HTML animations: https://htmx.org/examples/animations/ happy to answer questions

I've heard of Intercooler before and saw htmx on Github trending a few weeks ago. A question about this example: https://htmx.org/examples/inline-validation/ This paradigm revolves around sending validation requests to server-side endpoints, is there any reason to put that load on the server rather than validate it on the page prior to submit with JS? Or scalability issues? Not being antagonistic, genuinely curious b…

The idea behind libs like htmx is that you get to have some of the niceties of a SPA, without writing any JS and requiring minimal computational power from the client.

Re: Htmx – high power tools for HTML

#35

Post by recursivedoubts »

digitaltrees wrote: post #25
recursivedoubts wrote: post #10

hello, I'm the creator of htmx (and originally intercooler) I just released 0.0.4, so htmx is still very young, but it's got a decent test suite: https://htmx.org/test/0.0.4/test/ there is a nice extension mechanism: https://htmx.org/extensions/ and some very rough docs on how to pull off pure HTML animations: https://htmx.org/examples/animations/ happy to answer questions

I like the name htmx better than kutty. Easier to remember and feels more official.

i liked kutty a lot, but it just meant too many things in too many other languages

lookin' at you, dutch

Re: Htmx – high power tools for HTML

#36

Post by benatkin »

recursivedoubts wrote: post #7
fastball wrote: post #6

For similar-goal prior-art, see Unpoly[1]. Also the IETF asks[2] that you please stop using "X-" to prepend your custom HTTP headers[3] [1] https://unpoly.com/tutorial [2] https://tools.ietf.org/html/rfc6648 [3] https://htmx.org/reference/#headers

I like unpoly a lot, Henning is a perfect gentleman, but the first check in on intercooler.js was before the first check in on unpoly: https://github.com/bigskysoftware/intercooler-js/graphs/cont... https://github.com/unpoly/unpoly/graphs/contributors I'm happy to change the headers htmx is young enough to get away with it. Would you like to issue a pull request?

I'm not sure about changing the headers. X- is a widely accepted convention. In the RFC also says this:

> SHOULD NOT prefix their parameter names with "X-" or similar constructs.

It doesn't spell out exactly what would be considered a "similar construct", but I think "HX-" might count as a similar construct.

There's no good way to implement the feature you want that would satisfy all reasonable interpretations of that RFC, so switching to "HX-" would be a half-measure.

I understood exactly what was meant by X-HX- and I think it's a good design.

Still, HX- is shorter and about as intuitive as X-HX- so I think it might still be the way to go, even though IMO that RFC isn't a good enough reason to change it.

Re: Htmx – high power tools for HTML

#37

Post by edko »

recursivedoubts wrote: post #35
digitaltrees wrote: post #25

Earlier quoted context omitted.

I like the name htmx better than kutty. Easier to remember and feels more official.

i liked kutty a lot, but it just meant too many things in too many other languages lookin' at you, dutch

I am sure you must be referring to someone from the Katholieke Universiteit Tilburg.

Re: Htmx – high power tools for HTML

#38

Post by fastball »

benatkin wrote: post #36
recursivedoubts wrote: post #7

Earlier quoted context omitted.

I like unpoly a lot, Henning is a perfect gentleman, but the first check in on intercooler.js was before the first check in on unpoly: https://github.com/bigskysoftware/intercooler-js/graphs/cont... https://github.com/unpoly/unpoly/graphs/contributors I'm happy to change the headers htmx is young enough to get away with it. Would you like to issue a pull request?

I'm not sure about changing the headers. X- is a widely accepted convention. In the RFC also says this: > SHOULD NOT prefix their parameter names with "X-" or similar constructs. It doesn't spell out exactly what would be considered a "similar construct", but I think "HX-" might count as a similar construct. There's no good way to implement the feature you want that would satisfy all reasonable interpretations of tha…

I think the spirit of the RFC is mostly about complications arising if such headers ever became standardized, but also that the "X-" just doesn't add any value – it's a convention without a purpose and just makes headers longer. In fact, it arguably becomes less useful the more people use it.

So I think it's better for new projects to drop the "X-".

On the other hand, I think it's reasonable to prepend with "HX-" because these headers apply to functionality that is specifically related to the capabilities of this library (or similar libs). It is highly improbable that this syntax would ever become standardized in either the HTML or HTTP specs, but if it did, the HX in front of headers makes sense given that the tag attributes are also prepended with an HX.

From an entirely stylistic perspective, I also think that shoving an "X-" in front of all your headers is ugly (ugliness can of course be justified by usefulness, but as stated above I don't think that applies here).

But of course these are just my thoughts on the matter, others might like "X-", though I'll admit I don't know why you would.

Post reply on HN