Makepad: a Rust UI runtime with a live-editable DSL and a wasm build pipeline

The problem Makepad targets, and who it is actually for

Most Rust GUI projects make you choose between a native window and a browser target, and then make you rebuild the interface for whichever one you picked. Makepad's stated aim is a single UI runtime that compiles to wasm/WebGL, macOS/Metal, Windows/DX11 and Linux/OpenGL, with the same widget code behind all four. The README describes it as "a cross-platform UI runtime for native and web targets" and "a Rust-first framework with a scriptable UI DSL".

The audience is narrower than that sentence suggests. The repository is a Cargo workspace whose members include apps/browser, apps/terminal, apps/sheets, apps/photos, apps/mail and apps/calendar. That is not a widget library with a demo. It is an application platform, and the examples are the documentation. If you want a small dependency that draws a settings dialog, this is the wrong shape of project. If you are building a desktop-class application in Rust and want the option of shipping the same code to a browser, the workspace layout tells you the authors are doing exactly that themselves.

The second audience is people working with local generative models. The README says the repository has "a large set of AI backends integrated for embedding llms or generative AI models inside applications or run them easily on local hardware".

How the runtime, the DSL and the Studio fit together

Three pieces are visible from the repository structure. The first is the runtime and widget layer, spread across libs/, widgets/, draw/ and platform/. The second is the script engine, which the README lists as "live-editable UI DSL and runtime script integration". The third is the studio app, which the README describes as "for running, inspecting, and iterating on examples and projects"; the README's main entry point for exploring the apps is the Makepad desktop, run with cargo run -p makepad-app-wm --release.

The DSL is the design decision worth arguing about. A scriptable UI language means interface structure can change without a Rust recompile, which is what makes the live-editing loop possible. The cost is a second language to learn and a boundary between script and compiled code that you have to reason about when something breaks. The README does not document that boundary, so treat it as something you will learn from the examples directory rather than from prose.

The README also mentions "AI automation inside Studio to control and inspect UI", which means the studio is intended to be driven programmatically, not only by hand. For a team already using coding assistants, that is the most distinctive claim in the README, and also the one with the least documentation behind it.

Installing Makepad and running a first example

The README's prerequisite is a Rust toolchain, noting that stable works for native targets.

Once Rust is present, the shortest path to a running window is one of the bundled examples. The Splash demo is the README's simple animated demo:

cargo run -p makepad-example-splash --release

The first build compiles the engine and the example, so expect it to take a while. When it finishes you should see an animated window. Two other examples are listed in the same block: cargo run -p makepad-example-gltf --release for glTF rendering and cargo run -p makepad-example-map --release for maps. The map example needs its tiles first:

./tools/download_map.sh
./tools/download_voice.sh

Linux is the platform to be careful with. The README points at ./tools/linux_deps.sh and gives an apt-get line covering X11, Wayland, EGL, GBM, Mesa and a long list of GStreamer packages. On Ubuntu or WSL2 you can run the script instead of pasting that list.

For targets other than desktop, Makepad ships its own build tool rather than relying on cargo directly:

cargo install --path=./tools/cargo_makepad

After that, toolchains are installed per target, for example cargo makepad wasm install-toolchain, cargo makepad apple ios install-toolchain, or cargo makepad android --abi=all install-toolchain. A wasm example then runs with cargo makepad wasm run -p makepad-example-splash --release.

The wasm size pipeline is the most developed part of the tooling

The README devotes more space to wasm output size than to any other single topic, and the flags interact. The base shipping build is:

cargo makepad wasm build -p makepad-example-splash --profile=small --strip

--strip removes custom sections such as names and producers. --strip-custom-sections is documented as preserving the older behaviour when you only want custom sections gone. --profile=small uses smaller fonts and is described as pairing well with --strip. --no-threads trims the web thread bridge and thread exports when threading is off.

The split pass is the unusual one. Adding --split emits a primary wasm plus secondary payloads named .secondary.wasm and .data.bin, and implies function splitting. Bare --split uses what the README calls an automatic cold-first policy: it moves defer-safe cold functions into a secondary wasm so startup can begin on the primary first, and falls back to the normal function split when there are no useful cold candidates. You can override the threshold directly:

cargo makepad wasm build -p makepad-example-splash --release --strip --split=200

For the smallest result, combine Binaryen IR optimization and Brotli compression. --wasm-opt runs Binaryen wasm-opt -Os and requires Binaryen installed separately (brew install binaryen or apt install binaryen). --brotli compresses .wasm and assets. The full combination shown in the README is:

cargo makepad wasm build -p makepad-example-splash --release --wasm-opt --strip --split --brotli

One detail worth noting: the README states the wasm linker packs relocations before the post-link size and split passes. That ordering matters if you are debugging why a split point landed where it did.

Where Makepad will cost you time

The main issue is release discipline. The only release listed is tagged pre-alpha and dated 2019-12-08. The default branch is dev, and the last push was on 2026-11-02. So the code moves, but there is no tagged version to pin against and no documented upgrade path. If your organisation requires semantic versioning before adoption, Makepad does not offer it today.

Makepad against iced and other Rust UI toolkits

The natural comparison is iced, the other widely used Rust GUI toolkit. The difference is architectural rather than cosmetic. iced is an Elm-style framework: you write a message enum, an update function and a view function, and the framework owns the state transition loop in Rust. Makepad puts a scriptable DSL between you and the runtime, so interface structure is expressed in a live-editable script rather than in Rust view functions, and the Studio can inspect and modify a running interface.

That changes what iteration feels like. With iced, a layout change is a recompile. With Makepad, the README's claim is a live-editable UI where the loop is tighter. The trade is that iced's model is plain Rust with no second language and a smaller conceptual surface, while Makepad asks you to learn its DSL and accept that the script/runtime boundary is not documented in the README.

The second difference is target breadth. Makepad ships its own cargo subcommand for iOS, tvOS, Android and wasm toolchain installation, and documents a wasm size pipeline with splitting and compression. If browser delivery with a size budget is a requirement, that pipeline is the reason to look at Makepad first. If you only ever ship a desktop binary and want the smallest possible dependency, the DSL and the build tool are overhead you are paying for nothing.

Editorial conclusion

Adopt Makepad if you are building a Rust application that needs one UI codebase across macOS, Windows, Linux and wasm, and you are willing to work against a repository whose only tagged release is a pre-alpha from 2019. Do not adopt it if you need a stable API contract or a documented upgrade path; the README does not describe one. Before committing, run the Splash example on your own machine, then run the wasm build with --strip --split --brotli and inspect the emitted primary and secondary payloads, because that output is the part of the toolchain most likely to shape your deployment.

Frequently asked questions

Official sources

1. License: MIT
2. makepad/makepad on GitHub
3. Project website
4. README
5. Releases