It's a combination of capabilities and productivity.
To use a concrete example from another app I built: it's a web-based file browser for S3 (think Norton Commander for S3 on the web).
You enter S3 creds and my backend code gets a list of files and sends to the client as JSON. I generate UI (HTML) from that JSON.
Could the backend generate that HTML? Not really, because it's not just a static list.
It's a sophisticated file browser. The user can double-click to "enter" a directory, navigate the list of files with a keyboard, right click to get context menu with options to delete, rename files etc.
My UI (HTML) needs to be mutated and it's not even possible to offload those kinds of things to the backend because they are driven by the state in the client (mouse movements, keyboard events, scroll events etc.).
That's the capability part: a lot of things can only be done in the client.
As to productivity: even if the needs are not as sophisticated, my productivity in Svelte is off the charts.
Let's say you just generate static HTML for the list of files.
Generating HTML is a very iterative process: you start with the basic structure, you try it and then you tweak the CSS to make it look better.
Since my backends are in Go, changing a single line of Go code requires killing the server, rebuilding it and restarting it and since I lost all the state, re-doing all the steps needed to get to a page I'm working on.
My iteration loop per single change is minutes and very annoying.
With Svelte I have an amazing HTML templating language and with HMR (Hot Module Reload) I often don't even have to refresh the page: I change my .svelte file to, say, add a class to <td> element, I save it in Visual Studio Code and the page get magically refreshed with new visuals, without loosing the state.
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.
Thanks for sharing, I'm interested in hearing more about your approach here. Do you go:embed to add the production svelte assets to your Go binary or do you ship both as separate apps and/or involve a CDN?
To use a concrete example from another app I built: it's a web-based file browser for S3 (think Norton Commander for S3 on the web).
You enter S3 creds and my backend code gets a list of files and sends to the client as JSON. I generate UI (HTML) from that JSON.
Could the backend generate that HTML? Not really, because it's not just a static list.
It's a sophisticated file browser. The user can double-click to "enter" a directory, navigate the list of files with a keyboard, right click to get context menu with options to delete, rename files etc.
My UI (HTML) needs to be mutated and it's not even possible to offload those kinds of things to the backend because they are driven by the state in the client (mouse movements, keyboard events, scroll events etc.).
That's the capability part: a lot of things can only be done in the client.
As to productivity: even if the needs are not as sophisticated, my productivity in Svelte is off the charts.
Let's say you just generate static HTML for the list of files.
Generating HTML is a very iterative process: you start with the basic structure, you try it and then you tweak the CSS to make it look better.
Since my backends are in Go, changing a single line of Go code requires killing the server, rebuilding it and restarting it and since I lost all the state, re-doing all the steps needed to get to a page I'm working on.
My iteration loop per single change is minutes and very annoying.
With Svelte I have an amazing HTML templating language and with HMR (Hot Module Reload) I often don't even have to refresh the page: I change my .svelte file to, say, add a class to <td> element, I save it in Visual Studio Code and the page get magically refreshed with new visuals, without loosing the state.
My iteration loop is basically nothing.
Over many iterations, that all adds up.