Valdi – plattformübergreifendes UI-Framework mit nativer Performance

 (github.com/Snapchat)
9 Punkte von GN⁺ 2025-11-09 | 2 Kommentare | Auf WhatsApp teilen
  • Valdi von Snap ist ein plattformübergreifendes UI-Framework, das auf iOS, Android und macOS native Performance bietet, indem in deklarativem TypeScript geschriebene UIs direkt in die nativen Views der jeweiligen Plattform kompiliert werden
  • Es funktioniert ohne WebView oder JavaScript-Bridge und hält die Performance durch automatisches View-Recycling, eine optimierte Layout-Engine und viewport-basiertes Rendering hoch
  • Funktionen wie sofortiges Hot Reload, VSCode-Debugging und TSX-Syntax-Unterstützung beschleunigen die Entwicklung, zugleich wird auch die Integration in bestehende native Apps flexibel unterstützt
  • Mit typsicheren Bindings zwischen TypeScript und nativem Code, protobuf-Unterstützung sowie C++-, Swift- und Kotlin-Integration bietet es eine tiefgehende Struktur für die Native-Integration
  • Die Technologie wurde 8 Jahre lang in Snaps Produktions-Apps erprobt und ist eine skalierbare Basis für UI-Entwicklung mit fortgeschrittenen Funktionen wie umfangreichen Animationen, Gesten und Multithreading

Überblick über Valdi

  • Valdi ist ein plattformübergreifendes UI-Framework, das Snap seit 8 Jahren in Produktions-Apps einsetzt
    • Schreibt man eine UI in deklarativem TypeScript, wird sie direkt in native Views für iOS, Android und macOS kompiliert
    • Es bietet native Performance ohne WebView oder JavaScript-Bridge
  • Aktuell befindet sich das Framework in der Beta-Phase; sobald Tools und Dokumentation im Open-Source-Umfeld stabilisiert sind, ist ein offizielles Release geplant

Wichtige Merkmale und Beispiele

  • Das Beispiel für eine Basiskomponente zeigt, wie sich im HelloWorld-Klasse mit und eine einfache UI aufbauen lässt
  • Es verwendet eine TypeScript-basierte deklarative Komponentenstruktur und kann mit demselben Code auf allen Plattformen ausgeführt werden
  • Offizielle Dokumentation, Installationsanleitung, API-Referenz und Codelab stehen als Entwicklungsmaterial bereit

Performance-Optimierung

  • Um native Performance zu erreichen, setzt Valdi auf folgende Architektur
    • Automatisches View-Recycling: Ein globales View-Pooling-System nutzt Views über Bildschirme hinweg wieder und minimiert Verzögerungen beim Inflating
    • Unabhängiges Komponenten-Rendering: Es werden nur einzelne Komponenten aktualisiert, ohne das Rendering des Parents zu beeinflussen
    • C++-basierte Layout-Engine: Läuft mit minimalem Overhead auf dem Main Thread
    • Viewport-aware Rendering: Es werden nur sichtbare Views inflated, was die Performance bei Infinite Scroll verbessert
  • Dazu gibt es die Performance Optimization Guide als begleitende Dokumentation

Developer Experience

  • Die Funktion Hot Reload übernimmt Code-Änderungen sofort
  • VSCode-Debugging-Unterstützung: Breakpoints setzen, Variablen prüfen, Performance-Profiling durchführen und Heap Dumps erfassen
  • TSX-Syntax und Typsicherheit sorgen für eine vertraute Entwicklungsumgebung

Flexible Integrationsstruktur

  • Valdi kann in bestehende native Apps eingebettet werden (Embed Valdi in native)
  • Native Views können innerhalb von Valdi verwendet werden (Embed native in Valdi)
  • Über Polyglot-Module ist eine typsichere Anbindung an C++-, Swift-, Kotlin- und Objective-C-Code möglich
  • Mit einer Full-stack-Architektur lassen sich vollständige Funktionen unter Nutzung von Worker-Threads im Hintergrund umsetzen

Native Integration

  • Automatische Codegenerierung wandelt TypeScript-Interfaces in Bindings für Kotlin, Objective-C und Swift um
  • Über Polyglot-Module ist direkter Zugriff auf Plattform-APIs und native Drittanbieter-Bibliotheken möglich
  • Bidirektionale Kommunikation erlaubt den sicheren Austausch komplexer Datenstrukturen und Callbacks
  • protobuf-Unterstützung ermöglicht effiziente Datenserialisierung

Bewährte Stabilität und Funktionen

  • Zentrale Technologie hinter wichtigen Produktionsfunktionen von Snap
  • Unterstützung für fortgeschrittene Animationen, Echtzeit-Rendering und komplexe Gestensysteme
  • Enthält zahlreiche Funktionen wie Flexbox-Layout, Multithread-Worker, native Animationen, fortgeschrittene Gestenerkennung, integriertes Test-Framework und Bazel-integrierte Builds

Support und Lizenz

  • Support über die Discord-Community
  • Unter der MIT-Lizenz veröffentlicht und frei nutzbar sowie offen für Beiträge

Verwandte Beiträge

2 Kommentare

 
GN⁺ 2025-11-09
Hacker-News-Kommentare

  • Unser Unternehmen verwendet React Native, aber wir wünschen uns dringend das Ende des App-Store-Zwangs und der sprachspezifischen Unterschiede zwischen den Plattformen.
    Nächstes Jahr überlegen wir, einfach auf eine Website-Basis zu setzen, die mobile App nur noch in eine WebView zu verpacken und Funktionen wie Benachrichtigungen, GPS und HealthKit nur noch mit nativem Code umzusetzen.
    In letzter Zeit denke ich wegen AI sogar, dass es vielleicht besser wäre, die UI für jede Plattform getrennt zu bauen.

    • Ich habe das auch so gemacht und es nicht bereut. Das ist die klassische „WebView-App“, aber man kann den Nutzern je nach Plattform eine ziemlich gute Erfahrung bieten.
      Der Schlüssel ist, die UI-Komponenten nicht zu ungewöhnlich zu gestalten und nur Dinge wie Button-Stile oder den Back-Stack je Plattform leicht anzupassen.
      Außerdem habe ich mit Service Worker Offline-Funktionen ergänzt und beim App-Start Netzwerk-Diagnose-Tools ausgeführt, damit sich Probleme schnell erkennen lassen.
      Allerdings war meine App für B2B gedacht, deshalb war so ein Setup möglich.
    • Wenn man WebView am Ende trotzdem in einen nativen Container packen muss, hat man damit bereits einen Fuß in die iOS-Code-Signing-Hölle gesetzt.
      Ich sehe das Web eigentlich als Weg, App Stores und Code Signing zu umgehen.
      Die meisten Funktionen gehen auch im Web, und nur HealthKit könnte man über eine separate Begleit-App lösen.
      Es kann deutlich effizienter sein, das Marketingbudget in QR-Codes oder Links zu stecken als in den Wettbewerb im App Store.
    • Ich probiere so etwas auch alle zehn Jahre wieder aus. Anfangs begeistert mich die schnelle Entwicklung, aber später zahlt man doch den Preis bei der Integration neuer OS-Funktionen oder bei der Unterstützung von Gesten.
      Besonders auf iOS erkennt man in dem Moment sofort, dass es eine WebView ist, wenn „Zurückswipen“ nicht funktioniert.
    • AI ändert Apples Richtlinien nicht.
      Ich schreibe die Business-UI einmal und lasse sie mit einem LLM zwischen React Native und React umwandeln.
      Aber Apple hält weiterhin an der 4.2-Regel zur Mindestfunktionalität fest, nach der Apps abgelehnt werden, die „bloß eine Website verpacken“.
    • Komplexe, langlebige Apps dreimal separat pro Plattform zu schreiben, ist fast ein Albtraum.
      Man muss Features und Tests über drei Plattformen hinweg synchron halten, und die Entwickler müssen mehrere Stacks beherrschen.
      Die meisten Nutzer merken den Unterschied zwischen einer guten WebView-Umsetzung und einer nativen App kaum, aber die Kosten dafür sind enorm.

  • Valdi wirkt konzeptionell ähnlich wie React Native.
    Inzwischen gibt es mit React Native, Lynx.js (ByteDance/TikTok) und Valdi gleich drei React-basierte Cross-Platform-Frameworks.
    Konkurrenz ist gut, aber ich bezweifle, dass sich so schnell ein Ökosystem in RN-Größe aufbauen lässt.
    Bei RN gab es dieses Jahr viele Fortschritte, etwa Verbesserungen an der Hermes-Engine, einen Generator für Native Bindings, multithreaded Animationen und Tailwind-Support.
    Lynx.js könnte im Vorteil sein, weil es auch Frameworks außerhalb von React unterstützen will.

    • Nach etwas Recherche sieht es so aus, als unterstütze Valdi VSCode-Debugging vollständig.
      Radon IDE für RN ist kostenpflichtig, Valdi dagegen ist Open Source.
      Interessant ist auch, dass Valdi die Hermes-Engine von RN verwendet.
      In der zugehörigen Dokumentation frage ich mich, wie AOT/JIT umgesetzt ist.

  • Ich habe früher bei Snap zusammen mit anderen eine frühe Version dieses Projekts (Screenshop!) debuggt.
    Simon war ein hervorragender Engineer, und ich freue mich wirklich, dass dieses Projekt veröffentlicht wurde.
    Glückwunsch an das Snap-Team.

    • Es überrascht mich, dass eine so einfache App wie Snap in ein Cross-Platform-UI-Framework investiert hat.
      Gerade weil es eine App ist, bei der native Integration für Kamera, AR, Benachrichtigungen und Screenshot-Erkennung wichtig ist, ist das noch erstaunlicher.
    • Schon damals war es ein wirklich großartiges Projekt, und ich erinnere mich, dass Open Source das Ziel war.
      Es freut mich, dass das nun Wirklichkeit geworden ist.
    • Ich habe auch mit Simon zusammengearbeitet und versucht, es ins Web zu portieren, aber das ist gescheitert.
      Er ist wirklich extrem klug, und Glückwunsch an das ganze Team.
    • Ich frage mich, ob man dieses Framework heute in einem realen Projekt einsetzen würde.
    • Der Name „Composer“ kommt mir in den Sinn.

  • Ein von Snapchat gebautes UI-Framework mit einer Discord-Community spricht mich persönlich überhaupt nicht an.

    • Viele Projekte verlagern ihre Community heute auf Discord.
      Es ist nicht perfekt, aber es könnte auch bedeuten, sich selbst von der künftigen Entwicklung abzukoppeln, wenn man da nicht mitgeht.
    • Ich nutze Discord auch oft, finde es aber für eine Arbeits-Community immer noch unbequem.

  • In der Dokumentation steht: „Wenn C++, Objective-C- und Kotlin-Objekte in TypeScript exponiert werden, sind sie Native Reference, in der Gegenrichtung JS Value Reference“,
    und dass Swift oder SwiftUI gar nicht erwähnt werden, wirkt etwas besorgniserregend.

  • Ehrlich gesagt fällt es mir schwer, einem von Snap entwickelten Framework zu vertrauen.
    Der Grund ist die frühere Qualität der Android-App, die viel zu schlecht war.

    • Ich war schockiert, als ich erfahren habe, dass früher nicht wirklich Fotos aufgenommen wurden, sondern Screenshots der Kameraansicht.

  • Valdi wird als „UI-Framework, das einmal in TypeScript geschrieben wird und auf iOS, Android und macOS mit nativer Performance läuft“ beschrieben.
    Hervorgehoben wird, dass es weder WebView noch JS-Bridge gibt.

    • „Wir haben beides. Country and western!“, scherzt jemand dazu.

  • Ich finde, man sollte die UI einfach zweimal in den nativen Sprachen der jeweiligen Plattformen schreiben und die gemeinsame Logik über C-artige FFI teilen.
    Wie schwer kann das schon sein?

    • Wir gehen auch in diese Richtung. Derzeit unterstützen wir nur iOS, wollen aber nach dem Einholen von Nutzerfeedback auf Android erweitern.
      Die meisten im Team nutzen zwar Android, aber unsere Kunden sind überwiegend auf iOS, deshalb haben wir das so priorisiert.
      Ich habe schon einmal eine RN-App gebaut, hoffe aber immer noch auf eine wirklich magische Cross-Platform-Lösung.
    • Ich stimme auch zu. Entscheidend ist die Architektur, also Business-Logik von der UI zu trennen.
      Dann werden Web, Mobile, Desktop und CLI nur dünne Schichten, die den Core aufrufen.
      Eine perfekt konsistente UX ist schwierig, aber langfristig kann man so die Abhängigkeit von 3rd-party-Frameworks reduzieren.

  • Wer sich für den State-Management-Ansatz von Valdi interessiert: Er übernimmt direkt den Stil von React-Klassenkomponenten.
    Im Beispiel der offiziellen Dokumentation sieht man eine Struktur, in der von StatefulComponent geerbt und onCreate, onDestroy sowie onRender implementiert werden.

    • Ich vermisse React-Klassenkomponenten auch.
      Der heutige Stil mit Dutzenden von useFunction-Aufrufen ist fehleranfällig und kompliziert.

  • Leider werden Linux-, Windows- und HTML-Ziele nicht unterstützt.
 
clastneo 2025-11-10

In RN lässt sich die Geschäftslogik der meisten Apps allein mit JS ausreichend schnell ausführen.
Beim Feinschliff scheint mir das Problem zu sein, dass es oft Unterschiede im Verhalten je nach Plattform gibt und dadurch alles frustrierend schwierig wird.