Comment by kjksf | Hacker News Reader

Comment by kjksf | Hacker News Reader

Parent Full thread

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.

My iteration loop is basically nothing.

Over many iterations, that all adds up.

Don't think you need to kill go server unless you've templates embedded into the binary itself.

Also, even if serve returns HTML as list of files instead of JSON, HTML can be seen as a flexible data format in itself that has few added advantages.

JSON is superfluous when the only consumer is the browser based UI and no third party is going to have that response ever.

so then you send HTML to the client, but then you still have to 'hydrate' it to make it interactive. and now you've reinvented React SSR.

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.

So where are the event listeners then? On the body tag, and they bubble up and then examine the hx attribute? Is that how it works?

You can do most of these things with html and browser dev tools.

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.

It kind of seems you are discrediting HTMX based on Go's lack of hot reloading on the backend.

Not going to debate you line by line, but HTMX doesn't prevent you from using client-side JS, for example to create your right-click context menus.

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?

Reply on news.ycombinator.com