3 ms·

When fetching from the backend, the docs recommend returning snippets of html instead of JSON. Is it technically valid to return a snippet of HTML with a conten

When fetching from the backend, the docs recommend returning snippets of html instead of JSON. Is it technically valid to return a snippet of HTML with a content type of “text/html”? There’s no standards saying you need !DOCTYPE or a head or body?

richdougherty 4y ago
I guess it's not valid, although the impact might be that big if it's only you calling your own endpoints. If you want to be really correct you could use your own content type under the vendor tree: https://www.rfc-editor.org/rfc/rfc6838#section-3.2 https://www.rfc-editor.org/rfc/rfc6838#section-3.2. E.g. Content-type: application/vnd+yourorg.htmlx+html-snippet
- devmunchies 4y ago
  Some discussion here https://stackoverflow.com/questions/19303361/content-type-for-html-fragments https://stackoverflow.com/questions/19303361/content-type-fo... Basically that nowadays it’s fine to use text/html for html fragments, because the content is still html, even if it’s not a full document.
tetraca 4y ago
Regardless of whether it is standard or not I've definitely worked on sites that worked this way back in the day. Smarty+PHP would generate the beef of the page, then certain components of the page would be pulled in using Ajax requests as the user did things. The browser would not care.
- Beltalowda 4y ago
  I still write sites like this. I realize this is not "the way" to do things today by many, but I find it works quite well and it avoids a lot of complexity. I think the "classic" web-apps were given a bit of an undeserved bad rep because a lot were written in bad PHP and bad JavaScript, and people conflated that with "this entire approach is wrong".
ryanbrunner 4y ago
I'm not familiar with htmx, but the approach I use in Rails with turbo is to return a full page, and then use a subset of that page for what I replace client side. This has a nice property that you can get it working as progressive enhancement, where the site still functions perfectly well without Javascript.

richdougherty 4y ago

I guess it's not valid, although the impact might be that big if it's only you calling your own endpoints. If you want to be really correct you could use your own content type under the vendor tree: https://www.rfc-editor.org/rfc/rfc6838#section-3.2 https://www.rfc-editor.org/rfc/rfc6838#section-3.2. E.g. Content-type: application/vnd+yourorg.htmlx+html-snippet

devmunchies 4y ago
Some discussion here https://stackoverflow.com/questions/19303361/content-type-for-html-fragments https://stackoverflow.com/questions/19303361/content-type-fo... Basically that nowadays it’s fine to use text/html for html fragments, because the content is still html, even if it’s not a full document.

tetraca 4y ago

Regardless of whether it is standard or not I've definitely worked on sites that worked this way back in the day. Smarty+PHP would generate the beef of the page, then certain components of the page would be pulled in using Ajax requests as the user did things. The browser would not care.

Beltalowda 4y ago
I still write sites like this. I realize this is not "the way" to do things today by many, but I find it works quite well and it avoids a lot of complexity. I think the "classic" web-apps were given a bit of an undeserved bad rep because a lot were written in bad PHP and bad JavaScript, and people conflated that with "this entire approach is wrong".

ryanbrunner 4y ago

I'm not familiar with htmx, but the approach I use in Rails with turbo is to return a full page, and then use a subset of that page for what I replace client side. This has a nice property that you can get it working as progressive enhancement, where the site still functions perfectly well without Javascript.