3 ms·

The core assumption of stacks like htmx is that you don't need fine-grained client-side interactions implemented in custom Javascript; that when you need the UI

The core assumption of stacks like htmx is that you don't need fine-grained client-side interactions implemented in custom Javascript; that when you need the UI to change, it's ok to go through the server. An example edge case where this fails completely is a canvas-based interactive game, where you (a) cannot "ask the server for html" in order to update your game UI and (b) going through the server for every UI update is unacceptable for performance. That said, people are realizing that in a very large percentage of practical cases (i.e., CRUD apps), you do not need the high fidelity of javascript and you can skip a lot of the related complexity by using simplified stacks. The big fail would be if you use htmx at first but over time you end up grafting a bunch of custom JS on top anyway, and your backend is a complicated Jinja mess, which is what made old school Rails/Django projects total messes and caused people turn to SPAs + JSON pumps. It probably takes some discipline to stick with pure htmx and push back on requests to graft random crap on top.

midrus 5y ago
You still can write client side only JavaSCript with Unpoly compilers, alpine.js, and probably htmx also has a way to add custom javascript without making jquery spaghetti. A tool like this that rely on server rendering (or livewire, hotwire, etc) is a perfect replacement for when your user interaction will need to reach to the server anyway (to save data or fetch something, etc). For example, you're not forced to go back to the server to display a modal. You can have it already rendered on beforehand and when clicking a given button just toggle its visibility. Or if you want to mark a todo item as "done" you can just apply the "done" styles with alpine.js or similar and make an async call to the backend that will persist the state, etc. Going full "SPA" just because this is less ideal than state based react, etc does not compensate the overhead of everything else involved in any web application (SEO support, translations, security, authentication, etc) which are incredibly complicated to get right with SPAs.
recursivedoubts 5y ago
Yes. Like any application architecture, the Hypermedia Driven Application architecture has strengths and weaknesses. In the case you outline, a canvas-based application, a hypermedia driven application is not going to be a good choice. However, that being said, it may be a good choice for parts of your application (e.g. the settings page.) Thankfully many SPA libraries are now embedable within an broader application, so you can use that approach when it fits best, and other, simpler approaches in other parts of your application.
- realrocker 5y ago
  Agreed. I have been playing with the idea of escaping to use svelte in spots for finer interactions : https://github.com/adnaan/gomodest-template https://github.com/adnaan/gomodest-template

midrus 5y ago

You still can write client side only JavaSCript with Unpoly compilers, alpine.js, and probably htmx also has a way to add custom javascript without making jquery spaghetti. A tool like this that rely on server rendering (or livewire, hotwire, etc) is a perfect replacement for when your user interaction will need to reach to the server anyway (to save data or fetch something, etc). For example, you're not forced to go back to the server to display a modal. You can have it already rendered on beforehand and when clicking a given button just toggle its visibility. Or if you want to mark a todo item as "done" you can just apply the "done" styles with alpine.js or similar and make an async call to the backend that will persist the state, etc. Going full "SPA" just because this is less ideal than state based react, etc does not compensate the overhead of everything else involved in any web application (SEO support, translations, security, authentication, etc) which are incredibly complicated to get right with SPAs.

recursivedoubts 5y ago

Yes. Like any application architecture, the Hypermedia Driven Application architecture has strengths and weaknesses. In the case you outline, a canvas-based application, a hypermedia driven application is not going to be a good choice. However, that being said, it may be a good choice for parts of your application (e.g. the settings page.) Thankfully many SPA libraries are now embedable within an broader application, so you can use that approach when it fits best, and other, simpler approaches in other parts of your application.

realrocker 5y ago
Agreed. I have been playing with the idea of escaping to use svelte in spots for finer interactions : https://github.com/adnaan/gomodest-template https://github.com/adnaan/gomodest-template