2026-08-14 –, Room 5
Julia has great tools for computation, but if you want to build an interactive desktop application with maps, real-time overlays, and custom visualizations, your options are limited. The usual answer is to reach for a web framework or Electron, which means maintaining a split codebase with a server layer in between.
That's what we did initially for SHERPA, a mission planning tool for NASA's lunar surface operations. We had a React frontend talking to a Julia backend over a local server, and it was clunky. Two languages, constant serialization, and every UI change meant context-switching between JavaScript and Julia. So we scrapped it and rebuilt the entire GUI in Julia using Dear ImGui (via CImGui.jl) for the interface and Mirage.jl, a custom OpenGL wrapper I wrote that gives you an HTML5 Canvas2D-style API for 2D and 3D rendering. No shader code or buffer management, just draw_image() and fill_rect() calls.
The real win is how this integrates with Julia's REPL. Our workflow is: start the GUI, use it, close the window, edit a function, reopen the GUI with all your state intact. Maps stay loaded, camera position is preserved, your scenario is right where you left it. This made it possible for a small team to go from nothing to a production tool in a few months, iterating on the GUI the same way you'd iterate on any Julia code.
This approach isn't specific to aerospace. Anything that needs interactive visualization on top of a Julia computation backend (lab instruments, geospatial tools, simulation dashboards, data exploration) could use the same stack. This talk covers how it all fits together, a live demo of the tools, and practical advice for building your own.
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, as well as maintaining state in two different places using two different metaphors. Not to mention trying to do custom 2D / 3D rendering meant mixing React and HTML5 Canvas. 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 stack has two pieces:
Dear ImGui (via CImGui.jl) handles all the UI: windows, sliders, buttons, menus, tables. It's an immediate-mode library, which means 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. This is a good match for scientific tools where the interface evolves constantly.
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. I later added 3D mesh rendering following the same minimal, immediate-mode philosophy.
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 current application state, and your current application state are simply Julia variables. When we needed a new overlay or visualization, it was usually just a few draw calls in the right place, not a new component wired into a framework.
But 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 application state persists in the session. This turns GUI development into the same fast iteration loop Julia developers already use for everything else, and it's something you really can't get with compiled GUI frameworks. It brings the fast-paced iteration of the web ecosystem (like React) into Julia.
This stack is general-purpose. Any application that puts an interactive visual frontend on Julia computation could work this way: instrument control panels, geospatial viewers, simulation monitors, data exploration tools. The patterns are the same regardless of domain.
In this talk I'll cover:
- Why we moved away from a React/Julia split architecture and what we gained
- How Dear ImGui and OpenGL compose into an application framework in Julia
- How Mirage.jl maps Canvas2D-style calls to OpenGL
- A live demo of the tools in action
- Practical patterns for structuring a Julia GUI app, and the rough edges to watch for
No graphics programming experience needed.
I'm Zach, Lead Software Engineer on the SHERPA project at NASA ARC. I've been doing rover strategic simulations and mission planning for the VIPER project for a few years now. I dabble in indie game development, I released my game Vector Prospector on Steam in 2020. I've been programming since I was eight, and I live in Newport Beach, California.