5 ms·

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 t

by woah 6y ago

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.

latch 6y ago
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.
- Thorentis 6y ago
  I agree that the objection doesn't hold up given how many websites are made, but I think they mean that a REST API shouldn't be returning HTML, which is true. Unfortunately using the replace feature would mean rewriting existing APIs. Or, you could use the client side template feature of htmx which supports rendering JSON into HTML using a templating language: https://htmx.org/extensions/client-side-templates/ https://htmx.org/extensions/client-side-templates/
  - recursivedoubts 6y ago
    > REST API shouldn't be returning HTML, which is true. No, it isn't. REST implies HATEOAS, and JSON isn't a hypertext. Calling JSON APIs REST-ful was always a mistake. http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...
  - inimino 6y ago
    > a REST API shouldn't be returning HTML Why do you think so? It might interest you to know that Roy Fielding defined REST before JSON was invented.
  - goto11 6y ago
    REST is the architectural style of the web, so returning HTML is the primary use case.
Thorentis 6y ago
There is an extension (which is part of the main repo) that supports using front-end templates to consume JSON from a back-end. Looks just as simple as the replace feature. See: https://htmx.org/extensions/client-side-templates/ https://htmx.org/extensions/client-side-templates/
recursivedoubts 6y ago
Yeah, this is something you are going to have to wrap your head around and chew on for a bit. htmx is an extension of HTML (a generalization of it) rather than something you need to shoehorn into a JSON API-oriented world view. It's just a different way of building web applications, much closer to the original web model. You can do a lot with it, with a lot less complexity in many cases. I wrote some blog posts about this stuff for intercooler back in the day: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...
tannhaeuser 6y ago
Woah I think this is misinformed on a very fundamental level, and I really would like to clarify where this idea is coming from (is it from a "modern" React or other JS-first bootcamp line of thought by chance? Not trolling, but genuinely interested). The entire point of the original web is that you send HTML to a browser rather than JS snippets or JSON payloads, and that you compose your documents from HTML fragments. "API servers" and RPC were concepts from before HTML, and the web as an app platform was welcomed for leaving granular request/response roundtrips behind and compose accessible and searchable HTML pages with really simple means (like shell scripts) on the server in the first place!
- woah 6y ago
  I've built web apps that didn't need much interactivity just using a regular ol vanilla web server sending html and then bootstrap.js for the menus, modals, etc. When a client wants the interactivity of a full-on application, I would use an application framework at that point. Using a system where the server needs to send back snippets of html for transitory states seems like you'd need to build yourself kind of a framework to handle the mechanics of that on the backend anyway. I'm not sure what the point is then. Sure, there is an asset in your project that is "just html" (the first loaded page), but you're going to need snippets of the interface's various states in different files so that the server can send them back. It's like this framework is pursuing an aesthetic goal of "just html" which breaks when you actually try to use it for the stuff that you'd use a framework for.
onion2k 6y ago
I don't think the idea of sending 'random' snippets of HTML to a browser and injecting them in to the DOM is inherently bad, and loads of frameworks have done exactly that in the past, but I would say that it does mean you have to be extremely good at managing your CSS. If something can be dropped in to the DOM anywhere where there's an hx attribute that could make managing the cascade specificity pretty tricky.

by woah 6y ago

latch 6y ago

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.

Thorentis 6y ago
I agree that the objection doesn't hold up given how many websites are made, but I think they mean that a REST API shouldn't be returning HTML, which is true. Unfortunately using the replace feature would mean rewriting existing APIs. Or, you could use the client side template feature of htmx which supports rendering JSON into HTML using a templating language: https://htmx.org/extensions/client-side-templates/ https://htmx.org/extensions/client-side-templates/
- recursivedoubts 6y ago
  > REST API shouldn't be returning HTML, which is true. No, it isn't. REST implies HATEOAS, and JSON isn't a hypertext. Calling JSON APIs REST-ful was always a mistake. http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...
- inimino 6y ago
  > a REST API shouldn't be returning HTML Why do you think so? It might interest you to know that Roy Fielding defined REST before JSON was invented.
- goto11 6y ago
  REST is the architectural style of the web, so returning HTML is the primary use case.

Thorentis 6y ago

There is an extension (which is part of the main repo) that supports using front-end templates to consume JSON from a back-end. Looks just as simple as the replace feature. See: https://htmx.org/extensions/client-side-templates/ https://htmx.org/extensions/client-side-templates/

recursivedoubts 6y ago

Yeah, this is something you are going to have to wrap your head around and chew on for a bit. htmx is an extension of HTML (a generalization of it) rather than something you need to shoehorn into a JSON API-oriented world view. It's just a different way of building web applications, much closer to the original web model. You can do a lot with it, with a lot less complexity in many cases. I wrote some blog posts about this stuff for intercooler back in the day: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.html http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

tannhaeuser 6y ago

Woah I think this is misinformed on a very fundamental level, and I really would like to clarify where this idea is coming from (is it from a "modern" React or other JS-first bootcamp line of thought by chance? Not trolling, but genuinely interested). The entire point of the original web is that you send HTML to a browser rather than JS snippets or JSON payloads, and that you compose your documents from HTML fragments. "API servers" and RPC were concepts from before HTML, and the web as an app platform was welcomed for leaving granular request/response roundtrips behind and compose accessible and searchable HTML pages with really simple means (like shell scripts) on the server in the first place!

woah 6y ago
I've built web apps that didn't need much interactivity just using a regular ol vanilla web server sending html and then bootstrap.js for the menus, modals, etc. When a client wants the interactivity of a full-on application, I would use an application framework at that point. Using a system where the server needs to send back snippets of html for transitory states seems like you'd need to build yourself kind of a framework to handle the mechanics of that on the backend anyway. I'm not sure what the point is then. Sure, there is an asset in your project that is "just html" (the first loaded page), but you're going to need snippets of the interface's various states in different files so that the server can send them back. It's like this framework is pursuing an aesthetic goal of "just html" which breaks when you actually try to use it for the stuff that you'd use a framework for.

onion2k 6y ago

I don't think the idea of sending 'random' snippets of HTML to a browser and injecting them in to the DOM is inherently bad, and loads of frameworks have done exactly that in the past, but I would say that it does mean you have to be extremely good at managing your CSS. If something can be dropped in to the DOM anywhere where there's an hx attribute that could make managing the cascade specificity pretty tricky.