Live data from Hacker News

Htmx – high power tools for HTML

htmx.org

101–110 of 175 posts

Re: Htmx – high power tools for HTML

#101
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/

> a REST API shouldn't be returning HTML

Why do you think so? It might interest you to know that Roy Fielding defined REST before JSON was invented.

Re: Htmx – high power tools for HTML

#102
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…

> How does one use this for AJAX without rewriting existing backends? I've never actually used a backend that couldn't return arbitrary content types. Those exist?

This is exactly the use-case for Content-Type and Accept headers. The client and server negotiates what type of content they can receive/send, so if you're sending application/json as the Accept header, you can only handle application/json, if you only send text/html in the header, then only HTML. If the client understands both, you do application/json,text/html. with the order signalling preference.

Any serious framework would be able to handle this without any hiccups.

Re: Htmx – high power tools for HTML

#103
The js via html tags is something I see also in Alpine.js, which has gotten a lot of press lately.

Is this an alternative, or is each really its own niche (and you might use both)? Is there a comparison?

Edit: It seems that htmx is almost entirely around AJAX, and Alpine around a) binding element data to objects and b) css & animations (such as hiding a popup). It would make a lot of sense to use them together (and the hx- even complements the x-). Is that correct?

Re: Htmx – high power tools for HTML

#104
post #96
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

My upvote for Unpoly. Used it in severa projects and it's awesome. Only drawback I've found so far is that the source is CoffeScript, so it might be a bit harder to read the internals when necessary. But In my opinion it gets a lot of things right, specially around form submissions, validation, error handling, modals, history, navigation, passive updates, etc. It is like Turbolinks++.

I love Unpoly!

But them using CoffeScript is the only reason for why I've not contributed to Unpoly even though I've found both bugs and stuff I'd like improved :/

Re: Htmx – high power tools for HTML

#105
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?

Pushing history state is the default, but it can be configured as needed on a case by case basis.

Re: Htmx – high power tools for HTML

#106
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.

Woah I think this is misinformed on a very fundamental level, and I really would like to clarify where this idea is coming from (is it from a "modern" React or other JS-first bootcamp line of thought by chance? Not trolling, but genuinely interested). The entire point of the original web is that you send HTML to a browser rather than JS snippets or JSON payloads, and that you compose your documents from HTML fragments. "API servers" and RPC were concepts from before HTML, and the web as an app platform was welcomed for leaving granular request/response roundtrips behind and compose accessible and searchable HTML pages with really simple means (like shell scripts) on the server in the first place!

Re: Htmx – high power tools for HTML

#107
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?

[deleted]

Re: Htmx – high power tools for HTML

#108
post #92

Earlier quoted context omitted.

Add tailwind css or another utility class css framework and you can do the whole frontend in html :)

Yes, but you shouldn't use it as a simple drop-in. The minified version via CDN is like 1.7 MB ... at least they mention you should not use it in the docs and instead configure it to your needs.

tailwind is 1.7MB of CSS? ....whyy?

Re: Htmx – high power tools for HTML

#109

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…

Interesting.

I was a fan of intercooler and used it in production more than once but for some reason I could never get my head round the dependency functionality and ended up just ignoring it.

Intercooler works beautifully alongside Django and Django Rest Framework and I look forward to trying out htmx.

Re: Htmx – high power tools for HTML

#110

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

On the click-to-load example https://htmx.org/examples/click-to-load/ I see no network traffic when I click the 'load more agents' button. Am I missing something, where are the requests going?

For the docs they are faking server side (view source starting line 138 )
Post reply on HN