DEV Community: Sai Chandan Kadarla

Building Vel: A Token-Efficient, Compile-to-Native UI Language

Sai Chandan Kadarla — Sun, 07 Jun 2026 19:42:05 +0000

I've been building Vel — a new declarative UI language plus the runtime and component registry to back it. The goal is unapologetically ambitious: write production desktop apps with the expressive density of Tailwind classes, the reactivity model of SolidJS, and the rendering quality of Flutter, while letting you call into any existing C/C++ backend without a binding layer.

This post walks through the architecture I landed on, why each tier exists, and what the language actually buys you in practice.

The three-tier rule

Most UI frameworks blur three concerns: the language, the runtime substrate, and the opinionated widget set. Vel splits them on purpose, with a strict one-way dependency:

language  →  framework  →  registry  →  application
(velc)       (libvel)       (vel::ui::*)    (.vel + main.cpp)

Language: a small, indentation-sensitive DSL (.vel) and a single-pass compiler (velc). It parses to an AST, type-checks against a primitive registry, and emits idiomatic modern C++ that consumes the framework.
Framework (libvel): the substrate. Widget pipeline (measure / place / paint / tick), Skia-backed Painter, an event dispatcher, the reactive primitives (Signal<T>, Computed<T>, AsyncSignal<T>), and infra (router, storage, net shim, IO, time, validate, notify, JSON, typed context). No application policy — no themes, no shortcuts, no business rules.
Registry (vel::ui::*): 43 baseline widgets in the shadcn idiom — Btn, Card, Tabs, Accordion, Dialog, Sheet, Table, TreeView, Stepper, Image, and so on. Built by composing framework primitives. Third parties can ship their own registries as plain .vel files; the language has cross-file imports as a first-class feature.
Application: your .vel files and a thin main.cpp shell. Themes, keyboard shortcuts, and routing decisions live here.

Code in a higher tier never reaches into a lower one. The framework never imports an icon set. The runtime never hardcodes a key combo. This isn't religion; it's the only way the language stays composable as third-party registries appear.

Why a DSL — and why compile to C++?

Two reasons.

First, source-token density. The same UI in JSX vs. Vel:

<View style={{padding: 24, gap: 12, backgroundColor: theme.bg0, borderRadius: 12}}>
  <Text style={{color: theme.fg, fontWeight: '700'}}>Hello</Text>
</View>

V p=lg g=md bg=bg0 r=md
  T "Hello" font=bold

That's roughly a 4–6× compression on real components without losing the declarative shape. For LLMs writing UI, that's the difference between fitting a feature in context and not. Vel was designed from day one with agent-authored code as a primary user.

Second, no VM at runtime. Vel compiles directly to typed C++ that calls into a static libvel. There's no interpreter loop, no JIT, no garbage collector. Layout, paint, and event dispatch are all monomorphic virtual calls on stable widget instances. On idle, the app sits in glfwWaitEventsTimeout and uses ~0 CPU — a global frame-dirty flag short-circuits the entire pipeline until something changes.

The reactive substrate

The keystone primitive is Signal<T> — a value plus a listener list. Everything reactive flows from it.

In the DSL, @state declarations become typed Signal<T> members on the generated component:

#Counter
  @count = 0
  @doubled = $count * 2          // detected as derived → Computed<int>
  @users: std::vector<User> = await fetchUsers()  // → AsyncSignal<...>

  V g=md
    T "Count: {$count}, doubled: {$doubled}" font=bold
    Btn "++" -> click => $count = $count + 1
    if $users.loading
      Spinner
    else
      for u in $users.value
        T "{u.name}"

What velc emits, semantically:

Signal<int> count_{0} — plain reactive cell.
Computed<int> doubled_{ [this]{ return count_.get() * 2; } } — the codegen walks the init expression's AST, finds $count as a dependency, and binds the computed to it. Any count_.set(...) propagates: count → computed → component → needsRebuild_ = true.
AsyncSignal<std::vector<User>> users_ — kicked off with std::async(std::launch::async, ...), polled each tick. Exposes .loading / .ready / .value / .error as method calls in the DSL.
The component constructor .listen()s every signal it owns. The next tick() calls rebuild(), re-measures, and re-places before the frame paints. Tree rebuilds are coarse-grained — like React's setState, not Solid's fine-grained reactivity — but the granularity is set per #Component, so it composes cleanly.

Effects (~ $a $b => body) compile to per-dep listeners — declarative side effects without polluting event handlers.

First-class C/C++ interop

The single most important constraint I set: you must be able to drop any existing C++ codebase into Vel with one line. No bindings, no schemas, no IDL. The language gives you two primitives:

use "myorg/db.h"        // raw C++ include — verbatim
use "ui/card.vel"        // cross-file vel import — pulls in components

Once a header is in scope, qualified names work in every expression. The lexer learned :: so db::fetchUsers(), std::vector<myorg::User>, and await myapp::loadAsync() all parse and codegen straight through to the underlying calls. The framework knows nothing about your backend — velc just emits the include and the call site. Your existing C++ links into the binary like any other translation unit.

This is the reason Vel exists at all. Every other "new UI language" I've tried makes interop a second-class citizen. Here, the interop is part of the type system from day one — state can be of any C++ type, expressions can call any user namespace, and the DSL's type annotations support templates.

Architecture of the rendering pipeline

The render path is Skia all the way down, but Vel adds a few layout patterns worth noting:

Constraints model: identical to Flutter (min/max W/H), one measure pass returns intrinsic size, one place pass writes final rects. A small but important fix in Vel — when the cross axis is unbounded (e.g. inside a scrollable), align=Stretch degrades to Start so children don't get infinite size cascades.
Frame-level damage tracking: an atomic frameDirty flag, raised by any Widget::markDirty() call, controls whether the next frame runs at all. Animating widgets re-arm the flag from their tick(); static pages don't.
Portal layer for overlays: tooltips, popovers, dialogs, sheets, menus, and toasts go through an OverlayHost that owns a per-frame portal queue. Widgets nested inside scrolled containers register their panel rect plus the current scroll offset, so the panel paints in screen space regardless of where in the tree it was declared. This solved the classic "popover gets clipped by a Card with clipContent" problem cleanly.
DPR awareness: the GL context is created at framebuffer resolution, the widget tree lays out in logical points, and the canvas matrix is scaled on each paint. Resize is handled by re-creating the Skia surface against the new framebuffer.

The registry as a primitive, not a library

The 43-widget baseline ships in vel/ui/, but the registry mechanic isn't reserved for the framework. Any .vel file is a registry artifact. Example:

// widgets/stat.vel
#Stat label:str value:str hint:str=""
  Card elev=1
    V g=xs
      T $label fg=fgMuted font=uiSm
      T $value font=bold/display
      if $hint != ""
        T $hint fg=fgFaint font=uiSm

// showcase.vel
use "widgets/stat.vel"

#Showcase
  H g=md
    Stat label="MAU" value="42,103" hint="last 30 days"
    Stat label="Latency" value="84ms" hint="p99"
    Stat label="Errors" value="0.02%" hint="↓ 18%"

velc resolves the import, parses the imported file to extract the component's param signature, and at the call site emits std::make_unique<vel::gen::Stat>("MAU", "42,103", "last 30 days") — positional constructor args, type-checked statically by the C++ compiler downstream. Third parties can ship registries as bare .vel files via git, vendoring, or eventually a package manifest.

What's working today

Compiler with lexer, parser (forward-progress-guarded), type checker, codegen, and --watch mode.
Reactive substrate: Signal<T>, Computed<T>, AsyncSignal<T>, PersistentSignal<T> (auto-syncs to disk), effects, typed ctx<T>(key) Provider substrate.
Framework primitives: Router (path matching, history), storage (JSON-backed KV), net (pluggable HTTP shim), io (file ops + watcher), time (debounce / throttle / interval / timeout), validate (form rules), notify (toast bus), json (wraps nlohmann), per-widget cursor states, theme switching with full tree rebuild.
Registry: 43 widgets including Table (virtualized, sortable, multi-select), TreeView, Stepper, Image (Skia-decoded with LRU cache), and the full shadcn-style overlay set.
DX: agent-readable widgets.json regenerated on every build; cross-file imports; --watch for hot iteration.

What's next

The big open items are hot reload (file watch is in; dlopen swap of the generated .so is not), a real vel.json package manifest, per-widget damage rectangles (right now damage is frame-level), and a few more registry primitives — Video, SVG, devtools overlay, a syntax-highlighted code editor.

If the three-tier story holds — and so far it does — Vel ends up being the smallest source surface area you can use to ship a production native desktop app, with the deepest backend interop story of any framework I'm aware of.

I'll keep posting as the registry grows.

From Skia to Lume: writing my own 2D rendering engine for Vel

Sai Chandan Kadarla — Sun, 07 Jun 2026 19:21:02 +0000

Vel is about a week old. I started it as a DSL plus framework experiment, and from day one the rendering substrate was Skia. That wasn't an accident. Skia is the most complete 2D rendering API you can drop into a C++ project today. Clean canvas surface, built-in text with system font fallback, image decode, a GPU backend that already works on every desktop OS. If you want a UI framework drawing pixels by the end of the week, Skia is what you reach for.

But the plan was always to replace it. Skia is a brilliant CPU-rasterization library bolted to a GPU backend, and as soon as you push it hard, the bolts show. Flutter publicly battled this same class of problems for years before they shipped Impeller and finally got rid of the runtime shader-compilation jank that made early Flutter apps stutter. I'd rather not repeat their story. So once the DSL was working and the framework was responding to my changes the way I wanted, I started writing the renderer I actually needed.

The new engine is called Lume. It lives in engine/ of the Vel repo. This post is about why I started with Skia, why I'm replacing it now, and what Lume does differently.

Why Skia first

Skia gave Vel three things I needed in the first few days of having a framework at all:

A clean SkCanvas API the widget pipeline could draw into without me writing any GPU code.
A working text renderer (CoreText on macOS, FreeType elsewhere, all behind the same API) with system font fallback.
Image decode plus GPU upload as table-stakes, so Image widgets just worked.

That let me focus on the actual hard problem of the framework, the DSL and the reactive substrate. Layout, signals, hot-reload, event dispatch, the widget registry. The rendering substrate didn't need to be mine yet. Skia was a load-bearing dependency for exactly the amount of time it took the rest of the system to stop being the bottleneck.

Why I'm replacing it now

Once the DSL and framework were in shape, I had a clear view of what the renderer was actually doing for me, and what it was going to cost as the surface area grew. Three things, all well-known to anyone who's tried to ship a Skia-based UI runtime at scale.

1. Shader compilation jank. Skia compiles shaders the first time it sees a new primitive during the frame that wants to draw it. The first time you open a dialog with a blur, you pay 40 to 120 ms while Skia builds the right shader for the GPU. Flutter spent years trying to predict and pre-warm these (the infamous "skp shader cache") and never fully won. The Impeller team's own postmortem describes this as the engine's defining flaw.

2. Tessellation on the CPU. Skia turns rounded rectangles, strokes, and curves into triangle meshes on the CPU, then ships them to the GPU. For one card it's free. For a table of 200 rows with rounded corners and hover highlights, the CPU is doing a lot of work that a fragment shader could do once and for all with an analytic SDF.

3. The framework didn't own its render path. This was the real one. Every cross-cutting question I expected to hit later (popovers clipping inside scroll views, text positioning in tight cells, atlas eviction policy, draw order across overlays, HiDPI handling) was eventually going to bottom out in Skia's behavior, and the answer was always going to be "work around it." When you don't control the rendering substrate, every one of those concerns is something you negotiate with a library that doesn't know what your widgets are.

I'm not the first person to land here. Flutter, Servo, Bevy's UI work, Slint: every team building a rendering-heavy UI runtime has eventually concluded that owning the engine is the only way to make the rest of the system answer to one design. The cheaper time to do it is before you have a year of code depending on someone else's render path.

What I borrowed from Flutter

Impeller's defining decision is ahead-of-time shader compilation. Every shader the engine could ever need is compiled at build time into Metal or Vulkan IR and bundled with the binary. The "first render is slow" problem goes away because there is no first render. Every shader has already been seen.

That insight was the foundation. The other thing I borrowed: keep the pipeline list small. Impeller has on the order of a dozen pipelines, not hundreds. The way you do that is by reducing every primitive you draw to a small set of canonical shapes (rounded rects with optional ring strokes, textured quads, line segments) and varying their behavior through uniforms, not new shaders.

Lume's pipeline count today is four:

Shape: analytic SDF rounded-rect. Fills, strokes, circles, lines, soft shadows all collapse to this.
Line: per-segment rotated quad with butt caps for polylines.
Text: textured quad sampling an R8 glyph atlas.
Image: textured quad sampling RGBA8 with corner-radius mask.

Every shape in the Vel showcase is one of those four primitives. A roundedFill is the shape pipeline with strokeWidth=0, radius=R. A shadowRect is the same pipeline with blur>0, which switches the fragment shader to a smoothstep falloff instead of the AA clamp. A circleStroke is a shape with radius=w/2. The instance attributes do the heavy lifting; the GPU just rasterizes.

What Lume actually is

The architecture is four layers:

L1  platform/   → CAMetalLayer attach (macOS). Future: ANativeWindow, HWND, canvas.
L2  gpu::Device → Dawn instance + adapter + device + queue (singleton).
L2  gpu::Surface → wgpu::Surface bound to the window's native layer.
L3  paint/      → DawnPainterImpl: four WGSL pipelines, glyph atlas,
                  per-instance state for shape/line/text/image, submission-
                  order draw segments.
L4  Painter API → public surface: fill, roundedFill, stroke, polyline,
                  arc, image, text, pushClip, pushTransform, and so on.

The whole stack is engine/include/vel/ (public headers) plus engine/src/ (about 3,000 lines of implementation). The framework calls into the Painter API and never sees a WebGPU type.

Three details that took real effort:

The glyph atlas is keyed on physical pixel size. When you ask for 14 px text on a 2× DPR display, FreeType rasterizes at 28 px. Lume's atlas cache key includes that physical size, so a window dragged to a 1× external monitor doesn't render upsampled-blurry text. It just rasterizes a second 14 px entry and uses that. The dst rect stays in logical pixels; the GPU samples the physical atlas 1:1.

Submission-order draw segments. Originally Lume batched all-shapes, then all-lines, then all-text per frame. This broke the Table widget's sticky header: the header background was drawn before the row text, so row text overdrew the header bg, and rows became visible through the header during scroll. The fix was to track a small DrawCmd list ({kind, firstInstance, count}) in submission order and emit one Draw call per segment. Same-kind cmds fuse. The Table works, and any widget that depends on draw order ("this card needs to be on top of those cards") works for the same reason.

Drag capture survives reactive rebuilds. Vel is signal-driven. When the user drags a Slider, the slider writes to a signal, which triggers a re-render, which replaces the Slider widget instance. The new instance has dragging_=false. The drag dies after one mouse-move event. The fix wasn't in Lume; it was in the framework's EventDispatcher. captureDrag(handler) registers a callable that closes over the slider's geometry plus its onChange (whose own closure captures the long-lived owning component's this). Mouse-move and mouse-up route to the captured handler directly, bypassing the widget tree. Drag continues across any number of rebuilds.

The Skia / Impeller / Lume comparison

The dimensions that matter for a 2D UI runtime:

	Skia (Vel v1)	Impeller (Flutter)	Lume (Vel today)
Shader compilation	JIT, at first-draw time	AOT, build-time	WGSL precompiled by Dawn at device init
Shape rendering	CPU tessellation → GPU triangles	Compute + tessellation hybrid	Analytic SDF in the fragment shader
Pipeline count	hundreds (one per primitive + state combo)	~12	4
Text	CoreText / FreeType per platform	Manual rasterizer → MTLTexture atlas	FreeType → R8 atlas, OS/2 typo metrics
Idle frame cost	Always paints	Always paints	~0 (frame-dirty flag short-circuits the whole pipeline)
HiDPI	Surface scaled in canvas	Per-pass DPR awareness	Atlas keyed on physical px; dst rect in logical px
Cross-platform reach	GL/Vulkan/Metal/D3D11	Metal + Vulkan (+ work-in-progress)	Dawn handles Metal/Vulkan/D3D12/WebGPU from one WGSL source
Library code in libvel	Skia + image codecs (~25 MB linked)	n/a	0
`libvel.dylib` size (macOS arm64)	~30 MB	n/a	11 MB
Hot-reload safety	Crashes if plugin link drops Skia symbols	n/a	Plugin links the same `libvel.dylib`; nothing else to share

The single most useful number on that table is the bottom one. With Skia gone, the hot-reload plugin no longer needs to think about which graphics symbols it shares with the host. libvel.dylib is the sole boundary. A hot reload re-emits a .vel.cpp, recompiles 200 lines, and dlopens the new dylib in under a second.

What Lume doesn't do yet (the honest section)

This is the first usable version of the engine, and I'd be lying if I said it was at parity with Skia for every workload. Three real gaps:

Compute-shader Gaussian blur. Lume's shadow is currently a smoothstep outer falloff applied to the rounded-rect SDF. For small blur radii (4 to 16 px, which covers most UI shadows) it's perceptually identical to a Gaussian. For larger radii it reads as "the rect got bigger and softer at the edges" rather than a true Gaussian. A two-pass separable Gaussian in a compute pipeline is next; for now the cheap approximation is honest about what it is.

Complex-script text shaping. I link HarfBuzz; I don't drive it yet. Latin, Cyrillic, and Greek render correctly. Arabic ligatures, Devanagari conjuncts, vertical text: those are next. The FreeType path is in; the HarfBuzz shaping pass on top of it isn't.

The platform surface is macOS-only. Dawn supports Vulkan and D3D12, so the underlying portability is real. The part missing is the window-to-surface glue. Lume has a SurfaceMac.mm that attaches a CAMetalLayer to a GLFW window's NSView; the Windows and Linux equivalents are file-shaped holes today. CI builds compile against the abstraction, but the surface code is the actual port.

The roadmap continues from here: native arcs and dashed strokes via additional pipelines, then HarfBuzz, then compute blur, then a Web target via Dawn plus Emscripten, then Windows and Linux surface layers, then partial-repaint damage rects. Owning the engine means the work is real, but at least it's bounded.

The journey is in the git log

The proof that Lume isn't a paper exercise is the diff. The Skia removal was commit 0d7a8f4. The reorganized four-tier repo (Lume in engine/, the framework in framework/, the component registry in registry/, and the .vel compiler in velc/) is f5b86af. grep -rE 'Sk[A-Z]|sk_sp' engine framework registry velc returns zero hits. The dependency list in vcpkg.json is six lines now, none of them Skia.

dawn          : GPU abstraction (Metal/Vulkan/D3D12/WebGPU)
freetype      : glyph rasterization
harfbuzz      : complex-script shaping (next)
glfw3         : windowing
spdlog        : logging
nlohmann-json : JSON for the framework

If you want to read it, the code is at github.com/chan27-2/Vel. The README's Lume section walks the engine specifically; the engine/ tree on main is the smallest version of "a 2D GPU rendering engine you can actually run" I know how to write.

The lesson I'd take from this, and I'm saying this because I want to remember it later, is that the rendering substrate is not a library decision. It's an architecture decision. The moment your framework needs to answer cross-cutting questions about hit-testing, atlas eviction, draw order, and HiDPI all at once, you can either keep negotiating with someone else's library or you can write your own. Flutter eventually came to the same conclusion. So did I, just earlier. The work is bigger than it looks. The result is that everything downstream of the renderer stops feeling like it's fighting the renderer.

What's new in Vel: hot reload, an SDK, and a real editor

Sai Chandan Kadarla — Sat, 06 Jun 2026 20:10:03 +0000

When I posted Building Vel a month ago, the language and runtime worked end-to-end — but everything around them was painful. You had to clone the repo, wait 30–60 minutes for vcpkg to build Skia, restart the binary on every change, and write .vel files in a plain text editor with no help.

Here's what shipped to fix that. None of it changed what Vel is. All of it changed what using Vel feels like.

A Flutter-style SDK

The install path is now one line:

curl -fsSL https://raw.githubusercontent.com/chan27-2/vel/main/scripts/install-vel.sh | bash
echo 'eval "$(vel shell-init bash)"' >> ~/.zshrc
vel doctor

The script downloads a prebuilt SDK archive for your OS and arch — vel-sdk-<ver>-darwin-arm64.tar.gz, linux-x64.tar.gz, windows-x64.zip — drops it at ~/.vel/sdk, and adds vel + velc to your PATH. No Skia compile. No vcpkg bootstrap. First run to working compiler: seconds, not hours.

Windows users get the equivalent PowerShell line:

irm https://raw.githubusercontent.com/chan27-2/vel/main/scripts/install-vel.ps1 | iex

The model is Flutter's, deliberately:

Flutter	Vel
`~/flutter`	`~/.vel/sdk`
`stable` / `beta` channels	`vel channel stable\
{% raw %}`flutter upgrade`	`vel upgrade`
`flutter doctor`	`vel doctor`

The piece Vel doesn't ship: your final binary still links Skia/GLFW via vcpkg, same as Flutter's platform embedders. The SDK gets you the compiler and the framework — your CMake handles the application link.

Hot reload via dynamic plugins

The biggest architectural change since the introduction post. libvel is now a shared library, and the app shell can dlopen a plugin — your widget tree compiled into its own dylib.

The plugin ABI is one symbol:

extern "C" vel::Widget* vel_create_root();

The host watches the dylib's mtime every 50ms. When you save a .vel file, a watch loop runs cmake --build build --target showcase_plugin (typically 1–2s for a small edit). The dylib mtime ticks. The host destroys the current root, dlcloses the old handle, dlopens the new one, and calls vel_create_root() again. The window updates in place.

One script wires it all together:

./scripts/dev-hot.sh

That's the dev loop now: edit, save, see the UI change in under two seconds without restarting.

What it costs. Signal state is reset on reload. If you had a form half-filled, those values are gone after the dylib swap — the new root is a fresh tree. This is a deliberate tradeoff: serializing state across an ABI boundary is the kind of feature that ends up dictating every widget's API. For a UI dev loop, "edit structure → see new structure" is what matters; the state comes back when you fill the form once.

The other cost: RTLD_LOCAL matters. Plugins are loaded with dlopen(path, RTLD_NOW | RTLD_LOCAL) so symbol tables don't leak across reloads. Without it, the second load picks up stale vtables from the first plugin and crashes on the first virtual call. The teardown order also matters — destroy the old root before dlclose, because the destructors run vtables that live in the plugin's text segment.

A VS Code extension with real diagnostics

Vel has a VS Code extension now — syntax highlighting, completion, hover, live diagnostics.

The interesting part is where the data comes from. Two things were already true about velc:

velc --diagnostics-json file.vel emits structured parse + typecheck errors.
velc --docs-json emits the complete widget registry — every widget, every prop, every event, every example — as JSON.

The extension is mostly a thin TypeScript shim over those two outputs. The language server runs velc --diagnostics-json on save and surfaces the errors. Completion and hover read from widgets.json — the same file the docs site is built from. There is one source of truth for "what widgets and props exist," and the compiler owns it.

This is the part I'm proudest of. The compiler doing double duty as the registry source means the editor experience never drifts from the language. Add a widget; the editor knows about it on the next sync. Rename a prop; the diagnostics flag every old call site.

A live theme configurator

The framework now ships a ThemeConfig global — accent, radius scale, dark/light — that any widget can flip:

Btn "Rose"   variant=outline -> click => vel::useAccentRose()
Btn "Lg"     variant=outline -> click => vel::useRadiusLg()
Btn "Light"  variant=outline -> click => vel::useLightTheme()

There are 7 accents (Indigo, Blue, Violet, Rose, Emerald, Amber, Slate), 6 radius scales (None → Full), and dark/light. A single setter call rebuilds the Theme from the config and re-applies it across the tree. The whole UI re-tints in one frame.

The detail that took thought: this used to crash. The old path called root->onThemeChanged() synchronously from inside the click dispatch, which rebuilt the entire widget tree — freeing the button that was still executing its own onClick handler. Use-after-free, every time.

The fix is deferred rebuild: set a pendingThemeChange_ flag and apply the theme at the start of the next frame, after the current event dispatch has unwound. It's now the pattern for any widget action that mutates global state — locale switching will use it next.

EditableText: one widget, two surfaces

Input and Textarea shared ~95% of their code — UTF-8 cursor math, blink, key handling, focus sync, char input. They were drifting. Both have been refactored onto a shared EditableText base:

class EditableText : public Interactable {
public:
    std::string text;
    std::string placeholder;
    std::function<void(const std::string&)> onChange;
    std::function<void(const std::string&)> onSubmit;

    bool onMouseDown(Point, MouseButton) override;     // final
    bool onKey(int, int, bool) override;               // final
    bool onChar(unsigned int) override;                // final
    void tick(double now) override;                    // final

protected:
    virtual int  byteIndexAt(Point pos) const;         // override per layout
    virtual void onEnterPressed();                     // Input submits, Textarea inserts \n
};

Subclasses now only own their rendering and the click-to-cursor mapping. One place to fix backspace-at-position-zero. One place to keep the cursor on a UTF-8 boundary. Adding a PasswordInput or a syntax-highlighted code editor is much smaller now — the base class owns the hard parts.

CI on Linux, macOS, and Windows

Less glamorous, but it matters: GitHub Actions builds Vel on Ubuntu, macOS, and Windows on every push and PR. Each platform builds velc, builds libvel, runs CTest, and runs the showcase smoke test where a display exists.

Two things were painful to get right:

vcpkg caching. Earlier iterations cached only installed/, which left the cache unable to bootstrap on restore — the .git directory and scripts/ were missing. Now the entire vcpkg-root is cached, keyed on the manifest hash. CI cold start dropped from a full Skia build to a tar extract.
Headless runners. macOS CI has no display; Windows Server runners ship without a usable OpenGL driver, so glfwCreateWindow aborts the showcase. The vel run script now detects MINGW*/MSYS*/CYGWIN* and macOS CI and skips the GUI launch — compile + CTest still cover the toolchain.

Multi-platform CI is the kind of thing you don't notice until it breaks. It took three commits to get right, and I hope to never touch it again.

The showcase, reorganized

A small one but worth flagging: examples/showcase.vel used to be one long scrolling page exercising every primitive. It's now a multi-page demo with a sidebar:

Form Controls
Buttons & Cards
Data
Overlays
Theme

Build, then ./scripts/vel run ./build/showcase — that's the first thing you see. It's also the integration test that exercises every widget, every prop, and every event.

What's next

Per-widget damage rectangles. Frame-level damage tracking is great for idle apps; per-widget would let animations not repaint the whole screen.
vel.json package manifest, so third-party registries become installable instead of vendored.
A vel new template generator. The boilerplate to start a Vel project is small but not zero.
More registry primitives — Video, SVG, a devtools overlay, a syntax-highlighted code editor (which the EditableText refactor now makes practical).

If you tried Vel a month ago and bounced off the install, give it another go. curl -fsSL .../install-vel.sh | bash, run vel doctor, open the showcase. The first ten minutes look very different now.