Thanks for the kind feedback! I totally get the appeal of daisyUI – super quick to drop in and great for prototyping.
With TemplUI, I’m aiming for a more minimal, dependency-free setup – no extra Tailwind plugins or runtime JS unless absolutely needed. The idea is to stay as close to the metal as possible and let devs build their own design system on top, rather than fight against a pre-styled one.
It's less “drop-in UI kit” and more “starter kit to build your own.” That makes it more customizable and hopefully a better fit for projects that want full control.
I'm working on an application and use Fiber, Templ and Datastar to keep my frontend in Go, like my backend. I'm overall quite happy with this approach.
But Datastar tries to do both, AlpineJS stuff like show/hide dropdow options, as well as HTMX stuff like talk to backend and merge/replace parts of the DOM.
I came across TemplUI a few times while working on this app so far. But always felt the Vanilla JS plus HTMX approach of TemplUI conflicts with Datastar. Too much overlap in different components doing the same stuff for my taste. While at the same time, I spent way too much time converting Tailwind UI components into Tempo. Time I could spend better.
Datastar is quite on the experimental/unstable side of things. And its concept of signals doesn't quite work for my Kubernetes style API resources. So maybe I need to revisit this decision at some point.
What I really like about Datastar and what made me choose it in the first place is how easy it makes using server sent events.
So yeah, exciting times. Still some rough edges I would say. But for me personally I already prefer hypermedia over the predominant React frontends approach.
I used the icons from templui, but haven't updated since a few weeks when the packages went internal, because you have to install its own cli now for dependency management.
Originally, I had templUI components available via Go module imports, but there were a few real issues:
- Tailwind v4+ with CSS-only config needs hardcoded paths to `.templ` files. That clashed in teams where Go paths differed (e.g. `~/dev`, `~/code`, etc.).
- It made Git diffs messy – you had `.templ` and `.go` files being imported per component.
- Updating components via module versions often led to unwanted breaking changes – not easy to "just use one component" from a newer version.
- Workarounds like Makefile tricks for Tailwind `src` path felt too hacky.
The CLI avoids all that. It copies clean files into your codebase, so it's portable, version-safe, and no import path magic needed.
That said – I’m open to feedback. If there's a solid reason to bring back module imports (optionally), I’m listening!
Mostly for building typed web UIs in Go – instead of using html/template, which isn’t typed and feels oldschool. templ makes Go feel way more modern for frontend work.
I know I am an old angry guy but I really don't want things to 'feel' (not sure what that even is) more modern; I have projects that bring me millions a year which are running for over 2 decades now and this kind of 'modern' is just obsolete next year. I like profit and not being bothered by updates every 5 seconds. I have a simple stack, my saas apps are violently fast and they run for decades without me touching anything but some bugs/features. The modern feel is not required and in fact detrimental to just making bucketloads of business value and company wealth imho. But then again, we never had investors, so I don't know how it feels to burn other people's money.
These are weird things to complain about for templ - it’s very boring and stable and it just compiles to very boring Go code while 1) providing type safety for your templates and 2) being less annoying to compose things than template.html.
It definitely doesn’t feel like JSX or any other modern/exciting thing to me.
Yep, that makes sense. I do prefer Go to TS really as I love typesystems but TS types often are completely unreadable. I am a Haskell guy and not entirely sure how they managed to make TS types this line noisy and, frankly, a struggle.
I recently started using it to make a web frontend for a go backend. This is perfect for that as you can use the same struct definitions and functions from the backend.
Why do you say "JSX"? JSX is an HTML templating language for JavaScript. templ looks like an HTML templating language for Go. Every popular web backend language has an HTML templating language... so that it can produce HTML - is it really that surprising?
Nit: I just spent about 5 minutes clicking around trying to find out what templ is.
I could've just Googled it sooner, but I was just surprised I couldn't find any reference to the thing it's actually building on/for.
I took another look and we do explain what templ is on our introduction page: https://templui.io/docs/introduction#built-on-strong-foundat...
"Templ - Type-safe templating for Go" with a link to templ.guide.
Thanks for the feedback!
Fair point – I’ll make sure to link to https://templ.guide more prominently. Thanks for the heads-up!
What is it
Its a components library for [templ](https://templ.guide/)
templ is kind of like JSX but for Golang, if you are familiar with JSX.
It's a language that compiles down to Go and lets you mix HTML-like syntax into your Go code for HTML templating.
https://templ.guide/
From what I can tell it's a Go-based library for building web UI.
While I like the modern feel of shadcn/ui and derivatives, I still think that daisyui is much easier to use.
You really just paste these 2 lines in your html and that's it:
it's a bit more than 100kb of js, but for prototyping it is very nice.I wish more UI libraries where in the same style. You can always optimize the bundle later.
Thanks for the kind feedback! I totally get the appeal of daisyUI – super quick to drop in and great for prototyping.
With TemplUI, I’m aiming for a more minimal, dependency-free setup – no extra Tailwind plugins or runtime JS unless absolutely needed. The idea is to stay as close to the metal as possible and let devs build their own design system on top, rather than fight against a pre-styled one.
It's less “drop-in UI kit” and more “starter kit to build your own.” That makes it more customizable and hopefully a better fit for projects that want full control.
I'm working on an application and use Fiber, Templ and Datastar to keep my frontend in Go, like my backend. I'm overall quite happy with this approach.
But Datastar tries to do both, AlpineJS stuff like show/hide dropdow options, as well as HTMX stuff like talk to backend and merge/replace parts of the DOM.
I came across TemplUI a few times while working on this app so far. But always felt the Vanilla JS plus HTMX approach of TemplUI conflicts with Datastar. Too much overlap in different components doing the same stuff for my taste. While at the same time, I spent way too much time converting Tailwind UI components into Tempo. Time I could spend better.
Datastar is quite on the experimental/unstable side of things. And its concept of signals doesn't quite work for my Kubernetes style API resources. So maybe I need to revisit this decision at some point.
What I really like about Datastar and what made me choose it in the first place is how easy it makes using server sent events.
So yeah, exciting times. Still some rough edges I would say. But for me personally I already prefer hypermedia over the predominant React frontends approach.
I used the icons from templui, but haven't updated since a few weeks when the packages went internal, because you have to install its own cli now for dependency management.
Not a fan of that.
The CLI is just a small Go binary – you can install it once via `go install` and then run `templui add icon`.
It helps keep things consistent as the library evolves.
But yeah, I get that some folks prefer manual imports – all good!
Everything under internal did discourage me from trying templUI too. What's the reason for it?
Yeah, totally fair question.
Originally, I had templUI components available via Go module imports, but there were a few real issues:
- Tailwind v4+ with CSS-only config needs hardcoded paths to `.templ` files. That clashed in teams where Go paths differed (e.g. `~/dev`, `~/code`, etc.).
- It made Git diffs messy – you had `.templ` and `.go` files being imported per component.
- Updating components via module versions often led to unwanted breaking changes – not easy to "just use one component" from a newer version.
- Workarounds like Makefile tricks for Tailwind `src` path felt too hacky.
The CLI avoids all that. It copies clean files into your codebase, so it's portable, version-safe, and no import path magic needed.
That said – I’m open to feedback. If there's a solid reason to bring back module imports (optionally), I’m listening!
What does "HTMX support" even supposed to mean? HTMX is a drop-in library. Literally any html file "supports" HTMX.
You're right – HTMX works everywhere by default.
By “HTMX support” I just mean: the JS logic in components (e.g. tooltips, modals) auto-reinitializes after HTMX swaps.
So you can use components inside HTMX-driven UIs without worrying about broken behavior.
I had no idea JSX for Go would be so popular. (9.3k stars on the templ project). What are people using it for?
Mostly for building typed web UIs in Go – instead of using html/template, which isn’t typed and feels oldschool. templ makes Go feel way more modern for frontend work.
I know I am an old angry guy but I really don't want things to 'feel' (not sure what that even is) more modern; I have projects that bring me millions a year which are running for over 2 decades now and this kind of 'modern' is just obsolete next year. I like profit and not being bothered by updates every 5 seconds. I have a simple stack, my saas apps are violently fast and they run for decades without me touching anything but some bugs/features. The modern feel is not required and in fact detrimental to just making bucketloads of business value and company wealth imho. But then again, we never had investors, so I don't know how it feels to burn other people's money.
These are weird things to complain about for templ - it’s very boring and stable and it just compiles to very boring Go code while 1) providing type safety for your templates and 2) being less annoying to compose things than template.html.
It definitely doesn’t feel like JSX or any other modern/exciting thing to me.
The author and you are good at convincing me to use it. thanks and thats not sarcasm.
Appreciate that! Always happy to find common ground.
THIS actually!
Totally fair – stable, fast, boring tech is often the best kind of tech.
templ’s more for folks who want to stay in Go but need a smoother frontend experience for modern UI needs.
Yep, that makes sense. I do prefer Go to TS really as I love typesystems but TS types often are completely unreadable. I am a Haskell guy and not entirely sure how they managed to make TS types this line noisy and, frankly, a struggle.
Is TS actually a thing? ^^
Curious about your stack that you are using if you don’t mind sharing.
I recently started using it to make a web frontend for a go backend. This is perfect for that as you can use the same struct definitions and functions from the backend.
Nice to hear, happy coding! =)
Why do you say "JSX"? JSX is an HTML templating language for JavaScript. templ looks like an HTML templating language for Go. Every popular web backend language has an HTML templating language... so that it can produce HTML - is it really that surprising?
Checkbox/Radio Card is a neat idea, but doesn't seem to work on mobile.
Thanks for your feedback. I cannot reproduce it. If the problem persists, I would be happy if you create a detailed issue on GH, thanks!
This is beautiful, thank you!
You are welcome! Happy coding! =)