During this week’s live session, Łukasz Chludziński, Kewin Wereszczyński, Hubert Sosiński, and Matt Hargett took a close look at Valdi: the newly released UI framework open-sourced by Snapchat. They approached it like any developer encountering it for the first time would,  exploring documentation, bootstrapping a project, and examining how Valdi differs from React-style workflows.

What Valdi is and why it exists

Valdi’s stated purpose is a cross-platform UI framework designed to bridge the tension between developer velocity and runtime performance. It has powered large parts of Snapchat’s production apps for eight years, which explains why it ships with a mature set of internal patterns. The framework was originally built to support Snap’s multi-platform ambitions while maintaining native-level performance characteristics.

Should Valdi be considered a framework or a development environment? Well, the boundary between the two is blurred when tools, build steps, and rendering pipelines are tightly integrated.

Architecture differences: render functions, not JSX returns

One of the central conversations focused on Valdi’s rendering model, which diverges from the familiar React component structure. The critical distinction is that Valdi uses render functions that return void rather than actual element objects. This lets Valdi evaluate render functions at the exact location where UI should be emitted, enabling fine-grained control over render paths and making incremental rendering cheaper by design. This model avoids some of the overhead inherent in React’s diffing process, shifting performance considerations toward compile-time and AOT strategies.

Working with the tooling and docs

Much of the stream focused on understanding how to get a Valdi project running. The hosts experimented with installing the CLI, navigating documentation, and filing through confusing or incomplete setup instructions. Several clues suggested that parts of the documentation originated as internal onboarding materials cleaned up for external release.

They also tested bootstrapping a new project using valdi bootstrap, stepping through prompts that generated an iOS, Android, and macOS application scaffold. Moments like these revealed both the strengths and growing pains of a framework that has only just been made public.

Demos: bootstrapping and hot reload

After generating a project, Łukasz explored the initial file structure, ran the application, and attempted to inspect components directly in the repo. Although some pieces were hard to locate, the team eventually reached a working setup and moved on to test Valdi’s hot reload.

A small change inside a module triggered a near-instant update in the running app once the file was saved. The quick turnaround suggested a different mechanism than the typical JavaScript-driven HMR loop and led to a discussion about how Valdi’s architecture might support this level of responsiveness.

Bigger picture: where Valdi fits

What are Valdi’s ambitions and long-term direction? Since Valdi compiles to native, some of the code may never run as JavaScript or Hermes, which positions it differently from frameworks that lean heavily on JS runtimes. The hosts also wondered how Valdi might scale to other Snap platforms, such as Spectacles, and what future evolution might look like based on internal feedback cycles at Snap.

Closing thoughts

Exploring Valdi live gives a practical sense of how the framework behaves beyond marketing claims. The setup experience, the rendering model, and the near-instant file-save updates showed that Valdi combines familiar ideas with a different execution path than React-style systems.

It’s early days, and several pieces still feel internal, but the underlying approach is clear enough to spark real curiosity. The session ends with a shared sense that Valdi is worth watching: not as a React Native replacement, but as another attempt to balance velocity and native performance with a typed, modern toolchain.

‍