Show HN: htmgo - build simple and scalable systems with golang + htmx (htmgo.dev)

1. A development experience with instant visual feedback for the frontend. Even more so when using tailwind.

2. A stable, safe and performant backend.

The downside is that a node process has to be running and doing the ssr, though that is an okay trade off for me because my project is mainly the api, having a reference implementation of the frontend is just a nice extra.

I've also experimented with implementing the reverse proxy in rust itself and using a unix socket and other IPC mechanisms to push the data to the SSR layer.

With it properly spaced out and nested, after a few days it started reading exactly like HTML to me, where I can quickly see the hiearchy

I suppose bike shedding still matters to people who see themselves as Hemingway not an engineer

Turbo stimulus and Strada..

HTMX... Nothing. Just serve it however you feel. In the posts case, they decided to add some tight coupling with go, while not for everyone, is not really a framework.

I appreciate go server for really lightweight banal sites or even light services and htmlx is quickly becoming my new favourite markup. I will say this project isn't for me, but casting it as just another 'fasthtml' project is a bit far off the mark.

I switched from using golang templates with hand-crafted HTML to gomponents[1] a few months ago, and it's been amazing. It is so so so much easier to write re-usable components, so much easier to express complicated conditionals, so much nicer to have a type checker helping you not make mistakes.

And of course I like gomponents for the same reason (I presume) JS-oriented people like NodeJS: It's just a lot nicer to have as much as possible written in the same language, be it JavaScript or Golang.

[1] https://www.gomponents.com/

> You could use air, but I find it still to be too slow to recompile the entire app.

At the moment I'm using fsnotify to watch file changes and restart the process immediately, so far it hasn't been too bad for live reloading. I'm hoping as long as precautions are taken to lazy load things on startup, then it would stay fairly quick.

I'm really curious to do some benchmarking and see how this compares to template-based HTML generation. It seems theoretically possible to accumulate raw data first and then build the document from top to bottom (instead of piecing together a lot of intermediate strings), but I'm not sure the complexity would justify the performance gains.

I also just learned about `gocomponents` [2] in another thread here, which seems to be a similar idea with a substantial headstart. I could probably just switch to it, but I kind of like the idea of following a pattern instead of installing a dependency.

[1] https://gist.github.com/allknowingfrog/951fbaa221a3a504b382f... [2] https://github.com/maragudk/gomponents

The routing uses the std lib + chi, it's fairly integrated into the html builder because the http request needs to be utilized to check specific htmx headers.

I could imagine you could use your own web framework though, since you can wrap the std lib handlers.

Here is an "Elm-like" example from https://elmprogramming.com/building-a-simple-page-in-elm.htm... coded in raku. HTMX is a great lever to put the code on the server - thus Go, Raku, whatever.

  use HTML::Functional;

  my $body = body [
    div( :class<jumbotron>, [
      h1("Welcome to Dunder Mifflin!"),
      p  "Dunder Mifflin Inc. (stock symbol{strong 'DMI'})\n" ~
          q:to/END/;
          is a micro-cap regional paper and office
          supply distributor with an emphasis on servicing
          small-business clients.
          END
    ]),

    p :hx-get<https://v2.jokeapi.dev/joke/Any?format=txt&safe-mode>,
      "Click Me",
  ];

[1] https://www.gomponents.com/