# AllenDang/giu: a Dear ImGui GUI framework for Go

> giu wraps Dear ImGui and GLFW behind a declarative Go API, so you can build a desktop window without writing render or platform code. It is a good fit for tools and internal utilities, and a poor fit for apps that need native widgets or a pure-Go build.

**AllenDang/giu** — Cross platform rapid GUI framework for golang based on Dear ImGui.

- Repository: https://github.com/AllenDang/giu
- Stars: 2,785 · Forks: 157
- Language: Go
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/allendang-giu

## What giu is for, and who it is for

giu is a Go binding to Dear ImGui, layered on the cimgui-go binding and GLFW v3.3. The problem it addresses is the cost of a desktop window in Go: normally you either bind to a native toolkit or write your own render loop. giu removes both. The README describes it as a "rapid" framework and lists "Drop in usage; no need to implement render and platform" as a feature, which is the honest summary of its value.

The audience is narrower than "Go developers". It suits people writing internal tools, debug panels, editors and utilities where the UI is a means to an end. It suits developers who already think in immediate mode, or who are willing to learn it, because every widget is redrawn from your code rather than retained in a widget tree. It does not suit teams shipping a consumer desktop product that must look native on each OS. Dear ImGui draws its own widgets; the README does not claim otherwise, and no theming layer turns an ImGui control into a Cocoa or Win32 control.

## Immediate mode, the loop, and how state actually moves

The README's quick introduction states the model plainly: "Immediate mode GUI system means the UI control doesn't retain its state and value." Calling giu.InputText(&str) draws a text box and writes what the user types into str. The widget keeps nothing. Your loop function is the source of truth, and the README says it is "invoked 30 times per second to reflect interactive states".

That inverts the usual mental model. There is no widget object to query later, no event handler to attach to a control that owns its own value. You read the variable on the next frame. The README also notes a performance consequence: giu "Redraws only when user event occurs", and it reports 0.5% CPU usage at 60FPS. That figure is the project's own claim in the README, not an independent measurement.

Layout follows the same declarative style. Widgets placed inside a container's Layout stack vertically by default. Row() places them horizontally, Column() nests a vertical group inside a row, and any widget with a Size() method accepts a negative value to fill the remaining space, as in InputText(...).Size(giu.Auto). The container hierarchy is MasterWindow for the OS window, Window for a titled collapsible panel, SingleWindow for a window that fills the master, and Child for a bordered panel.

One architectural detail worth noting: the README says giu "will rebuild font atlas incrementally according to texts in UI between frames", which is how it displays multiple languages without a font configuration step. That is a real design choice, and it is also where font-related overhead lives.

## Installing giu and running the hello world example

The backend depends on OpenGL 3.3, so check that first. The README warns that some virtual machines, VirtualBox among them, do not support it.

On macOS, install the command line tools and fetch the module:

```bash
xcode-select --install
go get github.com/AllenDang/giu
```

On Windows the README points to a mingw build, then asks you to add its bin directory (usually \mingw64\bin) to PATH before running the same go get command.

On Debian or Ubuntu, install the X11 and GL development packages first:

```bash
sudo apt install libx11-dev libxcursor-dev libxrandr-dev libxinerama-dev libxi-dev libglx-dev libgl1-mesa-dev libxxf86vm-dev
```

Fedora and Arch have their own package lists in the README, and the note applies to all of them: "Because giu relays on C++ code, you need to have C/C++ compiler set up." After that, a plain go build works.

The smallest real program is the hello world in the README. It creates a master window, then hands a loop function to Run:

```go
func loop() {
	g.SingleWindow().Layout(
		g.Label("Hello world from giu"),
		g.Row(
			g.Button("Click Me").OnClick(onClickMe),
			g.Button("I'm so cute").OnClick(onImSoCute),
		),
	)
}

func main() {
	wnd := g.NewMasterWindow("Hello world", 400, 200, g.MasterWindowFlagsNotResizable)
	wnd.Run(loop)
}
```

What you should see is a 400x200 non-resizable window with a label and two buttons; clicking either prints to stdout. The examples directory goes further, with separate folders for widgets, canvas, markdown, code editor, gizmo, plot and multiwindow layouts, and the README recommends examples/widgets for the full widget set.

## The C++ dependency is the constraint that shapes everything

The most consequential limitation is stated in a note rather than a section: giu relays on C++ code, so a C/C++ compiler must be present. That single fact rules out several workflows. You cannot cross-compile by setting GOOS and GOARCH alone; the README's own cross-compiling instructions for arm64 require adding the arm64 architecture to dpkg and installing gcc-aarch64-linux-gnu, g++-aarch64-linux-gnu and the arm64 variants of the X11 development libraries. A project that expects a pure-Go, single-command cross build will not get one here.

Platform support inherits from two layers. giu is built on GLFW v3.3, and the README says it is "also restricted by cimgui-go (which at the moment builds only for linux, windows and mac)". The supported list is Windows 10 and 11 x64, macOS 10.15 and Big Sur, Linux, and Raspberry Pi 3B. Anything else is untested territory, and the README does not document a fallback.

The rendering model is a second boundary. Because giu draws its own controls, an application that must match the platform's native look, follow OS accessibility conventions, or be scriptable by OS-level UI automation is the wrong tool. The README lists no accessibility support. If your requirement is a form that a screen reader can traverse the way it traverses a native dialog, giu does not address it.

A third, smaller friction: the README's documentation pointers are the wiki, the examples, GoDoc and code comments. There is no single reference manual. Expect to read example source to learn widget behaviour.

## giu against other Go GUI approaches

The closest comparison is Fyne, a Go GUI toolkit that renders through its own canvas and targets Go-first development. The difference is in what you write. Fyne gives you retained widgets with their own state and a theme; giu gives you a draw function that runs continuously and variables you own. Fyne's build story is pure Go, while giu requires a C++ toolchain and OpenGL 3.3. If your constraint is a cross-compiled binary with no system libraries, that difference decides the choice before any API comparison.

A second alternative is the Go bindings to native toolkits, such as those wrapping GTK or the platform frameworks. Those produce controls the OS draws, which is what you want for a consumer app and what you pay for in per-platform build complexity and inconsistency between platforms. giu trades native appearance for one code path across three platforms.

A third option is to bind Dear ImGui yourself, which is what giu is. The README positions giu against other Dear ImGui Go bindings on specific points: executable size under 3MB after UPX compression for the helloworld demo, live redraw during window resizing, incremental font atlas rebuilding, redraw only on user events, declarative UI, DPI awareness and clipboard support. Those are the project's stated differentiators, and they are the things to check if you are choosing between ImGui bindings rather than between GUI paradigms.

## Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-22. Releases are infrequent rather than continuous: v0.14.0 and v0.14.1 landed in May 2025, and v0.15.0 on 2026-06-02. The README asks for financial support, offering invoiced technical support and maintenance contracts for businesses and a Patreon page for individuals, and notes that features remain to be added. That is a maintenance model funded by sponsorship rather than by a company with a product behind the library. Plan accordingly: pin a version, and read the release notes before moving, because there is no long-term support commitment documented in the README.

The module declares go 1.26.0 and pulls github.com/AllenDang/cimgui-go v1.5.1-0.20260729111607-b44df50ed8eb, a pseudo-version pinned to a commit rather than a tagged release. Updating giu can therefore move the C binding underneath you, and the C binding is the part that decides which platforms build. Test on every platform you ship to after an upgrade, not just the one you develop on.

The licence is MIT. That is permissive and places few obligations on how you distribute binaries, but it also means the project carries no warranty. This is a description of the licence identifier in the repository, not legal advice; read the LICENSE file and your own counsel's guidance before relying on it for a commercial release.

## Conclusion

Adopt giu if you are building a desktop tool or internal utility in Go and want an immediate-mode UI without writing platform or render code, and you can accept a C/C++ toolchain in the build. Skip it if you need native OS widgets, a pure-Go build, or a platform outside Linux, Windows and macOS. Before committing, verify that your target machine exposes OpenGL 3.3, since the README states that some virtual machines, VirtualBox among them, do not; then build the examples/helloworld demo on each platform you ship to.

## FAQ

### What does imgui stand for?

Immediate mode GUI. giu's README explains that in this model a control does not retain its state or value: calling giu.InputText(&str) draws a text box and stores what the user types in &str, and the widget itself knows nothing about it.

### Is Go good for GUI?

The README makes no general claim about Go and GUIs; it describes one approach. giu's value is framed as dropping in without implementing render or platform code, at the cost of a required C/C++ compiler and an OpenGL 3.3 backend.

### What are some good GUI libraries for Golang?

The README compares giu only to other Dear ImGui Go bindings, not to the wider field, so it names no alternatives. It lists giu's own differentiators, including small executables, live redraw during resizing, incremental font atlas rebuilding and DPI awareness.

## Sources

- [AllenDang/giu on GitHub](https://github.com/AllenDang/giu)
- [Issues](https://github.com/AllenDang/giu/issues)
- [License: MIT](https://github.com/AllenDang/giu/blob/master/LICENSE)
- [README](https://github.com/AllenDang/giu/blob/master/README.md)
- [Releases](https://github.com/AllenDang/giu/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/allendang-giu