At first, this was true but now it has gotten pretty good. The times it gets things wrong are often not the models fault and just google searches fault.
There is such a strong narrative against Google currently. It's really interesting seeing goalpost move and excuses made for this latest leaderboard. The fact of the matter is Google, openAI and anthropic all have excellent models with similar capabilities.
You can make use of htmx-indicator to show that the request is ongoing. From my perspective you have to be careful here. If you are _too_ optimistic and imply a request has been successfully sent to the DB when it really hasn't then users are not going to like that as their requests disappear.
You don't have to hydrate the html as events get triggered from "hx-" attributes on the elements as rendered server side. htmx takes care of it for you.
Again I don't know if it is the best for their current use case but you could probably make something that is quite elegant in htmx.
There are a few actions that are exclusively client side, like opening a context menu, that I'd use a "sprinkle of JavaScript". There is a recently added htmx attribute "hx-on" that might work well for those cases.
I'd also not discount doing a round trip for some of that. Those GET requests can be very fast and will be cached. Given the poor performance of many SPA's a quick, cache-able GET request might look pretty good.
htmx is built to mutate html from the backend based on server side events. I'm not going to say it is better or worse than svelte for your use case but how you are describing it here is selling it short. I suspect you could make a decent files app with htmx and a sprinkle of JavaScript.
As per your development process, if you use htmx you can serve the template files from disk. Then all you need to do is edit the html templates which your backend reads in. No need to rebuild your golang application. For some changes you wouldn't have to reload the page just click the interaction to get the html fragment from the server.
You would need to rebuild your go application if you are changing parameters input into the template but that is conceptually the same as a client side template needing an API change. This also requires a rebuild.
I've been building a golang app that serves html via the go standard library template system. It works really well. You can define and execute templates inline so you can define entire pages in html and then wrap a "block" around any reusable bit that you want to serve up dynamically.
I love the model. I've been writing a golang app with the standard library template system and it works really well.
One bit I've found slightly unintuitive is the swap and settled states. Took my a while to animate in a sidebar how I wanted. It was my fault for not groking it faster but perhaps some more examples or guides in that regard could be useful.
SPAs make tons backend calls to get data. This isn't particularly different. To me the main difference is it is hard to build an offline app out of htmx as compared to a SPA but so few webapps are offline anyway...
https://g.co/gemini/share/ffa5a7cd6f46