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:
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:
"Note that when you are using htmx, on the server side you respond with HTML, not JSON. This keeps you firmly within the original web programming model, using Hypertext As The Engine Of Application State without even needing to really understand that concept."
I would love to use this with existing REST backends, but most are only able to return JSON. How does one use this for AJAX without rewriting existing backends?
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.
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.
Indeed, using tailwind without some build pipeline is not recommended. You'd use something like PurgeCSS to remove all unused css classes. Which admittedly kind of defeats the whole idea of keeping it simple.
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.
id imagine that you get a lot of rules when you have a whole bunch of different "margin-top-<x>". the idea is probably to rely on some CSS tree-shaking/"dead CSS elimination" tool to only keep the ones you need
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
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.
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...
Because I don't want to build and maintain an API endpoint to give me an HTML blob for the users age, and another one for their full name, and another one just for their first name, and another one for figuring out what day of the year is their birthday. I want adding these features to my UI to be a client-side-only change.
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.
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.
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.
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?
I was part of a project that when I just joined it, RESTful APIs together with fat frontend clients was becoming the hot-new-thing. The application was originally returning text/html (templates) to be injected in various part of the frontend, at request-time.
To migrate to our flashy new Angular V1 application, we added a application/json content-type that instead of returning the template, returned the data that the template used. So we could endpoint-by-endpoint migrate to the SPA we were building.
Was simply a matter of making the data required for the views a bit more advertised internally, so the controllers could instead not render the views when the content-type is json.
You could dynamically create HTML that mirrored a JSON response. You'd just have to have to walk the JSON structure and create a structure for where the key and the value from the JSON end up. Each node could just be a <div>. The ID could be a composition of the key and the parent nodes/keys so that it'd be unique. You could also stuff both values in a data-* attribute.
It wouldn't be the prettiest HTML but you could work with it via CSS and JS.
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.
Sure but it’s extra engineering time (tiny per instance yes but multiplied over many legacy apps with no value add — not an easy business case to make just to use a html based front end library.)
Much easier to use client-side templating as suggested by the author.
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:
"Note that when you are using htmx, on the server side you respond with HTML, not JSON. This keeps you firmly within the original web programming model, using Hypertext As The Engine Of Application State without even needing to really understand that concept."
I would love to use this with existing REST backends, but most are only able to return JSON. How does one use this for AJAX without rewriting existing backends?