4 ms·

I could definitely see something like intercooler boosting productivity. My only concern (possibly unfounded) is that you end up designing all of your server s

I could definitely see something like intercooler boosting productivity. My only concern (possibly unfounded) is that you end up designing all of your server side endpoints specifically in an intercooler fashion. All of your endpoints must now return an html snippet, which is specific to the design of the page. So you have a lot of page specific endpoints. This is in contrast to a REST api where the api can be designed largely independently of any one use case. If you ever need to switch away from intercooler you are going to have a large undertaking not just on the front end, but now on the back end as well. But I might be missing something.

edoceo 6y ago
When you migrate away from intercooler the new front-end is loading some data-api and some html-blocks from the old way. Move them out in increments. Intercooler is great for some cases and can make a good transition step moving from all server-side v1 to a fully responsive/dynamic v3
recursivedoubts 6y ago
Yeah, I would recommend adopting htmx (or intercooler) incrementally, where it adds the most value. And when it doesn't "feel right" for a particular use case, don't use it there. This minimizes your commitment to the approach and lets you use the right tool for whatever UX job you have at hand. EDIT: I should have read your comment more closely. With respect to two end points, one html and one JSON: I view the JSON and HTML end points as separate problems that both benefit from not being conflated with one another. Your HTML end points are tuned to the particular use cases for your UX (e.g. active search) with the caching and tuning required for your specific needs. The JSON end points need to be general and support unknown 3rd party client needs, and thus require more expressivity (e.g. GraphQL) at the cost of not being tuned for particular use cases. I tried to get this idea across in this older blog post: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/01/18/rescuing-rest.html
mattmanser 6y ago
If you don't need a rest API, all it does is make everything far more complicated, i.e. every page now has two end-points, one for the html, one for the data. It's trivial in most web frameworks to have an endpoint respond in two ways, one with all the html including head, menus, footers, etc. if you hit it with a GET, the other just the snippet if you hit it with an Ajax request. A REST API is basically a massive over-complication unless you actually need it for a good reason, say you're running both a web app and a mobile app from it. I've used this technique occasionally for over a decade and personally have always found this server-side approach very simple compared to juggling REST APIs with client-side rendering when a client or an existing code base demanded it. I've also always found the defence 'you might need to switch' to be a flimsy one. Usually when you do need to switch, everything is so different even your 'future-proof' API design needs a massive overhaul too because you made assumptions you didn't even realize you were making. Think of all those SOAP or XML APIs that were future proof...
- nightski 6y ago
  Fair points. A couple of notes though - intercooler needs two endpoints as well. One for the page, and another for any dynamic HTML. I mean I switched from jQuery to knockoutjs to react all on one application and the API served all those transitions well. So I'm speaking from personal experience here. But that is anecdotal and maybe it's not typical.
  - recursivedoubts 6y ago
    One pattern that I have used with some success is to reuse end points and use metadata that comes up with intercooler or htmx requests to determine the structure of the output. For example, if I have search functionality at /search and I'm implementing the active search pattern shown here: https://htmx.org/examples/active-search/ https://htmx.org/examples/active-search/ I'll re-use the /search url for the partial search results and check the HX-Request header to determine if I want to render the entire search UI or just the search results. If you use hx-push-url as well, you can get a search dialog that acts like an active search for the user, but also retains copy-and-paste-able URLs
  - deleted 6y ago
flukus 6y ago
> All of your endpoints must now return an html snippet, which is specific to the design of the page. So you have a lot of page specific endpoints. This is ok, adding an endpoint to spit out html is super simple, it's just printf statements with angle brackets. Beside that I find endpoints need to be somewhat coupled to the UI anyway, otherwise the endpoint needs to be a superset of all possible data and all the complications that come with that.

edoceo 6y ago

When you migrate away from intercooler the new front-end is loading some data-api and some html-blocks from the old way. Move them out in increments. Intercooler is great for some cases and can make a good transition step moving from all server-side v1 to a fully responsive/dynamic v3

recursivedoubts 6y ago

Yeah, I would recommend adopting htmx (or intercooler) incrementally, where it adds the most value. And when it doesn't "feel right" for a particular use case, don't use it there. This minimizes your commitment to the approach and lets you use the right tool for whatever UX job you have at hand. EDIT: I should have read your comment more closely. With respect to two end points, one html and one JSON: I view the JSON and HTML end points as separate problems that both benefit from not being conflated with one another. Your HTML end points are tuned to the particular use cases for your UX (e.g. active search) with the caching and tuning required for your specific needs. The JSON end points need to be general and support unknown 3rd party client needs, and thus require more expressivity (e.g. GraphQL) at the cost of not being tuned for particular use cases. I tried to get this idea across in this older blog post: http://intercoolerjs.org/2016/01/18/rescuing-rest.html http://intercoolerjs.org/2016/01/18/rescuing-rest.html

mattmanser 6y ago

If you don't need a rest API, all it does is make everything far more complicated, i.e. every page now has two end-points, one for the html, one for the data. It's trivial in most web frameworks to have an endpoint respond in two ways, one with all the html including head, menus, footers, etc. if you hit it with a GET, the other just the snippet if you hit it with an Ajax request. A REST API is basically a massive over-complication unless you actually need it for a good reason, say you're running both a web app and a mobile app from it. I've used this technique occasionally for over a decade and personally have always found this server-side approach very simple compared to juggling REST APIs with client-side rendering when a client or an existing code base demanded it. I've also always found the defence 'you might need to switch' to be a flimsy one. Usually when you do need to switch, everything is so different even your 'future-proof' API design needs a massive overhaul too because you made assumptions you didn't even realize you were making. Think of all those SOAP or XML APIs that were future proof...

nightski 6y ago
Fair points. A couple of notes though - intercooler needs two endpoints as well. One for the page, and another for any dynamic HTML. I mean I switched from jQuery to knockoutjs to react all on one application and the API served all those transitions well. So I'm speaking from personal experience here. But that is anecdotal and maybe it's not typical.
- recursivedoubts 6y ago
  One pattern that I have used with some success is to reuse end points and use metadata that comes up with intercooler or htmx requests to determine the structure of the output. For example, if I have search functionality at /search and I'm implementing the active search pattern shown here: https://htmx.org/examples/active-search/ https://htmx.org/examples/active-search/ I'll re-use the /search url for the partial search results and check the HX-Request header to determine if I want to render the entire search UI or just the search results. If you use hx-push-url as well, you can get a search dialog that acts like an active search for the user, but also retains copy-and-paste-able URLs
- deleted 6y ago

flukus 6y ago

> All of your endpoints must now return an html snippet, which is specific to the design of the page. So you have a lot of page specific endpoints. This is ok, adding an endpoint to spit out html is super simple, it's just printf statements with angle brackets. Beside that I find endpoints need to be somewhat coupled to the UI anyway, otherwise the endpoint needs to be a superset of all possible data and all the complications that come with that.