Valdi – un framework UI cross-platform offrant des performances natives

(github.com/Snapchat)

9 points par GN⁺ 2025-11-09 | 2 commentaires | Partager sur WhatsApp

Valdi, créé par Snap (Snapchat), est un framework UI cross-platform qui offre des performances natives sur iOS, Android et macOS, en compilant directement l’interface écrite en TypeScript déclaratif vers les vues natives de chaque plateforme
Il fonctionne sans WebView ni pont JavaScript, et maintient de hautes performances grâce à la réutilisation automatique des vues, à un moteur de layout optimisé et au rendu basé sur le viewport, entre autres
Il accélère le développement avec le hot reload instantané, le débogage VSCode et la prise en charge de la syntaxe TSX, tout en prenant en charge avec souplesse l’intégration aux applications natives existantes
Il propose une intégration native approfondie grâce à des liaisons sûres en type entre TypeScript et le code natif, à la prise en charge de protobuf et à l’interopérabilité avec C++, Swift et Kotlin
Il s’agit d’une technologie éprouvée pendant 8 ans dans les applications de production de Snap, constituant une base de développement UI extensible incluant des fonctionnalités avancées comme les animations à grande échelle, les gestes et le traitement multithread

Présentation de Valdi

Valdi est un framework UI cross-platform utilisé par Snap dans ses applications de production depuis 8 ans
- On écrit l’UI en TypeScript déclaratif, puis elle est compilée directement en vues natives pour iOS, Android et macOS
- Il offre des performances natives sans WebView ni pont JavaScript
Le projet est actuellement en bêta et passera en version stable une fois la stabilisation des outils et de la documentation dans l’environnement open source terminée

Principales caractéristiques et exemples

L’exemple de composant de base montre une UI simple construite dans la classe HelloWorld à l’aide de et
Il adopte une architecture de composants déclaratifs basée sur TypeScript, exécutable avec le même code sur chaque plateforme
Il fournit des ressources de développement comme la documentation officielle, le guide d’installation, la référence API et des Codelabs

Optimisation des performances

Pour garantir des performances natives, il adopte la structure suivante
- Réutilisation automatique des vues : un système global de pooling réutilise les vues d’un écran à l’autre et réduit au minimum la latence d’inflation
- Rendu indépendant des composants : seuls les composants individuels sont mis à jour, sans impact sur le rendu parent
- Moteur de layout basé sur C++ : fonctionne sur le thread principal avec un surcoût minimal
- Rendu tenant compte du viewport : n’inflate que les vues visibles à l’écran pour améliorer les performances du scroll infini
Une Performance Optimization Guide est également proposée dans la documentation

Expérience développeur

La fonctionnalité hot reload applique immédiatement les modifications de code
Prise en charge du débogage VSCode : définition de points d’arrêt, inspection des variables, profiling des performances et capture de heap dumps
La syntaxe TSX et la sûreté de typage offrent un environnement de développement familier

Structure d’intégration flexible

Possibilité d’insérer Valdi dans une application native existante (Embed Valdi in native)
Possibilité d’utiliser des vues natives au sein de Valdi (Embed native in Valdi)
Les modules Polyglot permettent une interopérabilité typée et sûre avec du code C++, Swift, Kotlin et Objective-C
Une architecture full-stack permet d’implémenter l’ensemble des fonctionnalités en exploitant des threads workers en arrière-plan

Intégration native

La génération automatique de code convertit des interfaces TypeScript en bindings Kotlin, Objective-C et Swift
Les modules Polyglot donnent un accès direct aux API de plateforme et aux bibliothèques natives tierces
Une communication bidirectionnelle permet d’échanger en toute sécurité des structures de données complexes et des callbacks
La prise en charge de protobuf permet une sérialisation efficace des données

Stabilité et fonctionnalités éprouvées

Technologie centrale qui alimente les principales fonctionnalités de production de Snap
Prise en charge des animations avancées, du rendu en temps réel et de systèmes de gestes complexes
Inclut de nombreuses fonctionnalités comme le layout Flexbox, les workers multithread, les animations natives, la reconnaissance avancée des gestes, un framework de test intégré et une build intégrée avec Bazel

Support et licence

Support fourni via la communauté Discord
Distribué sous licence MIT, permettant une utilisation et des contributions libres

2 commentaires

GN⁺ 2025-11-09

Avis sur Hacker News

Dans notre boîte, on utilise React Native, et on espère vraiment en finir avec les différences entre l’App Store et les langages propres à chaque plateforme
L’an prochain, on envisage peut-être de repartir simplement sur un site web, avec une app mobile emballée dans un WebView, et de ne gérer en code natif que les fonctions comme les notifications, le GPS ou HealthKit
Ces temps-ci, avec l’IA, je me dis même qu’il vaut peut-être mieux faire des UI séparées pour chaque plateforme
- C’est ce que j’ai fait aussi, et je ne l’ai pas regretté. C’est ce qu’on appelle communément une « app WebView », mais on peut offrir une expérience tout à fait correcte selon la plateforme
  L’essentiel est de ne pas rendre les composants UI trop atypiques, et d’ajuster seulement légèrement, selon la plateforme, des éléments comme le style des boutons ou la pile de navigation
  J’ai aussi ajouté des fonctions hors ligne via Service Worker, et lancé des outils de diagnostic réseau au démarrage de l’app pour identifier rapidement les problèmes
  Cela dit, mon app était destinée au B2B, donc cette configuration était possible
- Mais si, au final, il faut quand même emballer un WebView dans un conteneur natif, alors on a déjà mis le pied dans l’enfer de la signature de code iOS
  À mes yeux, le web est justement la voie qui permet de contourner l’App Store et la signature de code
  La plupart des fonctions sont possibles sur le web, et pour HealthKit il suffit d’une app compagnon séparée
  Il peut être bien plus efficace d’utiliser son budget marketing pour promouvoir des QR codes ou des liens plutôt que de se battre dans l’App Store
- Moi aussi, je fais ce genre de tentative tous les dix ans. Au début, on tombe amoureux de la vitesse de développement, mais plus tard on finit par payer le prix sur l’intégration des nouvelles fonctions de l’OS ou la gestion des gestes
  Surtout sur iOS, dès que le balayage « retour » ne fonctionne pas, on sait immédiatement qu’on est dans un WebView
- L’IA ne changera pas les guidelines d’Apple
  Moi, j’écris l’UI métier une seule fois, puis j’utilise un LLM pour faire la conversion entre React Native et React
  Mais Apple maintient toujours la règle 4.2 sur la fonctionnalité minimale, selon laquelle les apps qui ne font qu’« emballer un site web » sont refusées
- Écrire trois fois, par plateforme, une app complexe et pensée pour le long terme tient quasiment du cauchemar
  Il faut synchroniser les fonctionnalités et les tests sur trois plateformes, et les développeurs doivent maîtriser plusieurs stacks
  La plupart des utilisateurs remarquent à peine la différence entre une bonne implémentation WebView et une app native, alors que le coût est énorme
Valdi semble conceptuellement assez proche de React Native
On a désormais trois frameworks cross-platform basés sur React : React Native, Lynx.js (ByteDance/TikTok) et Valdi
La concurrence est une bonne chose, mais je doute qu’ils puissent rapidement bâtir un écosystème aussi vaste que celui de RN
Cette année, RN a beaucoup progressé avec notamment des améliorations du moteur Hermes, un générateur de bindings natifs, des animations multithread et la prise en charge de Tailwind
Lynx.js pourrait avoir un avantage en cherchant aussi à prendre en charge d’autres frameworks que React
- En regardant un peu, j’ai vu que Valdi prend complètement en charge le debugging dans VSCode
  Le Radon IDE de RN est payant, alors que Valdi est open source
  Il est aussi intéressant de voir que Valdi utilise le moteur Hermes de RN
  En lisant la documentation associée, je me demande comment AOT/JIT est implémenté
J’avais aidé à déboguer une première version de ce projet (Screenshop!) chez Snap il y a longtemps
Simon était un excellent ingénieur, et je suis vraiment heureux de voir ce projet rendu public
Félicitations à l’équipe de Snap
- Je suis surpris qu’une app aussi simple que Snap ait investi dans un framework UI cross-platform
  C’est d’autant plus étonnant pour une app où les intégrations natives comme la caméra, l’AR, les notifications ou la détection de capture d’écran sont importantes
- C’était déjà un projet vraiment formidable à l’époque, et je me souviens que l’open source était l’objectif
  Je suis heureux de voir cela devenir réalité
- J’ai aussi travaillé avec Simon, en essayant un portage web, mais ça a échoué
  C’est quelqu’un de vraiment brillant, et félicitations à toute l’équipe
- Je me demande si, aujourd’hui, j’utiliserais réellement ce framework dans un projet concret
- Le nom « Composer » me revient en tête
Un framework UI créé par Snapchat avec une communauté Discord, personnellement ça ne m’attire pas du tout
- Beaucoup de projets déplacent leur communauté vers Discord en ce moment
  Ce n’est pas parfait, mais on risque peut-être de se mettre soi-même à l’écart de l’évolution future
- J’utilise souvent Discord moi aussi, mais je le trouve toujours peu pratique comme communauté de travail
La documentation dit : « si on expose des objets C++, Objective-C et Kotlin à TypeScript, on obtient des Native Reference, et dans l’autre sens des JS Value Reference »
L’absence de toute mention de Swift ou SwiftUI m’inquiète un peu
Honnêtement, j’ai du mal à faire confiance à un framework créé par Snap
À cause de la très mauvaise qualité de leur app Android à l’époque
- J’ai été choqué d’apprendre qu’à l’époque, au lieu de prendre une photo, ils prenaient en fait une capture d’écran de la vue caméra
Valdi est présenté comme « un framework UI écrit une seule fois en TypeScript, puis exécuté avec des performances natives sur iOS, Android et macOS »
Ils insistent sur l’absence de webview et de pont JS
- « Nous, on a les deux. Country and western! », plaisante quelqu’un
Je pense qu’il suffit simplement d’écrire l’UI deux fois dans les langages natifs de chaque plateforme, puis de partager la logique commune via une FFI de la famille C
Franchement, à quel point cela peut-il être difficile ?
- C’est aussi la direction qu’on prend. Pour l’instant, on ne prend en charge qu’iOS, mais on prévoit d’étendre à Android après avoir recueilli les retours utilisateurs
  La majorité de l’équipe utilise Android, mais nos clients sont surtout sur iOS, donc on a fixé cette priorité
  J’ai déjà créé une app RN, mais j’attends toujours une vraie solution cross-platform presque magique
- Je suis d’accord aussi. La clé, c’est une architecture qui sépare la logique métier de l’UI
  Ensuite, les différentes interfaces comme le web, le mobile, le desktop ou la CLI ne sont plus que de fines couches qui appellent le cœur
  Il sera difficile d’obtenir une UX parfaitement cohérente, mais à long terme cela peut réduire la dépendance à des frameworks tiers
Si vous êtes curieux de connaître la gestion d’état de Valdi, elle reprend telle quelle le style des composants de classe de React
Dans cet exemple de la documentation officielle, la structure consiste à hériter de StatefulComponent et à implémenter onCreate, onDestroy et onRender
- Les composants de classe React me manquent aussi
  La façon actuelle d’utiliser des dizaines de useFunction est source d’erreurs et trop complexe
Malheureusement, les cibles Linux, Windows et HTML ne sont pas prises en charge

clastneo 2025-11-10

Dans RN, pour la plupart des applications, la logique métier tourne suffisamment vite avec du JS seul.
Mais à mesure qu’on affine le produit, le vrai problème me semble être que, comme le comportement diffère souvent selon les plateformes, cela devient extrêmement difficile à gérer.