DEV Community: Cesar Gimenes

I built a tiny wind tunnel in Go

Cesar Gimenes — Wed, 08 Jul 2026 05:09:01 +0000

I built Kutta, a small 2D wind tunnel for aeromodelers, game developers, and anyone who enjoys watching air misbehave.

It is written in Go, uses Ebitengine for rendering, and runs as a single desktop application.

The project is open source:

https://github.com/crgimenes/kutta

The idea

Kutta started as a simple visual experiment: stream air past an airfoil and make the flow visible.

Not as a replacement for real CFD software. Not as an engineering tool for designing aircraft. The goal is more modest and, in my opinion, more useful for experimentation:

Give immediate visual intuition about what happens around an airfoil.

You can change the angle of attack and watch the flow field react. You can see the wake. You can toggle different visualization modes. You can draw your own shapes. You can split a wing into a wing and a flap, animate the control surface, and see the wake become unstable when the geometry or angle gets too aggressive.

It is a toy in the best possible sense: simple enough to play with, but grounded enough to teach something.

What it shows

Kutta visualizes several aspects of the flow:

speed field;
vorticity;
pressure-like scalar field;
smoke streaklines;
lift and drag vectors;
wake behavior;
separation when the angle of attack becomes too high.

It also includes NACA 4-digit and 5-digit airfoil generation, so you can type a profile such as 2412, 0012, or 23012 and get the corresponding shape without loading anything from disk.

And yes, there is also a neko airfoil.

It is terrible.

That is the point.

Qualitative, not validated CFD

This part is important.

Kutta is not a validated CFD tool.

It uses lattice units instead of physical units. It can show useful flow behavior such as stagnation, wake formation, suction over the upper side of the airfoil, and separation as the angle grows, but the numeric values should not be treated as engineering data.

Use it for:

intuition;
teaching;
visual experiments;
aeromodeling curiosity;
game/tool inspiration;
pretty projector demos.

Do not use it to size a real aircraft wing.

That boundary is intentional. I prefer tools that are honest about what they are.

How it works internally

The solver uses a 2D Lattice-Boltzmann method: D2Q9 with BGK collision.

The channel has a free stream coming from the left. The body is represented as a no-slip wall using half-way bounce-back. Forces are estimated from pressure integration over the body faces.

That means Kutta can capture form drag and lift behavior, but it does not model everything. For example, skin friction is ignored, so drag is understated. That is a known limitation, not a hidden bug.

The project is split into a few internal packages:

lbm: the flow solver;
foil: NACA airfoil generation;
scene and sceneio: editable multi-object scenes;
viz: color maps and smoke tracer particles;
the app layer: Ebitengine loop, editor, input, menus, and rendering.

The lower-level packages do not depend on rendering and can be tested headlessly. There is also a snapshot tool that renders fields to PNG, which is useful for sanity-checking behavior without opening a window.

The editor

Kutta includes a simple shape editor.

You can draw a closed shape, move vertices, and use Bézier handles to curve edges. You can also cut and rejoin shapes, which makes it possible to split an airfoil into separate parts.

That is how a wing can become a wing plus flap.

There is also a basic animation mode. You can scrub a timeline, add keyframes, and animate the pose of each part while the flow keeps running.

Scenes are saved as .afoil files. The format is small, textual, and based on s-expressions.

I like this kind of format because it is easy to inspect, diff, and keep in Git.

Why Go?

Go is not the first language people usually associate with simulations or visual creative tools.

That is one reason I like using it for this type of project.

For Kutta, Go gives me:

fast compilation;
simple cross-platform builds;
good standard tooling;
readable code;
easy packaging;
enough performance for this kind of real-time qualitative simulation.

Ebitengine handles the rendering and application loop. The result is a normal desktop app, not a large runtime environment or a complex toolchain.

For users, that means: download one executable and run it.

Why make it visual?

The original motivation was not only technical.

I wanted something that felt alive.

A static chart can explain lift. A formula can describe the idea. A textbook diagram can show separation. But watching a wake form behind a wing while you change the angle of attack gives a different kind of understanding.

It is less precise, but more immediate.

That matters for learning.

It also matters for open source visibility. A short video of Kutta running reached far more people than a traditional technical post would have. That reinforced something I already suspected:

Visual projects are much easier to explain at a glance.

People may not care about the solver at first. They care because it looks interesting. Then some of them become curious about how it works.

That is a good entry point.

Running it

There are prebuilt binaries for macOS, Windows, and Linux in the GitHub releases.

On macOS, it can also be installed with Homebrew:

brew install --cask crgimenes/tap/kutta

To run from source:

go run .

On Linux, Ebitengine needs the usual Cgo/OpenGL/audio development dependencies.

Controls

Some useful controls:

Up / Down: change angle of attack;
Tab: cycle NACA profile;
V: change visualization mode;
S: toggle streamlines;
G: toggle glow/bloom;
Space: pause/resume;
N: single step while paused;
R: reset the flow;
E: open the editor;
O: open an .afoil scene;
Cmd+S / Ctrl+S: save.

You can also type a NACA code directly in the field at the top.

What I learned

The main lesson was that a small, constrained simulation can still be valuable.

It does not need to solve the full real-world problem. It only needs to make one layer of the problem visible.

For Kutta, that layer is aerodynamic intuition.

It also reminded me that open source projects benefit from being demonstrable. A project that produces an interesting image, sound, animation, or interaction is much easier to share than a library that only makes sense after reading the API.

That does not make visual projects better, but it makes them easier to communicate.

Possible next steps

Some ideas I may explore:

better scene examples;
more airfoil presets;
improved editor workflow;
better force visualization;
exportable screenshots or short clips;

I want to keep the project small. The goal is not to turn it into a professional CFD package. The goal is to keep it useful, understandable, and fun.

Repository

Kutta is open source under the MIT license:

https://github.com/crgimenes/kutta

If you like small visual tools written in Go, take a look at the repository. A star helps me understand which experiments are worth maintaining.

Building desktop WebView apps in Go without CGo

Cesar Gimenes — Tue, 30 Jun 2026 03:54:59 +0000

I have been working on Glaze, a small desktop WebView toolkit for Go.

The short version: Glaze lets a Go program open a native desktop window backed by the WebView already available on the operating system, without using CGo.

It currently targets:

macOS, through WKWebView
Linux, through WebKitGTK
Windows, through WebView2

The project is still young, but the core idea is already useful: keep small Go desktop tools close to the normal Go workflow.

No C compiler in the build path.
No bundled native helper library.
No large application framework around it.

Just Go code calling the system WebView.

Why I wanted this

I write a lot of small tools in Go.

Some of them are fine as CLI programs. Others need a basic interface: a form, a preview, a local dashboard, a small editor, or a way to inspect and manipulate data visually.

For those cases, HTML is often enough. The browser gives me layout, text rendering, forms, tables, keyboard handling, and a familiar debugging model.

But I do not always want to ship a web server as the user interface. I also do not always want to pull in a large desktop framework when all I need is a native window around a local UI.

A WebView is a reasonable middle ground.

The problem is that many WebView solutions eventually bring CGo, native build tooling, helper libraries, or larger framework assumptions into the project.

That is not necessarily wrong. For many applications, those trade-offs are acceptable.

For this project, I wanted something narrower.

The design constraint

The main constraint behind Glaze is simple:

Use the WebView already provided by the OS, but call it from Go without CGo.

Glaze uses purego to call native platform APIs directly from Go.

That means each backend talks to the platform WebView:

WKWebView on macOS
WebKitGTK on Linux
WebView2 on Windows

The result is not a full GUI toolkit. That is intentional.

Glaze is focused on the window, the WebView, JavaScript-to-Go bindings, and a few desktop helpers that are useful for small tools.

Hello world

A minimal Glaze program looks like this:

package main

import (
    "log"

    "github.com/crgimenes/glaze"
)

func main() {
    w, err := glaze.New(true)
    if err != nil {
        log.Fatal(err)
    }
    defer w.Destroy()

    w.SetTitle("Glaze")
    w.SetSize(800, 600, glaze.HintNone)
    w.SetHtml("<h1>Hello from Glaze</h1>")

    w.Run()
}

That opens a native window and renders HTML inside the system WebView.

A local Go app in a desktop window

One of the patterns I care about most is turning an existing net/http application into a desktop app with minimal changes.

Glaze has an AppWindow helper for that.

package main

import (
    "fmt"
    "log"
    "net/http"

    "github.com/crgimenes/glaze"
)

func main() {
    mux := http.NewServeMux()

    mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "text/html; charset=utf-8")

        _, err := fmt.Fprint(w, `<!doctype html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Glaze App</title>
    <style>
        body {
            font-family: system-ui, sans-serif;
            margin: 2rem;
        }
        button {
            font: inherit;
            padding: 0.5rem 1rem;
        }
    </style>
</head>
<body>
    <h1>Local Go UI</h1>
    <p>This page is served by a Go http.Handler and displayed in a desktop WebView.</p>
    <button onclick="location.reload()">Reload</button>
</body>
</html>`)
        if err != nil {
            log.Printf("write response: %v", err)
        }
    })

    err := glaze.AppWindow(glaze.AppOptions{
        Title:   "Glaze App",
        Width:   1024,
        Height:  700,
        Handler: mux,
    })
    if err != nil {
        log.Fatal(err)
    }
}

This is the style of application I had in mind: local tools, internal utilities, small editors, dashboards, inspectors, and experiments.

The UI can still be plain HTML, CSS, and JavaScript. The backend can still be normal Go.

Calling Go from JavaScript

Glaze also supports binding Go functions to JavaScript.

That makes it possible to keep the UI lightweight while still doing real work in Go.

The goal is not to turn every application into a complex frontend. The useful case is exposing a small surface area: save a file, query local state, run a calculation, trigger an operation, or send an event.

This fits well with small tools where most of the logic belongs in Go and the WebView is mainly the presentation layer.

What Glaze is not trying to be

Glaze is not trying to replace mature GUI toolkits.

It is also not trying to replace larger frameworks for building full desktop applications.

Those projects usually solve broader problems: packaging, application lifecycle, icons, installers, auto-update, system integration, custom controls, and more.

Glaze is intentionally smaller.

The target use case is closer to:

“I have a Go tool and want a small local UI”
“I already have an HTTP handler and want to show it in a desktop window”
“I want HTML for layout but do not want to ship a browser”
“I want to avoid CGo in this project”
“I want a thin WebView layer instead of a full application framework”

That scope keeps the API easier to reason about.

Platform notes

macOS is the cleanest case because the Cocoa and WebKit frameworks are already part of the system.

Windows depends on the Microsoft Edge WebView2 Runtime, which is already present on current Windows installations in many cases.

Linux is the hard case. Different distributions package WebKitGTK differently, and dynamic library names matter. Glaze tries to detect GTK4/WebKitGTK first and falls back to GTK3/WebKitGTK where appropriate, but Linux still needs more testing across distributions.

That is one of the areas where feedback would be useful.

Current features

At the moment Glaze includes:

desktop WebView windows
JavaScript-to-Go binding
BindMethods helper for exposing exported Go methods
RenderHTML helper for Go templates
AppWindow for local net/http apps
Go-to-JavaScript event bridge
native file dialogs
native menu support on macOS and Windows
runnable visual examples

The repository also includes small demos such as Game of Life, Starfield, Doom Fire, Mandelbrot, Falling Sand, Raycasting, and a Filo REPL.

crgimenes / glaze

Glaze: a CGo-free desktop WebView toolkit for Go

Glaze

Glaze is a desktop WebView binding for Go. It is a pure-Go port of webview/webview built on purego, keeping CGo out of the picture. Each backend talks to the WebView framework the OS already ships -- WKWebView on macOS, WebKitGTK on Linux, WebView2 on Windows -- so nothing native is bundled.

It started as a fork of go-webview but has diverged enough to live as a separate codebase with its own goals and API.

Examples

Desktop	Game of Life	Starfield

Doom Fire	Mandelbrot	Falling Sand

Raycasting	Filo REPL

Why no CGo

This is the whole point of the project, and it's the part that's easy to miss. Most native-WebView bindings reach for CGo, which quietly takes back the things that make Go pleasant to ship: cross-compiling suddenly needs a matching C cross-compiler for every target (mingw for Windows, a sysroot for Linux), builds stop being reproducible, and go…

View on GitHub

Trade-offs

The main benefit is keeping the project close to regular Go development.

The main cost is that Glaze sits close to native platform APIs, so platform differences are real.

Some trade-offs are deliberate:

It does not bundle a browser.
It does not try to hide every OS difference.
It does not try to become a complete desktop framework.
Linux support depends on system WebKitGTK libraries.
Windows support depends on WebView2 runtime behavior.

For my use case, that is acceptable. I prefer a small, explicit layer over a large abstraction that hides too much.

Where I want to take it

The immediate focus is stability and examples.

The most valuable improvements right now are:

testing on more Linux distributions
better diagnostics when system WebView libraries are missing
more examples showing realistic local tools
API feedback from Go developers who build small desktop utilities
clearer documentation for platform-specific behavior

I am also interested in keeping the project boring in the good sense: small API, predictable behavior, explicit errors, and no unnecessary magic.

Repository

The project is here:

https://github.com/crgimenes/glaze

Feedback is welcome, especially around the API shape, Linux/WebKitGTK behavior, and whether the examples make the intended use case clear.