I think a competent 5yro could make a better pelican on a bicycle than that. Which to me feels like the hallmark of AI.
I mean, hell, I have drawings from when I was eight of leaves and they are botanically-accurate enough to still be used for plant identification, which itself is a very difficult task that people study decades for. I don't see why this is interesting or noteworthy, call me a neo-luddite if you must.
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.
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.
How would that work? If I’m readying it right, there are client side actions that need to mutate the html, that have no server side component at all, and you wouldn’t want to round trip because the latency would be too annoying anyway.
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.
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.
https://g.co/gemini/share/ffa5a7cd6f46