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

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.

gwd · a year ago

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

novoreorx · a year ago

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.

bilekas · a year ago

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

imacrayon · a year ago

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.

novoreorx · a year ago

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?

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

maddalax · a year ago

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.

hilti · a year ago

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

allknowingfrog · a year ago

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

maddalax · a year ago

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

breadchris · a year ago

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

2024user · a year ago

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

snorremd · a year ago

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.

j45 · a year ago

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

sitkack · a year ago

This attitude would stop over 50% of disagreements.

I specifically said "to me"

hadthischat · a year ago

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.

anonzzzies · a year ago

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

Dead Comment

DLA · a year ago

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

tanduv · a year ago

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.

OccamsMirror · a year ago

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

kosmozaut · a year ago

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.

jonathrg · a year ago

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

chabad360 · a year ago

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.

winrid · a year ago

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.

jacques_chester · a year ago

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

mattgreenrocks · a year ago

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.

thwg · a year ago

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.