Show HN: htmgo - build simple and scalable systems with golang + htmx | Hacker News Reader

Show HN: htmgo - build simple and scalable systems with golang + htmx

htmgo.dev

166 pointsmaddalax81 comments

Hey all, I just wanted to share a project I've been working on for the past month.

After years of heavy frameworks, I really like the idea of using htmx, but it’s a little too low level for me and needs a thin layer above it to facilitate things like components, better syntax with complex JS inside of an attribute, etc

To try and solve this problem with a very minimal stack (golang + htmx) that I've been really enjoying, I'm building this project to cater to my needs and was thinking it would be useful for other developers.

Open articleView on HN

Welp, another fasthtml project. I still don't understand the idea of reinventing HTML in another language. It's too restrictive and will never be as compatible as JSX.

Don't get me wrong, I love HTMX, I just don't want to write DSL to generate HTML. IMO a backend language should integrate HTMX similar to how https://hotwired.dev/ works.

> 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/

gomponents look better; at least the `h.` prefix could be omitted. Also, it serves a simpler purpose than htmgo.

What do you think about https://templ.guide/? To me, the ability to still write raw HTML in Go is incomparable.

I’m not quite sure what the roadmap looks like for gocomponents but it looks similar but I think it’s only filling one part of the puzzle. My plan for htmgo is to become essentially a ready to use framework for building your whole app, using very fast/lean modules, similar to Ruby on Rails, especially rails 8, and not just an HTML builder

What makes you believe the prefix can’t be omitted in htmgo? You just alias it the same way with a ‘.’

Sorry, I made a mistake. I thought the HTML tag functions were accessed through `ctx`, which is passed to the page function. It's true that we can import them directly to access `Div`, `Class`, etc.

> 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.

I actually created https://alpine-ajax.js.org for this reason. HTMX and Hotwire both have opinionated requirements around the content and status codes that your server returns. One of the goals with Alpine AJAX is you should be able to drop it into any basic CRUD app and have it working without changing any server code.

HTMX for example requires that a successful form submission respond with a 200 status, but many applications (most?) will 302 redirect to a new page to prevent duplicate form request on refresh.

This is very cool, I like the website too

I compare this project to FastHTML for two reasons: 1. They both invented a DSL to write HTML in a functional way. 2. They both integrate with HTMX to provide interactivity.

This is not a criticism or a metaphor, just an observation of their technical similarities. May I ask if there are any aspects I might be unaware of that make you feel this comparison is inappropriate?

Without touching JavaScript but now you have to type

return h.NewPage( h.Div( h.Class("flex gap-2"), h.TextF("the current time is %s", now.String()) ) )

To me that is horrible.

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

As a developer who has worked extensively with React and Reagent (a ClojureScript wrapper around React) I actually enjoy this kind of syntax. Better that then some custom HTML templating syntax I need to learn in addition to the language.

It doesn't look too bad if one also break the code into multiple functions to make "layouts" and "components".

I have had lots of fun building with Bun, ElysiaJS, and HTMX. Might test your go library out as well. Looks pretty neat.

Awesome, yeah those are pretty nice technologies. Definitely let me know if you do / encounter any issues!

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

This attitude would stop over 50% of disagreements.

and.. piss off another group who get their validation externally by evangelically putting down the technological choices of others.

Prejudice may not be in social areas but the same behaviour of prejudice is alive and well in justifying your own or denigrating someone else’s technology choices.

Same folks aren’t willing to be open to what is new to them in a new framework is still a 20 year old thing.

Being open to try new things is a rare state of mind and immediately disqualifies much of the population.

Having an open mind, and curious mind that seeks out new ways and experiences not something that happens randomly. You have to cultivate it in yourself and others.

I specifically said "to me"

You did, but you didn't lead with it.

Leading with it sets context before the fact.

I'm not sure what you expect out of this conversation

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

This is not right, there's nothing wrong with typing out code. Generators are fine, until they're not.

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

This is anything but bikeshedding.

These things are really nice and I enjoy using them very much, but we depend now so much on shadcn and ready made templates on top of that; almost all of those are react (and next). The world needs far more open source (fully, not those 'pay to a for all the useful components and templates'; not because I don't want to pay, but because of the licensing; we reuse all things internally, so 1-site license etc are just not options) html/tailwind, htmx, htmgo, clog etc templates with components.

edit: typo

I love this! I have been working on something similar recently [1] and it is exciting to think about the possibility of building full stack components for the web that are not going to break in the foreseeable future. Even if I need to swap languages/frameworks go is easy to parse and transpile!

I dream of a library like ours to take on the likes of React, and to get there the devex needs to have some key features. Most notably, imo, is live reload. You could use air, but I find it still to be too slow to recompile the entire app. I have had some success so far with yaegi to interpret the go at runtime [2]. It isn't perfect, but the full language spec is implemented.

My personal goal is to build the Go equivalent of rails/django. Live reloading is needed in addition to plugins that provide web app primitives (auth, storage, logging, metrics, etc). Additionally, I think the network effect of React is a powerful value driver, so some easy way to include React in an app is also important. Thankfully evanw has made this trivial with esbuild [3]

[1] https://github.com/breadchris/share/blob/master/html2/html.g... [2] https://github.com/traefik/yaegi [3] https://github.com/breadchris/share/blob/master/graph/build....

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.

15 years ago I created a web framework for newLISP. It even ran fast on a Nokia N900

Maybe you want to have a look at the code and get some inspiration.

https://github.com/taoeffect/dragonfly-newlisp

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.

I would take a look at this demo [1]. Pay close attention to what is being interpreted vs bound as a symbol to compiled code. The `yaegi extract` command will not work on exported generics atm.

If you want to collab more, shoot me an email: chris@breadchris.com

[1] https://github.com/DCjanus/yaegi_demo

This is useful! Love the Go & HTMX combination and use it often. Good documentation too for an alpha release. Nice work.

The example TODO app doesn't seem to be doing so well https://todo-example.htmgo.dev/

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

someone decided to ddos it with profanity so I'm pushing an update now so its not global viewable anymore.

I would have paid extra for free profanity, consider to offer it as an addon

htmx + Templ (https://templ.guide/) is something I'm really enjoying as a replacement for React in my personal projects.

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

I'm kind of in the same boat (but with VSCode). In addition to that, I found that it didn't make things too much easier than something like MVC with built-in template/html. The context integration seems like a huge footgun, since it just panics if you access a value that doesn't exist.

There is definitely a problem with the LSP. I've resorted to turning off the templ extension in VS Code, syntax highlighting and all.

That's actually something I've been slowly working on. There's a bug in the go parser tho that kinda slowed things down a lot.

Reminds me of https://j2html.com

Which I have also been starting to use for one project, with quarkus, been a nice experience so far.

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

Have you tried Renarde and Qute?

Yes. My concern is the template compilation will get really slow or the custom IDE integration will get out of date and break.

It will suggest a tweak to config if it sees live reload times going past 4s. That seems to help a lot on my 2019 MBP.

I hear you on point #2 though. The Red Hat IntelliJ plugin for that seems janky to me. And JetBrains own plugin doesn’t seem great either. In fact I don’t know if I’ve ever seen autocomplete in a Qute template ever.

Shame, because the rest of the stack is so damn good.

> It will suggest a tweak to config if it sees live reload times going past 4s

No I mean, I can tell it will get slow, haha.

> the rest of the stack is so damn good.

I agree! (so far, I think)

j makes me shudder. But thanks for sharing.

haha, to be fair my Java code is more like Go than typical Java. I should probably try Go someday.

Kotlin is a great fit for this - it has an html dsl library called Kotlinx.html, which works alongside HTMX fantastically. And, you can write a kotlinjs frontend chunk for anything additional you need that HTMX isn't a great fit for. I built a framework for my own use that has typesafe routing & SQL. It's a thing of beauty.

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

"Scalable", but does it scale in terms of business requirements typical of web projects?

I remember the days when one of the complaints about PHP was people mixing PHP and HTML together. And no, it was mixing PHP and HTML together. That’s it. Don’t try to tack on anything else to the conversation. And we’ve been going back to it for some time now. This doesn’t even map to HTML naturally!

I’m mean fine have fun with your libraries but the amount of excitement for something like this? Amazing.

I'll defintely give it a try when I can but in the meantime I wanted to congratulate and encourage you for the *simple* and yet very practical website presenting the project. It's so rare nowadays that it deserves it.

Has there ever been a widely used open source project for writing HTML as functions inside of another language? (JSX and PHP don't count - you're still writing the HTML markup).

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

From the module synopsis which means some of the capabilities of the Raku Quoting Slang are in play ... https://raku.land/zef:librasteve/HTML::Functional. Raku functions only need parens for disambiguation btw. Named attrs can use the :name<value> syntax which imo is the tidiest.

Raku is such a great language! It’s a shame it doesn’t get the attention it deserves. Thanks for sharing!

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...

How do you handle client side interactivity? I’m probably an outlier, but all the JS I write is client side, and I sure wish I had a typed language to use in development.

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

I find, for a little extra productivity, that liveview [0] even adds a bit more effortless building personally. No plumbing endpoints is great with all written in Go.

[0] https://github.com/canopyclimate/golive

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.

Template functions are a better approach, IMO.

[1] https://templ.guide/

interesting idea, can it be used with Gin or any other Go web framework - or is that not just the html templating library but a framework on its own?

There were a few typos in the docs page: https://triplechecker.com/s/D32t6y/htmgo.dev?v=HrUfl

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.

Also depending on popularity, I may make other adapters for different go web frameworks

Beautiful! I don't use Go anymore (moved to Rust) but this looks pristine.

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.

> I love web dev using rust! I use sveltekit and proxy all requests to /api to a rust backend

I think this most people would call this backend-, api- or service development. Especially if your api endpoint does not do anything web specific except http.

Anyway, how do you share types between the backend and frontend? Are you rawdogging json?

Rust could probably generate the HTML.

I've been playing with loco.rs to do this! Really cool, let's you use htmx or sveltekit (or whatever you want)

Sounds interesting! Do you have an example project? It seems to be quite opinionated.

Yeah quite opinionated! I don't have an example project at the moment, but here's a youtube video from loco.rs that someone might find interesting: https://loco.rs/casts/007-htmx/

Yeah, that makes sense. I've only had fullstack web dev jobs using node, thus the phrasing but you're totally right.

I use the ts-rs crate, which adds a derive(TS) macro for types in rust and generates typescript types. It works so far but my side projects are only medium sized. But I'm sure there are other options too.

Backend devs rejoice as they can now build dashboards without leaving go.

How is htmx low level?

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.

“Letting a hundred flowers blossom and a hundred schools of thought contend is the policy for promoting progress in the arts and the sciences and a flourishing socialist culture in our land.”

Hand-coding HTML is three decades in, like using computer languages from the 1970s in the 2000s.

There are so many of these experiments the last few years, could any be what replaces HTML5?

If not, why not? What would be enough better? Most likely not just another form of the same.

Fresh air

Reply on news.ycombinator.com