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

141–150 of 175 posts

Re: Htmx – high power tools for HTML

#141

Post by giancarlostoro »

zambal wrote: post #121
madeofpalk wrote: post #108

Earlier quoted context omitted.

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

It defines css classes for most css properties. Their website [1] explains why you might want that pretty well. Regarding file size, the idea is that you use something like PurgeCSS in your build pipeline, which removes all unused css classes. A bit like tree shaking for css. [1] https://tailwind.css

Additionally so you can open up the developer tools, and just slap on classes on divs and experiment a bit quicker.

Towards the end you can put it all together and trim it down, not sure if there's tooling that auto joins some of the CSS as necessary though.

Re: Htmx – high power tools for HTML

#142

Post by learc83 »

vosper wrote: post #79
hliyan wrote: post #76

Earlier quoted context omitted.

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

If you take a few minutes to build seperate endpoints, you'd get better performance. Both in latency/bandwidth and in system resources for your DB query.

Re: Htmx – high power tools for HTML

#143

Post by recursivedoubts »

andybak wrote: post #109
recursivedoubts wrote: post #61

Earlier quoted context omitted.

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.

thank you andy, i have always appreciated your positive feedback on intercooler :)

Re: Htmx – high power tools for HTML

#144

Post by nogabebop23 »

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…

Sending back HTML is kind of the point though. The idea is lots of sites built on frameworks (Rails, .NET, Java) already do HTML rendering server-side, so now you can get SPA-like UI without backend changes. If you've got a REST backend (which the former generally don't) I would use one of the many popular client side frameworks. Using HTMX or intercooler or unpoly, doesn't make a lot of sense in this scenario.

Re: Htmx – high power tools for HTML

#145

Post by nogabebop23 »

vosper wrote: post #79
hliyan wrote: post #76

Earlier quoted context omitted.

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

What's the difference between building seperate code paths on the client vs. 2 server endpoints though? Very few scenarios can't afford the behind-the-scenes extra http round trip...

Re: Htmx – high power tools for HTML

#146

Post by nogabebop23 »

capableweb wrote: post #102
SrslyJosh wrote: post #97

Earlier quoted context omitted.

> 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 fram…

THat's how you negotiate the content type; the original question was how they have a service returning json return html. I've never heard of a framework that can arbitrarily convert data into HTML - how would that even work?

Re: Htmx – high power tools for HTML

#147

Post by wenc »

nogabebop23 wrote: post #144
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…

Sending back HTML is kind of the point though. The idea is lots of sites built on frameworks (Rails, .NET, Java) already do HTML rendering server-side, so now you can get SPA-like UI without backend changes. If you've got a REST backend (which the former generally don't) I would use one of the many popular client side frameworks. Using HTMX or intercooler or unpoly, doesn't make a lot of sense in this scenario.

I think that even if a server returns HTML, on the client-side we'd typically like to retain the flexibility to style/restyle/rearrange elements it to fit the current layout. The same response could be used in multiple places with different styles.

What other client-side UI frameworks do you recommend? I'm liking what I'm seeing with HTMX due to its small size and simplicity.

Re: Htmx – high power tools for HTML

#148

Post by wenc »

SrslyJosh wrote: post #97
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…

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

> Those exist?

For sure. Most of the backends we write only return JSON. If you request HTML or any other content-type, we return nothing. We just don't implement it.

If you write your backend from scratch and only intend for it to be used only with your web front-end, you can make it return bits of HTML (I have several applications in jQuery that work like this -- the value of the response just gets inserted via ("#id").html(val)).

Our current backends are written to support multiple generic consumers of which a web front-end is only one.

Re: Htmx – high power tools for HTML

#149

Post by recursivedoubts »

wenc wrote: post #147
nogabebop23 wrote: post #144

Earlier quoted context omitted.

Sending back HTML is kind of the point though. The idea is lots of sites built on frameworks (Rails, .NET, Java) already do HTML rendering server-side, so now you can get SPA-like UI without backend changes. If you've got a REST backend (which the former generally don't) I would use one of the many popular client side frameworks. Using HTMX or intercooler or unpoly, doesn't make a lot of sense in this scenario.

I think that even if a server returns HTML, on the client-side we'd typically like to retain the flexibility to style/restyle/rearrange elements it to fit the current layout. The same response could be used in multiple places with different styles. What other client-side UI frameworks do you recommend? I'm liking what I'm seeing with HTMX due to its small size and simplicity.

with htmx you can send out of band content down that will be swapped in by id:

https://htmx.org/attributes/hx-swap-oob/

you can also select content by a selector:

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

and there is infrastructure for general response transformations via the extensions mechanism:

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

See the source code here:

https://unpkg.com/htmx.org@0.0.4/dist/ext/client-side-templa...

Re: Htmx – high power tools for HTML

#150

Post by ksec »

I wish some of this ( or All of it ) are implemented inside browser and no longer need any Javascript to function.

Web App still has its place. But 90% of the web are Web Pages or Interactive Web Page, not Apps. While Every time I point this out there will be someone stating Gmail as an example of Web Apps, but we will soon have Hey.com to prove it doesn't need to be that way.

However browser vendors and standards body ( Which really is just browser vendors ) has far too much interest in making the Web or Web Browser as another OS / Platform. Rather than optimising for the 90% of our current use case.

Post reply on HN