Golang and htmx is ready for production

[packs (Prakash)]

Dear all,

Anyone tried to use golang and htmx on production.

[James (James Wendel)]

This is a very generic question. HTMX is just a way of dealing with user interaction on the client side, how to send requests to the server, and how the server should respond. Golang has the template/html library, which handles reply to these requests just fine. If you do some searching, I’m guessing you can find plenty of examples of people using Go + HTMX.

[Karl]

I had a look at htmx.
I think it is definetely ready for production, but I can not understand the hype tbh.
Maybe I am too stupid to get the problem that it fixes, but I was kinda able to mimic htmx by a couple of lines with vanilla js when I tested it.

[Dean_Davidson]

@Karl

Maybe I am too stupid to get the problem that it fixes, but I was kinda able to mimic htmx by a couple of lines with vanilla js when I tested it.

I had the same exact response. I looked at it and was like “OK so kinda like every other front-end framework but with a different binding syntax and emphasis on server-side rendering??”. I searched “why use htmx” and I found stuff like this:

• Reactive components: htmx introduces a novel concept called “reactive components,” which allows efficient updates to the DOM without requiring a full page reload. This results in faster and more seamless interactions for users

Reactive components? Truly, we are living in the future. And further:

One of the reasons to use htmx is its ability to integrate HTML, CSS, and JavaScript into a single, cohesive library. This allows developers to create rich, interactive user interfaces that are easy to maintain and update.

How are React/Angular/Etc. apps not integrating HTML, CSS, and JavaScript into a single library?

But what about backend developers who love flexibility — for example, working with other server-side languages that are not influenced by JavaScript? htmx solves that by enabling you to render that HTML content and provide an SPA-like experience with whatever server-side language you choose.

Unless I am misunderstanding what makes this cool, I have been doing this since my days working with pre-Razor ASPX apps (that is: rendering a chunk of HTML on the server and incrementally updating my page instead of a full reload or using JavaScript to manipulate the DOM based on JSON responses).

Also - the idea that it’s “not JavaScript” I don’t understand. It looks like JavaScript to me. Again - it seems like a different binding syntax and a focus on server-side rendering. Not quite this paradigm shift it’s being billed as. And everybody blogging about it seems to be repeating the same thing without articulating why that thing is true.

[packs (Prakash)]

Thank for detailed explanation

[berkeleytrue (Berk Mars)]

I haven’t used it in production nor am I a full fledged go developer. I am a full stack javascript developer and I have worked and started many single page react apps. I think HTMX is probably a better choice to start with then at least 80% of apps built on a single page apps out there.

I have built an example app (Conduit, a Medium clone in the tradition of TodoMVC), and I find it really satisfying. It makes getting up and running real quick reduces complexity of combiling, bundling, shipping a javascript app.

I’d say the downside is that it requires sticking to some html principles that not everyone is super familiar with. For example, post/delete where the server responds with an error requires a different status code 302. htmx won’t react how you’d expect in this situation. This is something you’d run into early and one of the few things that might throw you off.

I also built the same app with a clojure backend and what I found in both cases is you spend way more time doing backend stuff as opposed to building a frontend and an api layer to work with the backend.