Gio
By the Gio project (Elias Naur and contributors)
Gio is a library for building cross-platform graphical user interfaces in the Go programming language using an immediate-mode rendering model, where the interface is redrawn from scratch each frame based on the application's current state…
Definition
Gio is a library for building cross-platform graphical user interfaces in the Go programming language using an immediate-mode rendering model, where the interface is redrawn from scratch each frame based on the application's current state rather than retained as a persistent tree of widget objects. It targets desktop, mobile, and web platforms from a single Go codebase, compiling to native binaries and WebAssembly. Gio is used for building GUI applications that want fine-grained control over rendering and layout without a retained widget-object model.
Overview
Gio was created by Elias Naur, a contributor to the Go project and its mobile tooling, to explore an immediate-mode approach to GUI development in Go, distinct from the retained-mode widget-object model used by most GUI toolkits, including Go's own Fyne. In a retained-mode toolkit, an application constructs a tree of persistent widget objects that the toolkit manages and updates; in Gio's immediate-mode model, the application's UI code runs every frame, describing what should appear on screen based on current state, and Gio's layout and rendering system produces the frame from that description without the application maintaining long-lived widget objects itself. Mechanically, a Gio application structures its interface using layout functions that compose flexible boxes, lists, and stacks, similar in spirit to layout systems in modern declarative UI frameworks, but expressed as ordinary Go function calls executed each frame rather than a separate markup or component tree. Input handling in Gio works by tagging areas of the screen with input handlers during the same per-frame pass that produces the visual layout, so hit-testing and rendering share the same code path instead of being handled by separate systems. Gio renders through a custom, highly optimized 2D graphics path built on top of GPU APIs appropriate to each platform, giving it a reputation for low CPU and memory overhead relative to some retained-mode alternatives. Compared with Fyne, Gio's immediate-mode model demands more explicit code from the developer for each frame since there is no persistent widget object holding state between renders, but this same design gives Gio finer control over rendering behavior and generally lower overhead, which is why Gio is sometimes chosen for performance-sensitive or resource-constrained GUI applications. Compared with web-view-based frameworks like Wails, Gio renders its own UI directly rather than delegating to a browser engine, avoiding that dependency entirely at the cost of implementing more UI behavior from lower-level primitives. In practice, Gio is used by developers building custom, performance-conscious GUI applications who are comfortable working with an immediate-mode paradigm, including some cross-platform mobile and desktop apps that value Gio's small binary size and native compilation across Android, iOS, Windows, macOS, Linux, and WebAssembly targets from one codebase. Gio's immediate-mode approach and smaller community relative to more established GUI toolkits mean fewer pre-built widgets and third-party component libraries are available out of the box, so teams often implement more of their own UI components than they would with a retained-mode toolkit that ships a fuller default widget set. This makes Gio best suited to developers willing to invest in understanding its layout and input model in exchange for the control and performance characteristics it offers, rather than teams wanting the fastest path to a conventional-looking application.
Key Features
- Immediate-mode UI model redrawn from state each frame
- Layout composed from flexible boxes, lists, and stacks in Go code
- Input handling integrated into the same per-frame layout pass
- Custom GPU-backed 2D rendering path for low overhead
- Single Go codebase targeting desktop, mobile, and WebAssembly
- No retained widget-object tree maintained by the application
- Small binary size relative to some retained-mode GUI toolkits