La forme n'est pas si loin : une description déclarative, reconstruite quand l'état change, mise en page par un modèle de boîtes. Ce qui disparaît, c'est tout ce qu'il y a en dessous — pas de moteur de navigateur, pas de processus de rendu, pas d'empaqueteur, et un binaire qui se compte en centaines de kilooctets plutôt qu'en centaines de mégaoctets.
| Electron | keal-view |
|---|---|
<span>Hi</span> | label("Salut") |
<button onclick=…> | button("Go", { -> … }) |
display: flex; flex-direction: column | column([…]) |
flex: 1 | .grows() |
<canvas> + 2D context | custom({ p -> p.canvas… }) |
a CSS variable theme | useTheme(darkTheme()) |
useState / a store | state(0) et .set(…) |
Le style est posé sur le nœud, par modificateurs chaînés, ou vient de l'unique thème en vigueur. Rien n'hérite d'un ancêtre par son nom et rien n'est écrasé par un sélecteur plus spécifique ailleurs dans le programme. Que ce soit une perte dépend entièrement de la taille qu'avait prise votre feuille de style.
Il n'y a pas de processus principal qui parle à un processus de rendu par IPC, ni de valeurs à sérialiser pour traverser. L'interface et le travail qu'elle fait sont le même programme, et un gestionnaire est un appel ordinaire.
Pas de DOM, pas de npm, pas d'outils de développement, pas d'arbre d'accessibilité, pas de mise en forme des écritures complexes, pas encore d'images. Le poids d'Electron achète énormément et il vaut mieux être honnête sur la quantité. Ce que vous obtenez à la place, c'est un programme que vous pouvez lire en entier, et une fenêtre qui ne coûte rien quand personne n'y touche.