Valdi compiles TSX to native views, and its beta tag is about the tooling

The beta label is about the developer experience, not the renderer

Valdi carries a Beta Status note, and it is worth reading closely before drawing conclusions from it. The note says Valdi has been widely used in Snap's production apps for the last 8 years, and that the project calls it a beta because the tools and documentation need more battle testing in the open source world. Valdi will exit beta when the team is happy with the developer experience.

Read plainly, that separates two things that are usually fused. The rendering approach is field tested, and the README's Proven at Scale list points to advanced animations, real time rendering and complex gesture systems as evidence. The onboarding is not. So if you are evaluating whether the framework can render a screen correctly, the beta tag is close to irrelevant. If you are evaluating whether a new engineer can get a build running on a clean machine, the tag is the most honest line in the README.

The root package.json declares no name and installs only a linter

Open package.json at the repository root and it contains three devDependencies and nothing else: @typescript-eslint/eslint-plugin ^8.30.1, @typescript-eslint/parser ^8.30.1 and eslint ^9.24.0. There is no name field, no version, no dependencies block and no scripts block. Running npm install there installs an ESLint toolchain and nothing resembling the framework.

That is not an oversight, it is the shape of the project. The build system is Bazel, and the root is full of its files: BUILD.bazel, MODULE.bazel, .bazelrc, .bazelversion, and the bzl/ and bzlmod/ directories. The artifact you actually install is a separate global CLI, which the Quick Start block names as @snap/valdi. Expect a Bazel repository with an npm lint overlay, not an npm library, and do not read the root manifest as a description of what Valdi depends on.

Xcode on macOS is the only prerequisite the setup names

The prerequisites line names Node.js 18 or later (22 recommended) and, on macOS, Xcode 26.5 or 27, and says valdi dev_setup installs the rest. The setup around it is a short block of commands:

# Install Valdi CLI
npm install -g @snap/valdi

# One-command setup (installs all dependencies)
valdi dev_setup

# Create your first project
mkdir my_project && cd my_project
valdi bootstrap
valdi install ios  # or android

One prerequisite is genuinely useful information, and it also draws a boundary. The iOS target has a Mac requirement, so valdi install ios is a dead end anywhere else. For the full host requirements, the README points to the prerequisites section of the Installation Guide. Note also that the automatic part begins after the CLI is global, and editor setup is separate again: the README says no Valdi-specific extension is needed and points to a VSCode/Cursor guide for using the workspace TypeScript version.

Three beta tags in four months, and still no 1.0

The recent release history is entirely pre-1.0: beta-0.1.1 on 2026-07-01, beta-0.2.0 on 2026-09-22 and beta-0.2.1 on 2026-10-19. The last push is dated 2026-10-31, so work is landing even though the version line has not crossed 0.2.

What that means practically is that no release has reached 1.0; the VERSIONING.md file at the root is where to check what the project promises between beta tags. The project states the terms itself, saying Valdi will exit beta when the developer experience satisfies the team, which is a criterion about tooling rather than a statement about the API. For a framework whose selling point is that your UI is real code, a minor bump that moves an attribute or a lifecycle hook is a rewrite risk across your component library, not a patch. Pin an exact tag, read the ROADMAP.md the project publishes, and expect to allocate time for framework upgrades that a stable 1.0 would have made rare.

The layout engine is C++ and it runs on the main thread

The repository's primary language is C++, even though everything you write is TSX, and the reason appears in the performance section as an optimized layout engine that runs on the main thread with minimal marshalling overhead. The root directory explains the shape, with compiler/, snap_drawing/, tsn/ and valdi_protobuf/ sitting alongside the TypeScript entry points.

Main thread is the word to hold on to. Valdi's stated wins come from elsewhere: automatic view recycling described as a global view pooling system that reuses native views across all screens to cut inflation latency, viewport aware rendering that inflates only visible views so infinite scrolling works by default, and independent component re-renders that do not trigger parents. Those reduce the amount of work, but the layout pass itself is still synchronous main thread work. Worker threads exist, but the project scopes them to background processing rather than to moving layout off the critical path, so a pathological component can still cost you a frame.

The license identifier recorded for the repository is NOASSERTION

A LICENSE file sits at the repository root, and the license recorded for this repository is MIT.

The README's license badge links to that LICENSE file, and the root also carries a THIRD_PARTY_NOTICES.md for bundled third-party code.

valdi_gpt renders a view tree that arrives at runtime

The examples directory lists six runnable apps, and one of them is worth reading before the rest. apps/valdi_gpt is described as AI driven dynamic UI, with Valdi rendering UI described at runtime, which is a different exercise from every other example. helloworld gets a component on screen, navigation_example covers screen navigation, managed_context_example covers sharing state, cli_example builds a CLI application and benchmark holds performance benchmarks.

The distinction matters for anyone planning to do the same thing. In the ordinary examples the view tree is in your TypeScript and the compiler can check it. When the structure arrives as data at runtime, the compiler has nothing to check, and malformed or hostile input becomes a rendering problem rather than a type error. The example ships as a demonstration of what the framework can express, so treat it as a spike. If runtime described UI is your actual goal, budget for validating the input before it reaches the view layer yourself.

Editorial conclusion

Valdi suits a team that already builds native iOS or Android and wants to share one TypeScript view layer instead of writing each platform twice, and that can live with a pre-1.0 release line. It is a poor fit for a team that needs a documented setup path today or a stable compatibility promise, because the project itself blames documentation and tooling for the beta status. Before you commit, read the MIT LICENSE and THIRD_PARTY_NOTICES.md yourself, confirm the iOS path works from a Mac, pin an exact beta tag, and budget for reading the docs rather than assuming the eight years of Snap usage transfers to you.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. Snapchat/Valdi on GitHub