Présentation du projet
ElementaryUI est une bibliothèque open source qui propose d’écrire des interfaces utilisateur en Swift, puis de les faire tourner directement dans le navigateur. Le principe repose sur la compilation du code Swift en WebAssembly (Wasm), format binaire supporté par tous les navigateurs modernes. En combinant la syntaxe déclarative de SwiftUI – @View, @State, etc. – avec le runtime Wasm, le projet permet d’obtenir une application web sans recourir à JavaScript. L’objectif affiché est de fournir aux développeurs Swift un moyen de réutiliser leurs compétences pour créer des expériences web natives, sans passer par un transpileur ou un framework JavaScript.
Architecture et compilation
Le flux de construction s’appuie sur le compilateur officiel swiftc, configuré pour la cible wasm32-unknown-wasi. Le code source est d’abord transformé en bitcode LLVM, puis en module Wasm. Un runtime minimal, fourni par ElementaryUI, charge le module et initialise un environnement d’exécution compatible avec les API du WebAssembly System Interface (WASI). Le runtime expose un pont vers le DOM : chaque appel à p { … } ou button { … } crée un nœud HTML, tandis que les modificateurs comme .onClick enregistrent des gestionnaires d’événements JavaScript qui invoquent les closures Swift compilées. Les propriétés décorées par @State sont gérées par un système de diffing interne qui détecte les changements de valeur et déclenche une mise à jour partielle du DOM, reproduisant ainsi le modèle de rendu de SwiftUI.
@View
struct LoveCounter {
@State var count = 1
var body: some View {
p { String(repeating: "❤️", count: count) }
if count < 10 {
button { "More Love" }
.onClick { count += 1 }
} else {
p { "Enough love for you!" }
button { "Less Love" }
.onClick { count = 1 }
}
}
}
Analyse des performances et limites
WebAssembly offre un taux d’exécution proche du natif, ce qui rend les calculs intensifs plus rapides que les équivalents JavaScript. Cependant, le chargement initial d’un module Swift compilé reste volumineux : le binaire inclut le runtime Swift, les métadonnées de type et les bibliothèques standard nécessaires à la réflexion. Cette taille impacte le temps de téléchargement et la latence de démarrage, surtout sur des connexions mobiles. Le pont DOM introduit une surcharge supplémentaire : chaque mise à jour d’état déclenche une série d’appels JavaScript‑Wasm, ce qui peut réduire le débit d’images dans des interfaces très dynamiques. De plus, le modèle de sécurité du navigateur empêche l’accès direct aux API système iOS/macOS (CoreGraphics, AVFoundation, etc.), limitant l’utilisation d’ElementaryUI aux fonctionnalités purement web. Le débogage reste également plus complexe : les outils de profilage WebAssembly sont moins matures que ceux dédiés à JavaScript, et les traces de pile Swift sont souvent obfusquées après optimisation. En dépit de ces contraintes, le projet montre qu’une approche déclarative Swift peut être viable pour des applications web de taille moyenne, où la cohérence du code Swift et la performance Wasm compensent le coût d’initialisation.