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

71–80 of 175 posts

Re: Htmx – high power tools for HTML

#71

Post by giancarlostoro »

recursivedoubts wrote: post #70
wenc wrote: 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…

You could check out the client side templates extension: https://htmx.org/extensions/client-side-templates/

This is great, I am definitely considering using this for some of my side projects so I don't spend hours with JS just to display some JSON output as HTML.

Re: Htmx – high power tools for HTML

#73

Post by wenc »

recursivedoubts wrote: post #70
wenc wrote: 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…

You could check out the client side templates extension: https://htmx.org/extensions/client-side-templates/

Thanks! This is what I need.

Re: Htmx – high power tools for HTML

#76

Post by hliyan »

wenc wrote: 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?

Re: Htmx – high power tools for HTML

#77

Post by woah »

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.

Re: Htmx – high power tools for HTML

#78

Post by forgotmypw17 »

recursivedoubts wrote: post #49
combatentropy wrote: post #43

Earlier quoted context omitted.

I have a lot of respect for intercooler and wish something like it had become the go-to, with more complicated things like React reserved for apps that really need it. I'm curious why you are starting over. What is different from intercooler besides no need for jQuery? Why HTMX instead of Intercooler 2.0?

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?

Re: Htmx – high power tools for HTML

#79

Post by vosper »

hliyan wrote: post #76
wenc wrote: 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?

Because oftentimes you’re retrieving data that will be stored in one central store and displayed / used in different ways in various components. Eg I might fetch user data and sometimes display their name, maybe another time compute their age from their birthdate, etc...

Re: Htmx – high power tools for HTML

#80

Post by latch »

woah wrote: 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 does just that.

Post reply on HN