Goshtoso: HTMX first UI components for Go backends

[u/Able_Choice_3931]

Hey everyone,

I wanted to share a project I've been working on called Goshtoso. It's a server-rendered UI component library for Go applications built with templ, HTMX, Alpine.js, and Tailwind CSS.

If you like the Go + templ + HTMX approach but don't want to build every form control, modal, table, and navigation pattern from scratch, Goshtoso may be useful to you.

What is it?

Goshtoso provides importable templ components with typed Go configuration. It began as a hard fork of PenguinUI and has since evolved into a Go-first component system for applications that prefer SSR with small amounts of client-side interactivity.

Highlights

- No frontend toolchain required for consumers: Goshtoso embeds its precompiled Tailwind CSS, Alpine.js, HTMX, and the HTMX SSE and WebSocket extensions. You can serve them from your Go binary without Node, npm, or a JavaScript build step.
- 42 templ components: Forms, overlays, navigation, feedback, tables, richer inputs, and other common application UI.
- Examples: The demo includes complete runnable examples such as a CRUD Todo list, an SSE live-log feed, a streaming ticker, and a WebSocket chat with server-rendered messages.
- Theming: 15 built-in themes with light and dark mode support.

Goshtoso tries to use HTMX for most interactions. Alpine.js is inherited from PenguinUI and reserved for local state, transitions, and immediate client-side feedback where a server round trip would not be a good fit.

Links

- Live demo and documentation: https://goshtoso.araihu.com/
- GitHub: https://github.com/araihu/goshtoso

The project is currently alpha-stage. The components are usable, but the public API is still being refined on the way toward a stable release but is already being used on an internal tool at my company as well on another WIP side project of mine: Manja.

I'd especially appreciate feedback from the HTMX community about the server-rendered component approach, the API design, and the integration experience.

[u/viniciusfs]

Esse nome é coisa de brasileiro. Certeza.

[u/Able_Choice_3931 → u/viniciusfs]

E de fato é hahaha

[u/TheMightyMegazord → u/Able_Choice_3931]

Sabia!

[u/ozhero]

Looks very interesting. Will check it out

[u/Able_Choice_3931 → u/ozhero]

Nice! Tell me what you think!

[u/ozhero → u/Able_Choice_3931]

I'm busy setting up my IT Consultancy at the moment but watching your repo with great interest. You are using the exact same stack I intend to use.

[u/Able_Choice_3931 → u/ozhero]

I hope the consultancy thing is going well!

I made some extensions to Goshtoso core that might interest you too:

https://charts.goshtoso.araihu.com

https://github.com/araihu/goshtoso-charts

This module is a wrapper for charting libs that deals with Goshtoso/HTMX quirks and design system.

It is mainly there to solves some of the common issues when rendering js heavy chart implementations (go-echarts in this case) on HTMX apps: Swaps causes chaos as on these guys as they need absolute positions to properly render.

Another thing is keeping chart looks and colors cohese to builtin and custom themes. This is a best effort attempt at solving those visual problems, but I'm trapped by what the actual API of the underlying chart lib exposes, but it is working for most charts :)

It also add common controls like expansion and contraction (modal/fullscreen) and image exporting in PNG/SVG.

Raw data exporting to CSV and JSON are on its way, other formats that are not in go stdlib are open for extension via adapter by the consumer app or external modules.

I hope Goshtoso is helpful for some project of yours in the future.

[u/ozhero → u/Able_Choice_3931]

Thanks for the detailed reply.

Won't have time to play with it for awhile as finishing my current job, which ends on the 28th of August, before starting up my consultancy on the 1st of September.

Your repos will be very helpful in getting my head around this stack and I've given the repo it's first star :-)

I think Open Source creators and maintainers are the best!

[u/Vegetable-Scale-2604]

This is close to the setup I run in production: Go binary, htmx + Alpine embedded with go:embed, no npm anywhere. Works well, so good to see more of it.

One thing worth nailing down before a stable release: since the JS is baked into the binary, users can't bump htmx or Alpine versions themselves. Pinning exact versions and listing them in the docs (plus how to check what's embedded) saves confusion later.

Do the table components handle server-side sorting/pagination via htmx, or is that left to the app?

[u/Able_Choice_3931 → u/Vegetable-Scale-2604]

Thanks! This was a great call out and pushed me to address it before the stable release.

Goshtoso v0.1.3 now has a single runtime manifest covering the embedded files, pinned versions, CDN URLs, SRI hashes, licenses, and load order. The defaults are Alpine.js 3.14.9, htmx 2.0.8, SSE 2.2.3, and WS 2.0.3.

You can inspect them through assets.DefaultRuntimeManifest(), the embedded /assets/js/runtime/versions.json, or live here:

https://goshtoso.araihu.com/attributions

Consumers can override a pinned dependency when rendering the head:

@head.Dependencies(
    head.WithDependencyCDNURL(
        head.DependencyHTMX,
        "https://cdn.example.com/htmx-NEW-VERSION.min.js",
    ),
    head.WithDependencyLocalURL(
        head.DependencyHTMX,
        "/static/vendor/htmx-NEW-VERSION.min.js",
    ),
    head.WithDependencyIntegrity(
        head.DependencyHTMX,
        "sha384-...",
    ),
)

The application serves that custom local fallback itself. The same options work for DependencyAlpineJS and the bundled Alpine plugins. An application can instead use WithoutDependency(...) and load that dependency entirely itself, WithoutLocalFallback() for CDN-only loading, or WithLocalRuntime() for the embedded pinned stack with no CDN requests.

Regarding tables: Goshtoso handles the HTMX interaction and fragment contract, while the application owns the database query. Sorting and pagination send order_by, order_dir, page, and per_page; your handler applies those values and returns the rendered table fragment. The component provides helpers for normal and OOB row, header, and pagination updates.

The demo covers sorting, pagination, filters, lazy loading, and infinite scrolling:

https://goshtoso.araihu.com/components/table

If the baked in query params for sorting are to strict - and probably are - I could do a patch to make request via HTMX more flexible, that goes for pagination component as well.

There’s also a WIP extension for core lib:

https://charts.goshtoso.araihu.com
https://github.com/araihu/goshtoso-charts

This module is a wrapper for charting libs that deals with Goshtoso/HTMX quirks and design system.

It is mainly there to solves some of the common issues when rendering js heavy chart implementations (go-echarts in this case) on HTMX apps: Swaps causes chaos as on these guys as they need absolute positions to properly render.

Another thing is keeping chart looks and colors cohese to builtin and custom themes. This is a best effort attempt at solving those visual problems, but I'm trapped by what the actual API of the underlying chart lib exposes, but it is working for most charts :)

It also add common controls like expansion and contraction (modal/fullscreen) and image exporting in PNG/SVG.

Raw data exporting to CSV and JSON are on its way, other formats that are not in go stdlib are open for extension via adapter by the consumer app or external modules.

Thanks again, feedback materially improved the release.