Wim Deblauwe

Congratulations to the winners!

That is correct Tim

Not really. You can read https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-not-a-good-fit-if for some general guidelines.

Vaadin is a good alternative if your team is not interested in learning html and css and really wants to stay 100% in Java. But if you currently have frontend developers using html/css and JavaScript, then a templating engine that uses html and htmx for the interactivity is something they can learn. Doing everything in Java would probably scare them away too much

I don't know Flask or Django, so I don't know how to answer that.

In any case, you can get a long way already with htmx using any backend technology that allows to return html (snippets). There is an interesting post at https://htmx.org/essays/when-to-use-hypermedia/#hypermedia-not-a-good-fit-if that explains more when htmx might not be a good fit for your project.

Not so sure if I understand your question correctly.

htmx could be regarded as a fancy wrapper around doing AJAX calls, but it brings a lot of convenience also around how the returned HTML is swapped back into the current page.

Maybe you can elaborate your question a bit more?

Interesting question that maybe warrants its own topic on the forum here.

For a non-rolling rollout case, htmx is easier regarding versioning. The server just sends the updated HTML to the browser. There is no chance that the old JavaScript application cannot talk to the updated server.

Although, in all honesty, there are scenario's thinkable that your browser loads a page, and before htmx does a request to fetch an html snippet to swap, the server is updated and that call is either not possible anymore, or the returned html is not structured in a way that makes sense for the html that is already in the browser. In that case, the user will have to do a page refresh or you could always send a version number with all htmx requests and the server could check that. If it notices the version is different, it can force the browser to do a full-page refresh using the HX-Refresh header.

However, for rolling rollouts, I am not sure, I have never had to work with them.

Hi,

About HTML as data exchange format:

"Sending data as HTML, on the other hand, implies a tighter coupling between the backend and frontend, as the backend pre-defines the presentation format. "

In fact, the inverse is true. With a JSON format, your frontend needs to be built for the data that is sent as you are missing a lot of information in most JSON Data API's (usually called REST APIs). There is no information on the other endpoints you can call for example. So in most cases, there is some out-of-band knowledge needed on the (JavaScript) frontend to make everything work.

With HTML, the full interaction is part of the HTML. There can be buttons and links in the HTML that allow further interaction, without the need of the client to know this. It just renders the HTML and everything works. There is no need to update 2 applications in lock-step.

This also avoids problems around versioning the REST API. The server just returns the new "version"/html in case of server-side rendering and the browser renders it. With a Single Page Application, you need to make sure the frontend is updated to deal with the updated REST API.

regards,

Wim

Hi Maarten,

Like Frank and Luca mentioned, htmx does not favor any backend. If you would join their discord server, you will see they have channels for just about any backend technology you can think about (Java, Kotlin, C#, PHP, Python, Go, ...).

regards,

Wim

Hi,

I think that is not really true. With microservices, you usually have a backend-for-frontend (BFF) that orchestrates the calls to the other microservices and prepares the JSON in an easy-to-use format for the Single Page Application. If you do server-side rendering, the BFF itself could be the server-side renderer in a microservices architecture.

regards,

Wim

I understand that this post is 2 years old, so maybe not relevant anymore. But if I would do this today, I would use https://htmx.org/. That way, you can use Thymeleaf fragments and avoid a lot of the JavaScript.

Why do you think you can't use a `th:block` inside another? That should work fine.

I asked ChatGPT to translate it and it came up with this which seems very reasonable. I could not test it since I don't have your backend, but maybe it will help you along. It certainly _looks_ reasonable at first sight:

<table class="table table-bordered" cellspacing="0">   <tbody>       <tr>           <th:block th:each="day : ${T(your.package.Days).values()}">               <td colspan="3" th:text="${day.getDay()}"></td>           </th:block>       </tr>       <tr>           <th:block th:with="count=${obj.getStartDay() - 1}">               <th:block th:each="d : ${#numbers.sequence(1, obj.getStartDay() - 1)}">                   <td colspan="3"></td>               </th:block>               <th:block th:each="index, iterStat : ${#numbers.sequence(0, obj.getPlanningData().size() - 1)}">                   <th:block th:if="${iterStat.value % 7 == 0 and iterStat.index != 0}">                       </tr><tr>                   </th:block>                   <td style="width: 1%" th:text="${obj.getPlanningData().get(index).get(1)}"></td>                   <td style="width: 3%">                       <input type="checkbox" class="form-control" th:id="'iu' + obj.getPlanningData().get(index).get(1)" th:name="iu" onclick="loadUsers(this.id);" />                   </td>                   <td>                       <input type="text" class="form-control small-font" th:id="'i_' + obj.getPlanningData().get(index).get(1)" th:name="${obj.getPlanningData().get(index).get(1)}" th:value="${obj.getPlanningData().get(index).get(3)}" />                   </td>               </th:block>           </th:block>       </tr>   </tbody> </table>

Feel free to ask a specific follow-up question if there is still something that is not working.

I wonder if the changes that you need to do can be done in CSS only. If that is the case, you could conditionally load different CSS files depending on a model attribute you set in the controller. That way, you can have 1 controller with just 2 methods that delegate to a single private method with the actual controller logic without duplication.

Something like this:

@Controller class MyController {  @GetMapping("/url1")  public String pageViaUrl1(Model model) {    model.addAttribute("cssLink", "application.css");    return renderPage(model);  }  @GetMapping("/url2")  public String pageViaUrl1(Model model) {    model.addAttribute("cssLink", "alternative.css");    return renderPage(model);  }  private String renderPage(Model model) {    // Maybe some more logic here to populate the model for the page    return "page";  } }

In your Thymeleaf template, use the `cssLink` variable to point to the CSS file.