4 ms·

On one hand, I like the simplicity of it. On the other, I fear it’s a backward move. We loose access to data as, well, data. If you get data from the backend it

On one hand, I like the simplicity of it. On the other, I fear it’s a backward move. We loose access to data as, well, data. If you get data from the backend it can be rendered in different ways by the front end. You loose that flexibility with HDA.

southerntofu 5y ago
It appears HTMX supports non-HTML APIs. The json-enc extension encodes <form> fields as JSON, and client-side-templates allows templating from JSON (and others) API responses. Now, take my words with a grain of salt because i'm unaware of the details, but i don't see a reason HTMX couldn't support XML with proper schemas which would be great: - for structured/typed data and ensuring proper API protocol negotiation between client and server - for data structures closer to the DOM model (which has both fields and children for most elements, while a JSON key can point to a list or an object, not both) - for serialization formats the browser knows about and is optimized for - for interoperability with other systems/protocols based on XML schemas, such as XMPP Data can be served in many forms. Your API could be a DNS key-value server, or a JSON endpoint, or a HTML page. Just because most people don't structure their HTML semantically doesn't mean it can't (or shouldn't) be done, which means you don't loose "access to data as data". On the contrary, designing your API as semantic/structured HTML empowers users to parse/script your website to better suit their needs, whether that's for accessibility purposes or for developing 3rd party clients. Something that's become almost impossible in the age of SPAs and CAPTCHAs imposing the developer's will on my browsing experience.
sdze 5y ago
You lose nothing. You just tell the backend by accept header what you expect it to return.
recursivedoubts 5y ago
I recommend splitting your hypermedia and your data APIs up, because they end up having very different usage patterns: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/

southerntofu 5y ago

It appears HTMX supports non-HTML APIs. The json-enc extension encodes <form> fields as JSON, and client-side-templates allows templating from JSON (and others) API responses. Now, take my words with a grain of salt because i'm unaware of the details, but i don't see a reason HTMX couldn't support XML with proper schemas which would be great: - for structured/typed data and ensuring proper API protocol negotiation between client and server - for data structures closer to the DOM model (which has both fields and children for most elements, while a JSON key can point to a list or an object, not both) - for serialization formats the browser knows about and is optimized for - for interoperability with other systems/protocols based on XML schemas, such as XMPP Data can be served in many forms. Your API could be a DNS key-value server, or a JSON endpoint, or a HTML page. Just because most people don't structure their HTML semantically doesn't mean it can't (or shouldn't) be done, which means you don't loose "access to data as data". On the contrary, designing your API as semantic/structured HTML empowers users to parse/script your website to better suit their needs, whether that's for accessibility purposes or for developing 3rd party clients. Something that's become almost impossible in the age of SPAs and CAPTCHAs imposing the developer's will on my browsing experience.

sdze 5y ago

You lose nothing. You just tell the backend by accept header what you expect it to return.

recursivedoubts 5y ago

I recommend splitting your hypermedia and your data APIs up, because they end up having very different usage patterns: https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/splitting-your-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/ https://htmx.org/essays/hypermedia-apis-vs-data-apis/