Blitz : moteur de rendu web léger, modulaire et extensible

 (github.com/DioxusLabs)
2 points par GN⁺ 2024-08-13 | 1 commentaires | Partager sur WhatsApp
  • Blitz est un moteur de rendu modulaire axé sur le rendu HTML/CSS, conçu pour ne pas fournir par défaut toutes les fonctionnalités d’un navigateur, mais rendre les fonctionnalités supplémentaires optionnelles lorsque nécessaire
  • Le projet est actuellement en pré-alpha : le moteur de rendu est déjà assez fonctionnel, mais il comporte encore beaucoup de bugs et de fonctionnalités manquantes, et son usage pour développer des applications n’est pas encore recommandé
  • Les objectifs de prise en charge couvrent la mise en page HTML moderne, le CSS avancé, les contrôles de formulaires HTML, l’accessibilité basée sur AccessKit et l’extensibilité via des widgets personnalisés ; des fonctionnalités comme WebRTC, WebSockets, Bluetooth ou localStorage ne sont pas fournies
  • L’architecture est divisée entre une abstraction DOM cœur et des modules de réseau, de rendu, de fenêtres et de gestion d’état, tandis que les crates wrappers de haut niveau blitz et dioxus-native prennent en charge le rendu HTML/Markdown ou Dioxus VirtualDom
  • La nouvelle version Blitz v0.2+ utilise Stylo ; le code source de la v0.1 reste disponible dans la branche legacy, mais n’est plus développé activement

Un moteur centré sur le rendu HTML/CSS

  • Blitz est un moteur de rendu HTML/CSS, né du constat que les navigateurs sont lourds au regard du cas d’usage de base qu’est le rendu HTML/CSS
  • L’objectif n’est pas d’implémenter l’ensemble des fonctionnalités d’un navigateur, mais de se concentrer sur celles nécessaires au rendu HTML/CSS et de rendre le reste autant que possible optionnel
  • Le projet est actuellement en pré-alpha
    • Le moteur de rendu est déjà assez fonctionnel
    • Il reste encore beaucoup de bugs et de fonctionnalités manquantes
    • Son utilisation pour créer des applications n’est pas encore recommandée
    • Un état d’avancement plus détaillé est disponible dans la roadmap issue

Fonctionnalités visées et fonctionnalités exclues

  • Le périmètre que Blitz vise à prendre en charge est centré sur le rendu d’interfaces HTML/CSS
    • Mise en page HTML moderne : flexbox, grid, table, block, inline, absolute/fixed, etc.
    • CSS avancé, comme les sélecteurs complexes, les media queries et les variables CSS
    • Contrôles de formulaires HTML
    • Accessibilité basée sur AccessKit
    • Extensibilité via des widgets personnalisés
  • Blitz ne fournit pas de fonctionnalités comme WebRTC, WebSockets, Bluetooth ou localStorage
    • Dans les applications natives, une grande partie de ces fonctionnalités peut être gérée avec des crates Rust classiques
    • La position du projet est que ces fonctionnalités n’ont pas besoin d’être couplées au moteur de rendu
  • Il n’existe pas encore de bindings pour d’autres langages comme JavaScript ou Python, mais les contributions en ce sens peuvent être acceptées

Exécution et exemples

  • Après avoir cloné le dépôt, il est possible de lancer le package browser
cargo run --release --package browser
  • Les exemples fournis incluent une petite application TODO, un moteur de rendu Markdown et une intégration avec du rendu WGPU brut
cargo run --release --package todomvc

cargo run --release --package readme ./README.md

cargo run --release --package wgpu_texture

Architecture modulaire

  • Blitz se compose d’une abstraction DOM cœur, de modules de fonctionnalités supplémentaires et de deux wrappers de haut niveau
    • Les fonctionnalités comme le réseau, le rendu, les fenêtres et la gestion d’état sont séparées en modules distincts
    • Ces éléments peuvent être combinés pour créer un moteur web complet

  • Crates wrappers de haut niveau

    • blitz : frontend HTML/Markdown capable de rendre une chaîne HTML
    • Utile pour prévisualiser des fichiers HTML ou Markdown
    • Il n’y a actuellement pas d’interaction
    • Utilise blitz-dom, blitz-html, blitz-shell et blitz-renderer-vello
    • dioxus-native : frontend Dioxus qui rend un Dioxus VirtualDom
    • Prend en charge une interaction complète via la gestion des événements de Dioxus
    • Utilise blitz-dom, dioxus-core, blitz-shell et blitz-renderer-vello
    • Les deux wrappers peuvent utiliser blitz-net de manière optionnelle pour récupérer des ressources secondaires

  • Crates cœur et crates additionnelles

    • blitz-dom : abstraction DOM cœur incluant la résolution de styles, la mise en page et la gestion des événements
    • N’inclut pas le parsing, le rendu ni l’intégration système
    • Utilise Stylo, Taffy et Parley
    • blitz-traits : crate de base minimale permettant aux autres crates d’interopérer sans dépendre directement les unes des autres
    • blitz-net : module réseau qui récupère des ressources depuis HTTP, le système de fichiers et des data URI encodées
    • Utilise reqwest
    • blitz-paint : convertit l’arbre blitz-dom en draw commands anyrender
    • Utilise anyrender
    • blitz-html : ajoute le parsing HTML à blitz-dom
    • Utilise html5ever et xml5ever
    • blitz-shell : shell permettant à Blitz de rendre dans une fenêtre
    • Intègre la boucle d’événements Winit, AccessKit, Muda, etc.
    • Utilise winit, accesskit et muda
    • L’abstraction de rendu AnyRender a été déplacée dans un dépôt séparé, anyrender

Utiliser la version de développement de Dioxus Native

  • La dernière version de développement de Dioxus Native se trouve dans ce dépôt
  • Comme Dioxus Native évolue rapidement, il est possible d’utiliser la version git pour bénéficier des dernières fonctionnalités et corrections de bugs avant les releases officielles
  • La procédure pour utiliser la version git est la suivante
    • Supprimer complètement la dépendance au crate dioxus
    • Ajouter dioxus-native = { git = "https://github.com/DioxusLabs/blitz";, rev = "e64a3d8", features = ["prelude"] }
    • Remplacer e64a3d8 par l’identifiant du commit git de la version souhaitée
    • Dans le code Rust, remplacer use dioxus::prelude::* par use dioxus_native::prelude::*
    • Si des fonctionnalités de dioxus non exportées par le prelude de Dioxus Native sont nécessaires, les importer depuis les sub-crates individuels comme dioxus-html, dioxus-signals ou dioxus-router
  • La version git de Dioxus Native dépend toujours de la version stable Dioxus v0.7.x disponible sur crates.io
    • Les bibliothèques additionnelles comme dioxus-sdk, dioxus-components et dioxus-free-icons devraient continuer à fonctionner

Versions et licences

  • Ce dépôt contient la nouvelle version Blitz v0.2+, qui utilise Stylo
  • Le code source de l’ancienne version v0.1 reste disponible dans la branche legacy
    • La v0.1 n’est pas développée activement
  • Le projet est distribué sous double licence Apache 2.0 et MIT
  • Le crate stylo_taffy est également soumis à la MPL 2.0 afin de faciliter l’interopérabilité avec le projet Servo
    • stylo_taffy est donc sous triple licence Apache 2.0, MIT et MPL 2.0
  • Sauf conditions particulières, les contributions soumises intentionnellement à Blitz sont placées sous double licence Apache 2.0 et MIT
    • Les contributions à stylo_taffy incluent aussi la MPL 2.0

À lire aussi

1 commentaires

 
GN⁺ 2024-08-13
Avis de Hacker News

  • Je suis le développeur principal de Blitz. Ce n’est pas encore abouti, et le système de saisie de texte/focus est basique ; le défilement en dehors du viewport racine n’est pas pris en charge. Les sélecteurs CSS complexes comme nth-child ou :has ne fonctionnent pas encore correctement, et l’intégration de la gestion des événements avec Dioxus, le framework de type React construit au-dessus de Blitz, se limite aux clics ; il n’y a même pas preventDefault. Le réseau est pour l’instant très simple : les requêtes sont synchrones sur le thread principal, et il faudra une vraie gestion réseau asynchrone ou multithread. Le travail sur les performances est aussi à peine entamé : style, layout et paint sont recalculés à chaque frame, et il existe aussi quelques fuites mémoire dues à des nœuds qui ne sont pas nettoyés. Les ombres, les polices web, calc, les layouts avec float et les contrôles de formulaire autres que la saisie de texte manquent encore. Au fond, c’est plutôt « construire une webview est un gros chantier et nous n’en sommes pas encore là » ; nous espérons une forme plus complète d’ici 2 à 3 mois. Des captures d’écran sont aussi disponibles ici : https://github.com/DioxusLabs/blitz/issues/23

    • Personnellement, j’aimerais concevoir un nouveau format de document avec une sémantique plus simple, plus facile à rendre. HTML me paraît assez complexe, et il n’a pas non plus été conçu pour le rendu dynamique. En tant qu’amateur de lean et de KISS, HTML ne me semble pas suffisamment léger ni simple.
    • Je cherchais une solution pour capturer des captures d’écran de sites web et, si possible, les produire à partir d’une représentation déjà crawlée. Les services existants lancent généralement une instance Chromium pour demander une capture d’écran, ce qui semble assez coûteux, aussi bien en exploitation qu’en frais SaaS. Dans ce cas, Blitz semble bien adapté, et je me demande s’il peut actuellement être lancé en mode headless pour enregistrer des captures d’écran.
    • Je suis curieux de connaître la motivation derrière le fait d’assembler directement plusieurs composants plutôt que de s’appuyer sur Servo, WebKit ou autre.
    • Je me demande quelles sont les parties d’ingénierie les plus complexes à gérer. Même si c’est encore en cours, ce serait bien de pouvoir partager un document de conception. Personnellement, je m’intéresse à la façon dont des moteurs comme Blitz ou Servo pourraient à l’avenir être construits avec des méthodes formelles. Par exemple, partir d’une définition pour générer une partie du système ; de nos jours cela inclut aussi les LLM, mais je les vois davantage comme d’excellents outils que comme des systèmes d’IA. Je pense aussi à des choses comme Z3. Certaines de mes entreprises ont aussi des organisations de recherche sur ce genre de sujets.
    • Je me demande si Blitz a été créé pour permettre à d’autres personnes de construire des navigateurs. Nous construisons Wootzapp (https://github.com/wootzapp/wootz-browser), une sorte de Robinhood de l’étiquetage de données, où l’on peut consacrer du temps à l’étiquetage de données web ou d’images et être rémunéré. Pour l’instant, c’est basé sur Chromium, et je me demande si Blitz vise à devenir un moteur de rendu que l’on pourrait brancher dans d’autres navigateurs. Nous travaillons aussi sur mobile : Android actuellement, puis iOS ensuite.

  • À première vue, ce projet semble très utile. Il permet de créer des apps natives avec le paradigme de mise en page HTML/CSS largement utilisé, tout en retirant les parties lourdes qu’impliquent un JS/DOM/API de navigateur complets. Cela pourrait permettre une amélioration bien plus importante que le fait d’embarquer un moteur de navigateur comme Electron. Justement, j’ai récemment entendu Casey Muratori critiquer très sévèrement CSS dans le podcast de Richard Feldman. Les exemples où il fallait pré-rendre des pages web et les mesurer dynamiquement pour obtenir de simples relations de layout m’ont particulièrement parlé. Comme le dit Muratori, écrire du CSS ressemble moins à construire sur des primitives simples qu’à plaider une affaire au tribunal. Bien sûr, en raison de la familiarité, de la compatibilité et du fait que le « chemin heureux » de CSS est extrêmement productif, la demande à laquelle répond ce genre de projet est importante. Mais il semble aussi y avoir une occasion d’offrir une couche plus simple et plus générale vers laquelle les utilisateurs peuvent descendre. Il pourrait s’inspirer de CSS Houdini, qui vise à rendre CSS extensible via une API JS ; c’est peut-être aussi ce que signifie « Custom Widgets ».

    • C’est à peu près la proposition de Blitz. Les algorithmes de layout enfichables sont quelque chose que nous voulons absolument rendre possible dans Blitz. Faire le layout en JS serait probablement trop lent dans la plupart des cas, mais le fait que l’API soit en Rust est un avantage. Le moteur de layout Taffy (https://github.com/DioxusLabs/taffy) est déjà assez modulaire. Les widgets personnalisés visent à aller au-delà du layout et à permettre un layout, un paint, une accessibilité, une gestion des événements, etc. entièrement personnalisés, comme les widgets des toolkits GUI traditionnels. Nous avons aussi une proposition pour ajouter de nouvelles unités à CSS lui-même. Elle s’inspire des méthodes de layout de nombreux systèmes d’UI non web et pourrait simplifier fortement le layout web dans les cas courants : https://github.com/w3c/csswg-drafts/issues/8267 Cela a été mis de côté pendant un moment, mais il faudra y revenir un jour, et j’aimerais vraiment implémenter l’algorithme.
    • Je me demande si c’est comme un Dillo amélioré : https://en.m.wikipedia.org/wiki/Dillo Ce serait bien d’avoir quelque chose de ce genre pour une navigation web simple ou pour des apps. La seule chose similaire que je connaissais était Sciter ; c’était un logiciel propriétaire, mais son modèle de licence était innovant.
    • Il nous faut un CSS strict qui supprime le superflu et promette de meilleures performances. Je ne comprends pas pourquoi les navigateurs ne le proposent pas encore ; par exemple, il suffirait déjà de retirer float.

  • Il y a quelques années — enfin, il y a 20 ans — j’ai créé un projet open source similaire appelé Flying Saucer. C’était un moteur de rendu HTML + CSS2 en Java pur. J’imaginais qu’il servirait à rendre des interfaces texte riches dans des jeux, mais son usage principal s’est avéré être la génération de PDF côté serveur. Il était bien plus simple de générer du HTML puis de le rendre en PDF que d’utiliser les diverses API de génération de rapports PDF disponibles à l’époque. Blitz a l’air sympa, et j’ai hâte de voir davantage de bibliothèques GUI en Rust. https://en.wikipedia.org/wiki/Flying_Saucer_(library) Étonnamment, il est encore mis à jour : https://github.com/flyingsaucerproject/flyingsaucer/releases...

  • « Une WebView légère qui remplace le moteur JavaScript par une API Rust native », ça semble prometteur. Si, en gros, c’est comme Tauri sans JS dans le chemin d’exécution, rien que l’idée me plaît

    • C’est vrai dans une certaine mesure, mais Tauri utilise la WebView du système, alors que nous construisons notre propre WebView. Elle repose en partie sur des composants Servo et des bibliothèques généralistes, et en partie sur du code maison. À certains égards, c’est plus proche de Sciter sans JS
    • Sciter me semble être une meilleure comparaison : https://sciter.com/ Il implémente le rendu HTML et CSS à partir de zéro. De mémoire, il avait autrefois son propre langage de programmation, et utilise maintenant JS. Je m’intéresse depuis longtemps à ce genre de choses, mais je n’ai jamais vraiment utilisé Sciter en profondeur. À l’époque, sa licence m’inquiétait, mais en regardant le site aujourd’hui, les conditions semblent beaucoup plus souples. Il vaut aussi la peine d’ajouter que si l’on veut utiliser une WebView système sans JS, il suffit tout simplement de désactiver JS dans la WebView système
    • Tauri utilise la WebView native, donc cela varie selon les plateformes. Blitz est son propre moteur de rendu

  • Intéressant. Pas plus tard qu’aujourd’hui, j’ai vécu une horreur avec puppeteer et Chromium headless, et je cherchais une alternative à wkhtmltopdf. Il ne faut absolument jamais lancer ça avec jemalloc dans LD_PRELOAD. J’ai résolu le problème, mais un moteur de rendu plus simple m’aurait bien plus plu.

    • Vous n’êtes pas la première personne à s’intéresser à son usage pour le rendu PDF. Il faudra sans doute davantage de prise en charge des propriétés CSS orientées impression et de la mise en page paginée : répartir la mise en page sur plusieurs pages distinctes et contrôler l’emplacement des sauts de page. Cela dit, c’est clairement un domaine que nous devrions pouvoir prendre en charge un jour.
    • Mon cas d’usage était un peu différent. J’essayais de rendre un élément d’une page avec Chromium Headless via Playwright, mais j’obtenais aléatoirement beaucoup de « Page crashed » et de « Timed out after 30s » dans Playwright. En passant à Firefox Headless, ces problèmes ont disparu, et en pratique Firefox s’est avéré environ 3 fois plus rapide que Chromium Headless pour le rendu. Blitz est très intéressant et proche de ce dont j’avais besoin. J’utilisais un navigateur headless au lieu de tout rendre moi-même avec Java Graphics2D, car la mise en page de ce que je devais rendre était assez complexe et je ne voulais pas réinventer la roue en écrivant mon propre moteur de layout.
    • Jetez un œil à gotenberg[0], cela pourrait répondre à votre besoin. Je l’utilise dans GitHub Actions pour convertir mon CV en PDF. [0]: https://github.com/gotenberg/gotenberg
    • Oui, Wkhtmltopdf est vraiment un monstre dévoreur de ressources. Les autres solutions prennent en charge la spec HTML de façon incomplète, ce qui rend difficile la production correcte des PDF souhaités, sauf si quelqu’un trouve une manière de faire avec des fonctionnalités moins modernes.

  • Ce n’est pas directement à propos de Blitz, mais je viens de découvrir Dioxus. Je me demande s’il existe une règle tacite selon laquelle les frameworks qui compilent vers WASM ne montrent pas correctement de démos, ou n’hébergent pas leur propre site avec ledit framework. J’ai l’impression d’avoir vu ça 5 ou 6 fois. Sur la page d’accueil de Dioxus, on voit bien un fichier WASM se charger, mais on ne sait pas clairement à quoi il sert, ni même s’il est réellement utilisé.

    • Le site de Dioxus est bien hébergé avec son propre framework, mais comme il prend en charge le rendu côté serveur et l’hydratation, le bundle WASM ne sert qu’aux fonctionnalités interactives. Une démo vidéo est aussi en préparation. Je serais curieux de savoir ce que vous aimeriez voir en particulier.

  • Avec un backend et htmx, ça pourrait être génial. Cela dit, comme il semble n’y avoir aucun moteur JS dans le mélange, je me demande comment cela pourrait fonctionner.

    • Je pense que ce serait une combinaison légendaire. Idéalement, le moteur de rendu web devrait prendre en charge HTMX nativement. L’idée générale de HTMX est de prendre en charge des fonctionnalités qui rendent HTML plus complet. Pourquoi seuls et devraient-ils pouvoir faire des requêtes HTTP, pourquoi seuls les événements de clic et de soumission devraient-ils déclencher des requêtes, pourquoi seulement GET et POST, pourquoi ne pourrait-on remplacer que tout l’écran ? Vu autrement, HTMX rend les éléments HTML moins restrictifs et plus génériques. Si un moteur de rendu web en tient compte dès sa conception, cela pourrait même le rendre plus simple.
    • Il existe un mouvement visant à intégrer les fonctionnalités de base de HTMX dans la spécification HTML, ce qui pourrait rendre JS inutile. https://www.reddit.com/r/htmx/comments/1ehjw7v/comment/lg09w...
    • C’est simple. Il suffit de remplacer htmx par Dioxus, ou peut-être plus tard par leptos.

  • Je viens de découvrir Dioxus aujourd’hui. https://dioxuslabs.com/

  • Vraiment génial. J’aimerais l’essayer dans un projet C++. Une question qui me vient à l’esprit concerne les performances. Je me demande s’il peut rendre des pages relativement complexes à un nombre élevé d’images par seconde. J’utilise généralement ImGUI, qui est excellent au point qu’on n’a presque pas à se soucier des performances pour afficher des données en temps réel. En revanche, le rendu web de Chromium peut faire grimper le CPU en flèche rien qu’avec de simples mises à jour de texte dans le DOM à 10 images par seconde ; si cela était résolu, cela pourrait changer la donne.

    • Les performances actuelles sont médiocres. Mais nous n’avons encore fait aucun effort d’optimisation, et comme nous construisons sur des dépendances plutôt rapides, il y a de bonnes chances que cela s’améliore beaucoup. Je ne pense pas que nous puissions battre Chromium dans un « combat équitable », mais il y a un potentiel pour rendre possibles des choses impossibles dans Chrome, par exemple une API de type canvas bien plus puissante.