Blinc is a Rust UI framework that renders the interface on the GPU

The interface is drawn on the GPU

Blinc describes itself as a GPU-accelerated, cross-platform UI framework for building desktop, mobile and web applications from a single Rust codebase.

The rendering approach is the part that sets it apart, and the highlights list names it: SDF rendering, glassmorphism, spring physics and @flow custom shaders.

Signed distance field rendering means the interface is described as distance fields rather than as triangles, and the geometry is evaluated on the GPU. For a UI that is mostly rectangles, rounded corners, shadows and text, that representation is a good fit, and it is what makes effects like a frosted glass panel cheap: the blur and the rounded edge are properties of the field rather than a texture and a mask.

The glassmorphism in that list is a design effect rather than a technical one, but it is a demanding one to render, and it is a reasonable signal of what the renderer is capable of.

Spring physics is the other entry, and it is the animation model rather than a library bolted on. The crate list shows a dedicated blinc_animation crate for springs, keyframes and timelines, so animation is part of the framework's data model rather than something each application wires up.

Then there is @flow custom shaders, which is the escape hatch. A framework that renders everything itself needs a way for an application to add its own effects, and a shader pipeline is how that works.

Underneath all of it is wgpu, which appears in the platform table as the backend for every platform: Metal on macOS and iOS, DX12 or Vulkan on Windows, Vulkan on Linux and Android, Vulkan or OpenGL ES for the HarmonyOS work in progress, and WebGPU for the browser.

One backend across all of them is a substantial engineering decision, and it is the reason the same interface code can run everywhere.

The builder API and what a first program looks like

The quick start is short enough to read in one pass.

use blinc_app::prelude::*;
use blinc_app::windowed::WindowedApp;

fn main() -> Result<()> {
    WindowedApp::run(WindowConfig::default(), |ctx| {
        div()
            .w(ctx.width).h(ctx.height)
            .bg(Color::rgb(0.1, 0.1, 0.15))
            .justify_center().items_center()
            .child(text("Hello Blinc!").size(48.0).color(Color::WHITE))
    })
}

The shape is the thing to understand. There is no separate element tree data structure and no separate render step; the interface is a value built by calling methods.

The div function creates a container, and then the methods chain. w and h set the dimensions from the context. bg sets the background colour. justify_center and items_center set the alignment. And child adds a child element, which is a text call with its own size and colour.

So the whole program is one expression tree assembled inside a closure that receives the context, and the closure is passed to WindowedApp::run along with a WindowConfig. The context is what supplies the window dimensions.

The highlights give the same idea in one line, with div().flex_col().gap(16.0).child(text("Hello")), so the naming convention is: the builder function names the element, the methods are the properties, and child is how content goes in.

What follows the example is the sentence that explains the ambition. The same build_ui function runs on desktop and web and no separate codebase.

That is the claim worth testing, because it is the one that is easy to claim and hard to deliver. It holds only if the platform-specific behaviour is confined to what the platform extensions abstract, and the crate list suggests that is the intent: blinc_platform holds the cross-platform traits, and each platform crate, desktop with winit, Android with the NDK, iOS with UIKit and Metal, and web with WebGPU and WASM, implements them.

The elements and their properties are built by blinc_layout, which the crate table describes as Flexbox layout, element builders and widgets. Flexbox is the layout model, which is the same choice the web made years ago and the one most UI toolkits that came after have converged on.

And the styling side is separate again, with blinc_theme holding design tokens and light and dark mode, and blinc_css in the workspace. So there is a layer above the builder where the visual language lives.

Forty components and forty live demos

Two numbers in the highlights are worth taking separately, because they say different things.

Forty plus components, described as a shadcn/ui-style library with CSS-overridable theming. The shadcn comparison is the key. shadcn/ui is not a component library you install as a package, it is a set of components whose source you copy into your project so you own and can modify them. A shadcn-style library in Rust follows that model in spirit, and the CSS-overridable theming is what makes it work: you can restyle a component with your own CSS rather than by passing configuration through every constructor.

That is a meaningfully different philosophy from a closed component library, and it is a coherent choice for a framework that renders its own widgets. Since the components are drawn by the framework's own renderer rather than being platform native controls, they are already custom-drawn, and the styling hooks follow from that.

The component crate is blinc_cn, with the cn suffix matching the shadcn reference, and there is a blinc_cn_dsl beside it. The icon crate is blinc_icons with the Lucide icon set.

Forty plus live demos is the other number, and it is a different kind of claim. They are interactive WebGPU demos running in your browser, which means the framework's behaviour can be checked without installing anything at all, on a machine with a browser that supports WebGPU.

That is a significant piece of the cross-platform story. The browser target is the one where you can most easily show someone what you built, and the gallery is effectively a live test suite for the rendering and interaction behaviour.

The documentation arrangement is worth noting too. There is the Blinc Book, a comprehensive guide covering layout, styling, animation, widgets, routing, media and more. There is the API reference on docs.rs. And there is a Skills.md, described as a concise, example-driven reference for AI code agents, which is the same convention of writing a short machine-oriented summary that other projects have adopted.

The examples directory backs the gallery up. Alongside the main examples crate there are separate web example crates for hello, scroll, drag, assets, a mobile demo, typography, text widgets and text position, and a _generated directory for the auto-generated WebAssembly wrappers produced by the build-web-examples tool.

Building the examples and the sibling crates

The examples section contains the most practically useful part of the documentation, and it starts with the claim that a fresh clone builds every example with no extra setup.

The sibling crates, which are blinc_canvas_kit, blinc_portal_ui, blinc_node_editor and blinc_game_kit, resolve from their published git pins. So they live in their own repositories and the workspace points at specific commits of them rather than vendoring their source.

cargo run -p blinc_app_examples --example cn_demo --features cn

That runs one example from the examples crate with the cn feature enabled. The naming is worth noting: the examples live in their own crate rather than inside blinc_app, and the comment in the workspace file explains why. It is a separate crate so that its 35MB of assets, being videos, 3D models and HDRIs, do not bloat the published blinc_app package.

That is a packaging decision with a real cost avoided. A crate that ships 35MB of demo assets downloads those assets for every user of the framework, whether or not they run the examples.

The sibling crates section is about editing them locally, and it is where the care in this project shows.

./scripts/use-local-packages.sh   # clones them into packages/ (gitignored)
                                  # and redirects the workspace to those copies

The script clones them into a packages directory, which is gitignored, and redirects the workspace to those copies. And then the warning, which is the important part: this modifies Cargo.toml locally only, do not commit it, because CI's check-no-local-patch.sh guard rejects it.

So there is a script in CI whose entire job is to make sure nobody accidentally commits a local development override into the shared manifest. That is a small thing that saves a class of confusing breakage, where a pull request contains a path override that only resolves on the author's machine.

And there is the way back:

./scripts/use-published-packages.sh

The existence of a revert script, listed in the same section, is what makes the local workflow safe to use at all.

Tuning the build for a machine with 8GB of RAM

There is a section of the documentation that is unusual to find in a framework README, and it is the one about building on low-resource machines.

The debug profile is tuned so a workspace build fits comfortably on around 8GB of RAM and a small SSD. The mechanism is that dependencies are compiled without debuginfo and workspace crates use line-table backtraces only, with the file and line still resolving.

That last part is the detail that makes the trade acceptable. Stripping debuginfo usually means you lose the ability to step through or inspect variables in a debugger. Line tables are the middle ground: the backtrace still tells you which file and line a frame came from, without the per-variable and per-type information that dominates the size.

The documentation calls it the single biggest lever for both the target directory size and peak linker memory, and says that no configuration is needed, which means it is already in the profile settings rather than something you have to opt into.

Then there is the escalation path for when a full workspace build still thrashes or runs out of memory on a constrained box, such as an 8GB ASUS NUC. Four suggestions are given, in order of impact.

Build only what you need rather than the whole workspace, which is the cargo run command above. Cap parallelism so N rustc processes do not collectively exhaust RAM, with CARGO_BUILD_JOBS=4 cargo build or by uncommenting the jobs setting in the .cargo/config.toml, and the advice to start near half your core count. Use a faster, lower-memory linker, mold on Linux and lld on macOS, with the commented target blocks in the config file for it, and the observation that linking is the heaviest single step on low-RAM machines. And reclaim SSD space with CARGO_INCREMENTAL=0 for a smaller target directory at the cost of slower warm rebuilds, plus cargo clean between large feature switches.

The ordering is the useful part, because the first two are free and the last one costs you time. A reader who is out of memory will try these in the right order if they are told the order.

The .cargo/ directory at the repository root holds that configuration, and the .vscode/ directory holds editor settings.

Platform status, the roadmap and the crate layout

The platform table is a status board rather than a feature list, and reading the statuses tells you where the project is.

macOS, Windows, Linux, Android and iOS are all marked stable, with their wgpu backends given. The web target is marked preview, and the browser requirements are spelled out: WebGPU, meaning Chrome 113 and later, Edge 113 and later, Firefox 141 and later, and Safari 18 and later on macOS Tahoe. HarmonyOS is in progress with a Vulkan or OpenGL ES backend.

So five stable platforms, one preview and one in progress. The web being the preview one is the interesting choice, since it is the target with the most reach and the one with the most severe browser constraints.

The roadmap lists the current focus as four items. Missing widgets, specifically a date and time picker, a colour picker and a data grid. Zyntax, a .blinc domain specific language for UI definitions, with support for live editing and hot reload in the future. Accessibility, covering screen reader support and keyboard navigation. And developer tooling, meaning hot reload and a visual inspector.

Two of those deserve comment. Accessibility being on the roadmap rather than shipped is the most consequential gap for a UI framework, since it is a requirement for a great many users and it is the kind of thing that is hard to retrofit. The Zyntax DSL is the ambitious one, a whole separate language for describing interfaces, and the workspace file gives it a candid treatment: the DSL crate is behind a risk-reduction prototype and there is a staged plan in the roadmap section it points at.

The crate table is a good map of the architecture, and the grouping into Core, Rendering, Animation, Components and Platform is the important part. The core is blinc_app for the framework and runners, blinc_core for signals, state machines and types, and blinc_layout for the Flexbox engine. The rendering group covers text shaping and the glyph atlas, SVG parsing and rasterization, image decoding with lazy loading, and the canvas and paint API. The platform group holds the traits and the four or five platform implementations.

And there is blinc_cli on crates.io, with the recent releases named Blinc CLI 0.1.0, 0.1.1 and 0.4.0. The framework itself is Apache-2.0 licensed, needs Rust 1.85 or later, and uses edition 2024.

Editorial conclusion

Adopt Blinc if you want one Rust codebase to target desktop, mobile and the browser with a GPU-rendered interface, since that cross-platform claim is what the crate split and the platform extensions are built around. Skip it if you need a stable, mature toolkit with a long support history, since the version line is at 0.4.0 and the web target is still marked preview, and if you need accessibility today, because it is on the roadmap rather than shipped. Verify first which platform backends you need, since the web build requires WebGPU and specific browser versions, that you have the Rust edition and version the project expects, and how you intend to develop the sibling crates, because the local override script changes your workspace and CI rejects the change.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. project-blinc/Blinc on GitHub
3. Project website
4. README
5. Releases