Live data from Hacker News

Htmx – high power tools for HTML

htmx.org

81–90 of 175 posts

Re: Htmx – high power tools for HTML

#81
post #77

The example on the front page already hints at the type of bad programming this may encourage. When clicked, the button sends a POST (this seems ok), and then the backend sends new html for the button. The idea of having random snippets of your frontend markup being returned from api servers seems questionable.

There is an extension (which is part of the main repo) that supports using front-end templates to consume JSON from a back-end. Looks just as simple as the replace feature. See: https://htmx.org/extensions/client-side-templates/

Re: Htmx – high power tools for HTML

#82
post #80
post #77

The example on the front page already hints at the type of bad programming this may encourage. When clicked, the button sends a POST (this seems ok), and then the backend sends new html for the button. The idea of having random snippets of your frontend markup being returned from api servers seems questionable.

I'm not sure I get what you're saying? I think you're saying that having html returned from the backend "seems questionable" and is a "type of bad programming". But that can't be right because that's mostly how the web works? Make a request to a server, server returns html. Is your issue that it's partial "random" content? How does that make it worse? It's a tried and true solution. The hamburger menu in amazon.com d…

I agree that the objection doesn't hold up given how many websites are made, but I think they mean that a REST API shouldn't be returning HTML, which is true. Unfortunately using the replace feature would mean rewriting existing APIs.

Or, you could use the client side template feature of htmx which supports rendering JSON into HTML using a templating language: https://htmx.org/extensions/client-side-templates/

Re: Htmx – high power tools for HTML

#83
post #76
post #69

This looks amazing -- seems like you can accomplish a significant amount of what constitutes front-end work these days with htmx. The examples are compelling: https://htmx.org/examples/ There is a slight deal-breaker for me. Much of the functionality revolves around hx-swap'ing i.e. writing the contents of a response as HTML into/around tags. This requires the server-side to return HTML instead of JSON. From the docs…

On a related note, I recently discovered that when you use semantically styled HTML, the difference between a JSON payload and an HTML payload is almost negligible (basically, the close tags). Why not transmit in a format that the browser already understands natively?

Probably fine in some use cases. But another reason on top of what's already been said: Because you might be sending the data back to a non-browser client such as a mobile application.

Re: Htmx – high power tools for HTML

#84

Earlier quoted context omitted.

What ideas do you think didn't work out? Btw, I'm currently a very happy user of intercooler. Thanks for the awesome lib.

I think the implicit dependency system is a good example that ended up confusing people as much as it helped: http://intercoolerjs.org/docs.html#dependencies The fact that intercooler didn't have an extension mechanism meant I had to heap a lot of stuff into the core (e.g. ic-action) that was interesting and useful, but made the code base messy and unfocused. htmx has an extension mechanism, so you can pull in stuff…

really cool to hear insights from package creators, thanks for sharing

Re: Htmx – high power tools for HTML

#85
post #80

Earlier quoted context omitted.

I'm not sure I get what you're saying? I think you're saying that having html returned from the backend "seems questionable" and is a "type of bad programming". But that can't be right because that's mostly how the web works? Make a request to a server, server returns html. Is your issue that it's partial "random" content? How does that make it worse? It's a tried and true solution. The hamburger menu in amazon.com d…

I agree that the objection doesn't hold up given how many websites are made, but I think they mean that a REST API shouldn't be returning HTML, which is true. Unfortunately using the replace feature would mean rewriting existing APIs. Or, you could use the client side template feature of htmx which supports rendering JSON into HTML using a templating language: https://htmx.org/extensions/client-side-templates/

> REST API shouldn't be returning HTML, which is true.

No, it isn't. REST implies HATEOAS, and JSON isn't a hypertext.

Calling JSON APIs REST-ful was always a mistake.

http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

Re: Htmx – high power tools for HTML

#86
post #77

The example on the front page already hints at the type of bad programming this may encourage. When clicked, the button sends a POST (this seems ok), and then the backend sends new html for the button. The idea of having random snippets of your frontend markup being returned from api servers seems questionable.

Yeah, this is something you are going to have to wrap your head around and chew on for a bit. htmx is an extension of HTML (a generalization of it) rather than something you need to shoehorn into a JSON API-oriented world view.

It's just a different way of building web applications, much closer to the original web model. You can do a lot with it, with a lot less complexity in many cases.

I wrote some blog posts about this stuff for intercooler back in the day:

http://intercoolerjs.org/2016/01/18/rescuing-rest.html

http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

Re: Htmx – high power tools for HTML

#87
post #76
post #69

This looks amazing -- seems like you can accomplish a significant amount of what constitutes front-end work these days with htmx. The examples are compelling: https://htmx.org/examples/ There is a slight deal-breaker for me. Much of the functionality revolves around hx-swap'ing i.e. writing the contents of a response as HTML into/around tags. This requires the server-side to return HTML instead of JSON. From the docs…

On a related note, I recently discovered that when you use semantically styled HTML, the difference between a JSON payload and an HTML payload is almost negligible (basically, the close tags). Why not transmit in a format that the browser already understands natively?

yeah, the payload is almost zero difference, a round off error compared w/ connection latency

a lot of folks conflate AJAX w/ JSON apis, and can't easily imagine an endpoint returning partial bits of HTML that have nothing to do with a public JSON API

worse, people have been misled to believe that JSON APIs are REST-ful

we have a lot of work to do

Re: Htmx – high power tools for HTML

#88

Earlier quoted context omitted.

I wanted the freedom to completely reimplement things and drop ideas that didn't work out in intercooler I also wanted to stress that htmx isn't just another javascript library, competing with react and the rest. It is focused on HTML and extending HTML to make it a powerful and complete hypertext. I think that the name htmx captures that idea pretty well.

Do you believe in equal access for no-JS?

as much as is practical

https://htmx.org/attributes/hx-boost/

Re: Htmx – high power tools for HTML

#89

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

thank you

Re: Htmx – high power tools for HTML

#90
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

Unpoly examples wrecked my back button. Had to click back like 15 times to get back to HN... Is this a permanent issue because of the way it’s implemented?
Post reply on HN