When our team needed an interactive planning tool for lunar surface missions, we started with what seemed like the obvious approach: a React web frontend backed by a Julia server. It worked, technically, but the developer experience was painful. Every piece of data had to be serialized over HTTP. UI bugs could live in JavaScript, Julia, or the communication layer between them. Adding a feature meant touching two codebases in two languages. For a small team, the overhead was eating us alive.

So we tried something different: build the whole thing in Julia. The result is a standalone desktop application for planning rover routes on the lunar south pole. The GUI renders terrain maps with sun illumination overlays, lets users place and adjust waypoints, and visualizes time-varying data like solar exposure and communications windows. One language, one process, no server. The underlying problem (interactive map-based visualization with custom overlays on top of a computation backend) comes up constantly in geospatial work, and the approach generalizes well beyond aerospace.

Dear ImGui (via CImGui.jl) handles all the UI: windows, sliders, buttons, menus, tables. It's an immediate-mode library, meaning every frame your code says "draw a button here, a slider there," and ImGui handles interaction. If your state changes, the UI reflects it next frame. No widget trees, no callbacks, no syncing.

Mirage.jl handles rendering. I wrote it because the available Julia OpenGL wrappers were too low-level for rapid prototyping. The API feels like HTML5 Canvas2D: draw_image(), fill_rect(), draw_circle(). It manages shaders and vertex buffers internally so you don't have to.

The immediate-mode approach has a real benefit beyond simplicity: there's no retained state to go stale. Your render function is a pure function of your application state, which is simply Julia variables. When we needed a new overlay, it was just a few draw calls in the right place, not a new component wired into a framework.

The biggest accelerator was the REPL workflow. Start the GUI from the Julia REPL, use it, close the window, change some code, reopen it. All state persists in the session. This turns GUI development into the same fast iteration loop Julia developers already use for everything else.

This stack is general-purpose. Any application that puts an interactive visual frontend on Julia computation could work this way: geospatial viewers, instrument control panels, simulation monitors, data exploration tools. For anyone who's built a QGIS plugin or wrestled with Electron to get a custom map tool out the door, this is a different way to think about the problem.

In this talk I'll cover:
- Why we moved away from a React/Julia split architecture
- How Dear ImGui and OpenGL compose into an application framework in Julia
- A live demo building an interactive geospatial visualization
- Practical trade-offs versus web-based and existing desktop GIS approaches

No graphics programming experience needed.