DEV Community

Cover image for Pure Go GUI Toolkit 2026 — 425K LOC Ecosystem, Zero CGO, WebGPU (gogpu/ui)
Andrey Kolkov
Andrey Kolkov

Posted on

Pure Go GUI Toolkit 2026 — 425K LOC Ecosystem, Zero CGO, WebGPU (gogpu/ui)

#go #gui #opensource #webgpu

Series: Building Go's GPU Ecosystem

  1. GoGPU: A Pure Go Graphics Library — Project announcement
  2. From Idea to 100K Lines in Two Weeks — The journey
  3. Pure Go 2D Graphics with GPU Acceleration — Introducing gg
  4. GPU Compute Shaders in Pure Go — Compute pipelines
  5. Go 1.26 Meets 2026 — Ecosystem overview
  6. Enterprise 2D Graphics Library — gg architecture
  7. Cross-Package GPU Integration — gpucontext
  8. Unified 2D/3D Graphics Integration — gg + gogpu
  9. Core Complete, Focus on GUI ← You are here

The Foundation is Done

Three months ago, GoGPU was an idea. Today it's 425,000+ lines of Pure Go — a complete GPU computing stack with a shader compiler, WebGPU implementation, 2D graphics library, and application framework. All without CGO.

The core architecture that powers everything — from shader compilation to pixel output — is production-ready. And that means it's time to build what this was all leading to: a real GUI toolkit for Go.

Where We Are: The Ecosystem at a Glance

Active Development

Project What It Does LOC Status
gogpu/ui GUI Toolkit 55K Phase 2 Beta

Foundation (Maintenance Mode)

Project What It Does LOC Version
gogpu/gg 2D Graphics (Canvas, GPU accel, text) 167K v0.29.0
gogpu/wgpu Pure Go WebGPU (Vulkan/DX12/Metal/GLES) 105K v0.16.9
gogpu/naga Shader Compiler (WGSL → SPIR-V/MSL/GLSL/HLSL) 54K v0.14.1
gogpu/gogpu Application Framework (windowing, input) 37K v0.20.0
+ 4 more gpucontext, gputypes, gg-pdf, gg-svg 9K Stable

The foundation libraries handle issues, feature requests, bug fixes, and performance improvements as they come in. Their architecture is settled. Our full energy goes into gogpu/ui.

Why Build Another GUI Toolkit?

Go's GUI landscape has options — Fyne, Gio, Wails. We respect all of them. But we're solving a different problem:

We want Go to power the applications that currently require Electron, Qt, or native platform toolkits. IDEs. Design tools. CAD. Professional dashboards.

That means:

  • Zero CGO — go build and it works, everywhere
  • WebGPU rendering — native GPU acceleration on all platforms
  • Enterprise layout — Flexbox, Grid, docking, virtualization
  • Reactive state — Signals-based data binding (not callbacks)
  • Accessibility — ARIA roles from day one, not bolted on later
  • Pluggable design systems — Material 3 today, Fluent or Cupertino tomorrow

Architecture: Three Layers, Clean Separation 

Layer 3b: Design Systems ── theme/material3/ (HCT color science)
Layer 3a: Generic Widgets ── core/button/, core/checkbox/, core/radio/
Layer 2:  CDK (headless)  ── Content[C] polymorphic pattern
Layer 1:  Foundation      ── widget/, event/, geometry/, layout/
Enter fullscreen mode Exit fullscreen mode

The key insight: widgets don't know their design system.

A button.Button defines behavior — click handling, keyboard activation, focus management. How it looks is determined by a Painter interface that the design system implements.

// The widget defines behavior
btn := button.New(
    button.Text("Submit"),
    button.OnClick(func() { save() }),
    button.VariantOpt(button.Filled),
)

// Material 3 painter handles appearance
// (injected via ThemeProvider, not imported by the widget)
Enter fullscreen mode Exit fullscreen mode

This means:

  • Core widgets are design-system-agnostic
  • Swapping from Material 3 to Fluent is changing one import
  • Community can create custom design systems without forking widgets

Dependency Inversion

gogpu/ui never imports gogpu directly. Instead, it depends on interfaces from gpucontext:

ui ──imports──> gpucontext (interfaces: WindowProvider, EventSource)
examples ──imports──> gogpu (concrete implementation)
Enter fullscreen mode Exit fullscreen mode

This means you can test the entire widget tree headlessly — no window, no GPU, just unit tests. The toolkit has 97% average test coverage across all packages.

What's Already Working

Phase 0: Foundation (Complete)

Core infrastructure that every widget builds on:

  • geometry — Point, Size, Rect, Constraints, Insets
  • event — Mouse, keyboard, wheel, focus events with modifier keys
  • widget — Widget interface with 3-phase lifecycle (Layout → Draw → Event)
  • layout — CSS Flexbox, VStack/HStack, CSS Grid engines
  • render — Canvas implementation backed by gogpu/gg

Phase 1: MVP (Complete)

The basics needed for a working application:

  • state — Reactive signals (Signal, Computed, Effect, Binding, Scheduler) wrapping coregx/signals
  • a11y — Accessibility tree with 35+ ARIA roles
  • primitives — Box, Text, Image display widgets with fluent API
  • app — Window integration via gpucontext interfaces

Phase 1.5: Extensibility (Complete)

Enabling the community to build on top:

  • registry — Widget factory registration with categories
  • plugin — Plugin bundling with dependency resolution
  • theme — Base theme system (ColorPalette, Typography, Spacing, Shadows, Radii, Extensions)
  • layout (public) — Custom layout algorithms

Phase 2: Beta (75% Complete)

Interactive widgets and Material Design:

  • button — 4 variants (Filled, Outlined, TextOnly, Tonal), 3 sizes, keyboard activation
  • checkbox — Checked / unchecked / indeterminate, label support
  • radio — Radio groups with vertical/horizontal layout, arrow key navigation
  • focus — Tab/Shift+Tab navigation, keyboard shortcuts, focus ring
  • cdk — Component Development Kit with Content[C] polymorphic pattern
  • material3 — HCT color science, 32 color roles, 15 typography roles, painters for all widgets

Remaining for Phase 2: TextField, Dropdown, Slider, Progress indicators, Typography system, Icon system

A Working Example

Here's a real application running today — ui/examples/hello:

func main() {
    gogpuApp := gogpu.NewApp(gogpu.DefaultConfig().
        WithTitle("gogpu/ui — Widget Demo").
        WithSize(800, 600).
        WithContinuousRender(false)) // Event-driven: 0% CPU idle

    uiApp := app.New(
        app.WithWindowProvider(gogpuApp),
        app.WithPlatformProvider(gogpuApp),
        app.WithEventSource(gogpuApp.EventSource()),
    )
    uiApp.SetRoot(buildUI())

    // ... rendering pipeline setup ...
    gogpuApp.Run()
}

func buildUI() *primitives.BoxWidget {
    return primitives.Box(
        primitives.Text("gogpu/ui — Widget Demo").
            FontSize(28).Bold().
            Color(widget.RGBA8(33, 33, 33, 255)),

        checkbox.New(
            checkbox.LabelOpt("Enable notifications"),
            checkbox.Checked(true),
            checkbox.OnToggle(func(checked bool) {
                fmt.Println("notifications:", checked)
            }),
        ),

        radio.NewGroup(
            radio.Items(
                radio.ItemDef{Value: "light", Label: "Light"},
                radio.ItemDef{Value: "dark", Label: "Dark"},
                radio.ItemDef{Value: "system", Label: "System"},
            ),
            radio.Selected("system"),
            radio.DirectionOpt(radio.Horizontal),
        ),
    ).Padding(32).Gap(12).
      Background(widget.RGBA8(255, 255, 255, 255)).
      Rounded(12).ShadowLevel(2)
}
Enter fullscreen mode Exit fullscreen mode

Key characteristics:

  • Event-driven rendering — 0% CPU when nothing changes
  • GPU-direct pipeline — widgets render through gg, ggcanvas blits directly to the GPU surface (zero-copy)
  • Functional options — clean construction without builder hell
  • Fluent styling — .Padding().Gap().Background().Rounded() chains

The rendering pipeline:

Widget tree → render.Canvas (gg) → ggcanvas → GPU surface
                                    ↓
                              Zero CPU readback
                              Direct GPU composition
Enter fullscreen mode Exit fullscreen mode

What's Next

Near-term: Phase 2 Completion

Widget Description Status
TextField Text input with cursor, selection, clipboard Next up
Dropdown Popup selection with search Planned
Slider Range input with track and thumb Planned
Progress Determinate and indeterminate indicators Planned

Phase 3–4: IDE-Class Application Shell

This is where it gets ambitious. The target is GoLand-class IDE layout — the kind of application shell that currently requires Electron, Qt, or platform-native code:

┌──────────────────────────────────────────────────────────┐
│  Toolbar                                                 │
├────────┬─────────────────────────────────┬───────────────┤
│        │  Tab1 │ Tab2 │ Tab3             │               │
│  Left  │─────────────────────────────────│  Right Panel  │
│  Panel │                                 │  (Inspector,  │
│  (Tree,│     Main Editor Area            │   Properties) │
│  Files)│                                 │               │
│        │                                 │               │
├────────┴──────────────────┬──────────────┴───────────────┤
│  Terminal │ Problems │ Git│                              │
│  Bottom Panel (resizable, collapsible)                   │
└──────────────────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

The building blocks for this, in order:

Component Phase Description
ScrollView 3 Smooth scrolling with inertia
TabView 3 Editor-style tabs with close buttons, reordering
SplitView 3 Resizable horizontal/vertical splits
Dialog/Modal 3 Popup windows with focus trapping
Popover/Tooltip 3 Context menus, hover tooltips
VirtualizedList/Grid 3 Render 100K items (file trees, logs)
Animation Engine 3 Spring physics, transitions, easing
Docking System 4 Draggable panels — left, right, bottom, floating
Drag & Drop 4 Cross-widget, cross-window DnD (tab reordering, panel docking)
Fluent Theme 4 Windows-native look
Cupertino Theme 4 macOS-native look
i18n 4 RTL text, locale-aware formatting

The docking system is the crown jewel — panels that snap to left/right/bottom, collapse to icon strips, drag between positions. Exactly what you see in GoLand, VS Code, or Photoshop. Built entirely in Go, rendered entirely on the GPU.

The Core Libraries: Maintenance Mode

With the GUI toolkit as the primary focus, the lower-level libraries shift to maintenance:

Library Focus Going Forward
gg (2D graphics) Bug fixes (#95 AA quality, #72 circle artifact), GPU pattern support, performance
wgpu (WebGPU) Community bug reports, platform-specific fixes, new HAL features as needed
naga (shaders) HLSL matrix fix (DX12 text rendering), new shader targets on demand
gogpu (framework) Community issues (#82 NVIDIA crash, #89 macOS Tahoe), WASM support (#70)

This doesn't mean they're done — it means they're stable enough to build on while we focus our development time on the toolkit that will use them.

Numbers

Metric Value
Total ecosystem 425K+ lines of Go
UI toolkit alone 55K lines, 208 Go files
Test functions (UI) 1,400+
Test coverage (UI) 97% average
GPU backends 5 (Vulkan, DX12, Metal, GLES, Software)
Shader targets 4 (SPIR-V, MSL, GLSL, HLSL)
Platforms Windows, Linux (X11/Wayland), macOS
CGO required None

Try It 

# Clone and run the hello example
git clone https://github.com/gogpu/ui
cd ui/examples/hello
go run .
Enter fullscreen mode Exit fullscreen mode

Requirements: Go 1.25+, a GPU with Vulkan/DX12/Metal/GLES support.

Get Involved

We're building this in the open and we want your input:

The foundation is solid. Now comes the fun part — building the toolkit that makes Go a first-class citizen for desktop applications.

The GoGPU ecosystem is MIT-licensed. Contributions welcome.

Top comments (0)