> I still don't understand the idea of reinventing HTML in another language.

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/

> IMO a backend language should integrate HTMX similar to how https://hotwired.dev/ works.

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.

Well when you put it all on one line it doesn’t look great :)

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

Everything doesn't have to be for everyone, and that doesn't make it bad.

You still type out code? My toolkit is endless generators and macros.

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

[dead]

Haha we kind of have the same vision. That's eventually what I want to turn htmgo into, something like rails, but as minimal as it can be (essentially plugins, good defaults but you can opt out).

> 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 still fairly new to Go, but I've been iterating on the idea of approaching HTML as basic string generation and ditching all of the other complexity. I have a single function that generates HTML tags from name, content and property arguments. Everything else just builds on it. [1]

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

yaegi is very interesting... I'm going to see if I can get it working on htmgo for reloading the views.

lol looks like I forgot to limit the user input length, clearing those now…

I do also like the idea behind templ, only issue is when I tried to use it, the DX was pretty poor on Jetbrains IDE’s. I think the LSP is broken for it

Also Gomponents, a similar project for Go: https://www.gomponents.com

Have you tried Renarde and Qute?

j makes me shudder. But thanks for sharing.

Kotlin is indeed a great backend to pair with HTMX. However I find jte.gg templating superior to kotlinx.html's awkward syntax. You still benefit from working with native Kotljn objects inside the templates. Check it out!

that looks nice, I've enjoyed Kotlin when I used it in the past

I have been working on a raku module (HTML::Functional) to do this, as with the OP the main motivation is for me to be able to declutter my own projects, so not widely used, but yes OSS.

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",
  ];

I dunno how widely used it is, but I've found gomponents[1] a big improvement over golang templates with hand-crafted HTML.

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

Phlex (https://phlex.fun), but I don't know about the 'widely' part.

Elm comes to mind. Mentioned a bunch on HN but you probably wouldn't call it widely used...

I’m on mobile at the moment so could probably give you a more detailed answer tomorrow, but check out https://htmgo.dev/docs#interactivity-events

Looks nice. I've tried (a couple of times) to build something similar to this, and to OP's project, but it's never worked out. Golive looks the nearest to the ideal in my head.

Ah good call, I should have checked for typos. Will fix, ty.

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.

I love web dev using rust! I use sveltekit and proxy all requests to /api to a rust backend (though it works with any SSR framework). This is nicely configurable for the vite dev server. Then I basically have all the business logic on the rust side and all the presentation logic on the SSR side to get the best of both worlds. This gives me two things:

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.

Low level in the sense that it doesn't have things you would traditionally need to build an application, such as re-usable components, conditional rendering, etc. To do that you have to wire it up with something else such as your backends templating system, alpine, etc.