Blitz: Leichter, modularer und erweiterbarer Web-Renderer

 (github.com/DioxusLabs)
2 Punkte von GN⁺ 2024-08-13 | 1 Kommentare | Auf WhatsApp teilen
  • Blitz ist eine modulare Rendering-Engine mit Fokus auf HTML/CSS-Rendering und ist so konzipiert, dass nicht der komplette Funktionsumfang eines Browsers standardmäßig enthalten ist, sondern zusätzliche Funktionen bei Bedarf optional ergänzt werden können
  • Der aktuelle Status ist pre-alpha: Der Renderer bringt bereits beträchtliche Funktionalität mit, hat aber noch viele Bugs und fehlende Funktionen, weshalb der Einsatz für die App-Entwicklung noch nicht empfohlen wird
  • Zu den angestrebten unterstützten Funktionen gehören moderne HTML-Layouts, fortgeschrittenes CSS, HTML-Formularsteuerelemente, auf AccessKit basierende Barrierefreiheit sowie Erweiterbarkeit durch custom widgets; Funktionen wie WebRTC, WebSockets, Bluetooth oder localStorage werden nicht bereitgestellt
  • Die Struktur ist in eine Core-DOM-Abstraktion sowie Module für Networking, Rendering, Fenster und Zustandsverwaltung aufgeteilt; die übergeordneten Wrapper-Crates blitz und dioxus-native übernehmen das Rendern von HTML/Markdown bzw. Dioxus VirtualDom
  • Die neue Version Blitz v0.2+ verwendet Stylo; der Quellcode von v0.1 bleibt im Branch legacy erhalten, wird aber nicht mehr aktiv weiterentwickelt

Engine mit Fokus auf HTML/CSS-Rendering

  • Blitz ist eine HTML/CSS-Rendering-Engine und entstand aus der Einschätzung, dass Browser im Vergleich zum eigentlichen Standard-Anwendungsfall HTML/CSS-Rendering zu umfangreich geworden sind
  • Ziel ist nicht, den vollständigen Funktionsumfang eines Browsers zu implementieren, sondern sich auf die für HTML/CSS-Rendering nötigen Funktionen zu konzentrieren und den Rest nach Möglichkeit opt-in zu gestalten
  • Derzeit befindet sich das Projekt im Status pre-alpha
    • Der Renderer verfügt bereits über beträchtliche Funktionalität
    • Es gibt jedoch noch viele Bugs und fehlende Funktionen
    • Für den Bau von Apps wird die Nutzung derzeit noch nicht empfohlen
    • Weitere Details zum Fortschritt finden sich im roadmap issue

Geplante und ausgeschlossene Funktionen

  • Der von Blitz angestrebte Umfang ist auf HTML/CSS-UI-Rendering ausgerichtet
    • moderne HTML-Layouts wie flexbox, grid, table, block, inline, absolute/fixed
    • fortgeschrittenes CSS wie complex selectors, media queries und CSS variables
    • HTML-Formularsteuerelemente
    • auf AccessKit basierende Barrierefreiheit
    • Erweiterbarkeit über custom widgets
  • Blitz stellt keine Funktionen wie WebRTC, WebSockets, Bluetooth oder localStorage bereit
    • In nativen Apps lässt sich ein großer Teil solcher Funktionen mit gewöhnlichen Rust-Crates umsetzen
    • Die Position des Projekts ist, dass solche Funktionen nicht an den Renderer gekoppelt sein müssen
  • Bindings für andere Sprachen wie JavaScript oder Python gibt es derzeit noch nicht, Beiträge dazu sind aber willkommen

Ausführung und Beispiele

  • Nach dem Klonen des Repositorys kann das Paket browser ausgeführt werden
cargo run --release --package browser
  • Als Beispiele stehen eine kleine TODO-App, ein Markdown-Renderer und die Integration von rohem WGPU-Rendering bereit
cargo run --release --package todomvc

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

cargo run --release --package wgpu_texture

Modulare Architektur

  • Blitz besteht aus einer Core-DOM-Abstraktion, Zusatzmodulen und zwei übergeordneten Wrappern
    • Funktionen wie Networking, Rendering, Fenster und Zustandsverwaltung sind in separate Module aufgeteilt
    • Durch die Kombination dieser Bausteine lässt sich eine Web-Engine erstellen

  • Übergeordnete Wrapper-Crates

    • blitz: ein HTML/Markdown-Frontend, das HTML-Strings rendern kann
    • Nützlich für die Vorschau von HTML- oder Markdown-Dateien
    • Derzeit ohne Interaktivität
    • Verwendet blitz-dom, blitz-html, blitz-shell, blitz-renderer-vello
    • dioxus-native: ein Dioxus-Frontend, das Dioxus VirtualDom rendert
    • Unterstützt vollständige Interaktivität über Dioxus-Event-Handling
    • Verwendet blitz-dom, dioxus-core, blitz-shell, blitz-renderer-vello
    • Beide Wrapper können optional blitz-net verwenden, um Unterressourcen abzurufen

  • Kern-Crates und zusätzliche Crates

    • blitz-dom: eine Core-DOM-Abstraktion mit style resolution, layout und event handling
    • Enthält kein Parsing, Rendering oder Systemintegration
    • Verwendet Stylo, Taffy, Parley
    • blitz-traits: eine minimale Basis-Crate, damit andere Crates interoperabel bleiben, ohne direkt voneinander abzuhängen
    • blitz-net: ein Networking-Modul zum Abrufen von Ressourcen über HTTP, Dateisystem und encoded data URI
    • Verwendet reqwest
    • blitz-paint: wandelt den blitz-dom-Baum in anyrender-Draw-Commands um
    • Verwendet anyrender
    • blitz-html: fügt blitz-dom HTML-Parsing hinzu
    • Verwendet html5ever und xml5ever
    • blitz-shell: eine Shell, mit der Blitz in ein Fenster rendern kann
    • Integriert Winit-Event-Loop, AccessKit, Muda usw.
    • Verwendet winit, accesskit, muda
    • Die AnyRender-Rendering-Abstraktion wurde in das separate Repository anyrender ausgelagert

Verwendung der Entwicklungsversion von Dioxus Native

  • Die neueste Entwicklungsversion von Dioxus Native befindet sich in diesem Repository
  • Da Dioxus Native schnell weiterentwickelt wird, kann die Git-Version verwendet werden, um neueste Funktionen und Bugfixes vor den offiziellen Releases zu nutzen
  • Das Vorgehen zur Nutzung der Git-Version ist wie folgt
    • Die Abhängigkeit zur Crate dioxus vollständig entfernen
    • dioxus-native = { git = "https://github.com/DioxusLabs/blitz";, rev = "e64a3d8", features = ["prelude"] } hinzufügen
    • e64a3d8 durch die Commit-ID der gewünschten Git-Version ersetzen
    • Im Rust-Code use dioxus::prelude::* in use dioxus_native::prelude::* ändern
    • Falls Funktionen aus dioxus benötigt werden, die das Dioxus-Native-Prelude nicht exportiert, diese aus einzelnen Sub-Crates wie dioxus-html, dioxus-signals oder dioxus-router importieren
  • Die Git-Version von Dioxus Native hängt weiterhin von der stabilen Version Dioxus v0.7.x auf crates.io ab
    • Zusätzliche Bibliotheken wie dioxus-sdk, dioxus-components oder dioxus-free-icons sollten weiterhin funktionieren

Versionen und Lizenz

  • Dieses Repository enthält die neue Version Blitz v0.2+, die Stylo verwendet
  • Der Quellcode der vorherigen Version v0.1 bleibt im Branch legacy erhalten
    • v0.1 wird nicht aktiv weiterentwickelt
  • Das Projekt wird unter einer Dual-Lizenz aus Apache 2.0 und MIT veröffentlicht
  • Für die Crate stylo_taffy gilt zusätzlich MPL 2.0, um die Interoperabilität mit dem Servo-Projekt zu erleichtern
    • stylo_taffy steht damit unter einer Triple-Lizenz aus Apache 2.0, MIT und MPL 2.0
  • Beiträge, die absichtlich an Blitz eingereicht werden, gelten sofern nicht anders angegeben ebenfalls als dual lizenziert unter Apache 2.0 und MIT
    • Für Beiträge an stylo_taffy gilt zusätzlich MPL 2.0

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-08-13
Hacker-News-Kommentare

  • Ich bin der Hauptentwickler von Blitz. Es ist noch nicht fertig; das Text-Eingabe-/Fokussystem ist noch grundlegend, und Scrollen außerhalb des Root-Viewports wird nicht unterstützt. Komplexe CSS-Selektoren wie nth-child und :has funktionieren noch nicht richtig, und auch die Event-Integration mit Dioxus, einem React-ähnlichen Framework auf Basis von Blitz, ist erst auf dem Stand, dass nur Klicks funktionieren; preventDefault gibt es ebenfalls noch nicht. Das Networking ist derzeit sehr einfach und führt synchrone Requests im Main-Thread aus; es braucht richtiges asynchrones oder multithreaded Networking. An der Performance wurde auch kaum gearbeitet, daher werden Stil/Layout/Paint in jedem Frame neu berechnet, und wegen nicht aufgeräumter Nodes gibt es an einigen Stellen Memory Leaks. Schatten, Webfonts, calc, Float-Layouts und Form-Controls außer Texteingabe fehlen ebenfalls noch. Letztlich entspricht es eher „ein Webview zu bauen ist eine große Aufgabe, und so weit sind wir noch nicht“, aber ich erwarte in 2–3 Monaten einen deutlich vollständigeren Stand. Screenshots gibt es auch hier: https://github.com/DioxusLabs/blitz/issues/23

    • Persönlich würde ich gern ein neues Dokumentformat mit einfacherer Semantik entwerfen, das leichter zu rendern ist. HTML wirkt ziemlich komplex und wurde auch nicht für dynamisches Rendering entworfen. Wenn man lean und KISS mag, wirkt HTML nicht leichtgewichtig oder einfach genug.
    • Ich habe nach einer Lösung gesucht, um Screenshots von Websites zu erzeugen, möglichst auf Basis einer zuvor gecrawlten Repräsentation. Bestehende Dienste starten meist eine Chromium-Instanz und nehmen dann den Screenshot auf; sowohl die Betriebskosten als auch die SaaS-Kosten wirken daher ziemlich hoch. Deshalb scheint Blitz gut zu passen, aber ich frage mich, ob es derzeit im Headless-Modus laufen und Screenshots speichern kann.
    • Mich interessiert die Motivation, das nicht auf etwas wie Servo oder WebKit aufzubauen, sondern verschiedene Komponenten selbst zu kombinieren.
    • Mich interessiert, was die technisch komplexesten Teile sind, die ihr bewältigen müsst. Auch wenn es noch in Arbeit ist, wäre es großartig, wenn ihr Design-Dokumente teilen könntet. Ich persönlich interessiere mich dafür, wie sich Engines wie Blitz oder Servo künftig mit formalen Methoden bauen lassen könnten. Zum Beispiel ausgehend von Definitionen und dann Teile des Systems zu generieren; heutzutage gehören dazu auch LLMs, aber ich sehe sie eher als hervorragende Werkzeuge denn als AI-Systeme. Dabei denke ich auch an Dinge wie Z3. Einige meiner Unternehmen haben ebenfalls Forschungsgruppen zu solchen Themen.
    • Ich frage mich, ob Blitz gebaut wird, damit andere Leute Browser bauen können. Ich arbeite an Wootzapp(https://github.com/wootzapp/wootz-browser), einer Art Robinhood für Datenlabeling, bei dem man Zeit für Webdaten oder Bild-Labeling aufwenden und dafür belohnt werden kann. Momentan basiert es auf Chromium; ich frage mich, ob Blitz ein Renderer werden soll, den man in andere Browser einstecken kann. Wir machen auch Mobile, aktuell Android und als Nächstes iOS.

  • Dieses Projekt wirkt schon auf den ersten Blick sehr nützlich. Es geht darum, native Apps mit dem weit verbreiteten HTML/CSS-Layout-Paradigma zu bauen, aber ohne den schweren Ballast, den vollständiges JS/DOM/Browser-API impliziert. Das könnte eine viel größere Verbesserung ermöglichen, als einfach eine Browser-Engine wie bei Electron mit auszuliefern. Zufällig habe ich kürzlich in Richard Feldmans Podcast gehört, wie Casey Muratori sehr kritisch über CSS sprach. Besonders eingängig waren Beispiele, bei denen man Webseiten vorab rendern und dynamisch vermessen musste, nur um einfache Layout-Beziehungen herzustellen. Wie Muratori sagt, fühlt sich das Schreiben von CSS weniger so an, als würde man auf einfachen Primitiven aufbauen, sondern eher wie das Plädieren eines Falls vor Gericht. Natürlich ist der Bedarf an so einem Projekt groß, weil Vertrautheit, Kompatibilität und „CSS auf dem Pfad, wo es einfach funktioniert“ enorm produktiv sind. Aber es scheint auch die Chance zu geben, eine einfachere und allgemeinere Schicht bereitzustellen, zu der Nutzer hinabsteigen können. Man könnte sich von CSS Houdini inspirieren lassen, das CSS über eine JS-API erweiterbar machen will; vielleicht ist genau das mit „Custom Widgets“ gemeint.

    • Das kommt der Vision von Blitz ziemlich nahe. Austauschbare Layout-Algorithmen sind etwas, das ich in Blitz unbedingt ermöglichen möchte. Layout in JS wäre in den meisten Fällen vermutlich zu langsam, aber dass die API in Rust ist, hilft dabei. Auch die Layout-Engine Taffy(https://github.com/DioxusLabs/taffy) ist bereits ziemlich modular. Bei Custom Widgets geht es über Layout hinaus darum, vollständige eigene Layout-, Paint-, Accessibility- und Event-Handling-Logik zu erlauben, ähnlich wie Widgets in klassischen GUI-Toolkits. Ich habe auch einen Vorschlag für neue Units in CSS. Er ist von den Layout-Ansätzen vieler Nicht-Web-UI-Systeme inspiriert und könnte Web-Layouts im allgemeinen Fall stark vereinfachen: https://github.com/w3c/csswg-drafts/issues/8267 Das lag eine Zeit lang auf Eis, aber irgendwann muss ich wieder daran arbeiten und möchte die Algorithmen tatsächlich einmal implementieren.
    • Ich frage mich, ob es sich wie ein verbessertes Dillo anfühlt: https://en.m.wikipedia.org/wiki/Dillo Für einfaches Web-Browsing oder Apps wäre so etwas schön. Das Einzige Ähnliche, das ich kannte, war Sciter; es war proprietäre Software, aber das Lizenzmodell war innovativ.
    • Es braucht striktes CSS, das Ballast entfernt und Performance-Gewinne verspricht. Ich verstehe nicht, warum Browser das noch nicht anbieten; man könnte zum Beispiel einfach float weglassen.

  • Vor ein paar Jahren, nein, eher vor 20 Jahren, habe ich ein ähnliches Open-Source-Projekt namens Flying Saucer gebaut. Es war ein reiner HTML-+CSS2-Renderer in Java. Ich hatte mir vorgestellt, ihn zum Rendern reichhaltiger Text-UIs in Spielen zu verwenden, aber der eigentliche Kernanwendungsfall war serverseitige PDF-Erzeugung. Es war damals viel einfacher, HTML zu erzeugen und als PDF zu rendern, als die diversen APIs zur PDF-Report-Erstellung zu nutzen, die es damals gab. Blitz sieht großartig aus, und ich freue mich auf mehr Rust-GUI-Bibliotheken. https://en.wikipedia.org/wiki/Flying_Saucer_(library) Erstaunlicherweise wird es noch immer aktualisiert: https://github.com/flyingsaucerproject/flyingsaucer/releases...

  • Eine „leichtgewichtige Webview, die die JavaScript-Engine durch eine native Rust-API ersetzt“, klingt vielversprechend. Wenn das im Grunde so etwas wie Tauri ohne JS im Pfad ist, klingt das schon beim Zuhören gut

    • Das stimmt bis zu einem gewissen Grad, aber Tauri verwendet die System-Webview, während wir unsere eigene Webview bauen Ein Teil basiert auf Servo-Komponenten und allgemeinen Bibliotheken, ein Teil ist selbst entwickelt. In mancher Hinsicht ist es eher mit Sciter ohne JS vergleichbar
    • Sciter scheint der bessere Vergleich zu sein: https://sciter.com/ Es implementiert HTML- und CSS-Rendering von Grund auf. Soweit ich mich erinnere, hatte es früher eine eigene Programmiersprache und nutzt jetzt JS Ich interessiere mich schon lange für solche Dinge, habe Sciter aber nie intensiv eingesetzt. Früher war ich wegen der Lizenz besorgt, aber wenn ich mir die Website jetzt ansehe, scheinen die Bedingungen deutlich flexibler geworden zu sein Erwähnenswert ist auch, dass man, wenn man eine System-Webview ohne JS nutzen will, einfach JS in der System-Webview deaktivieren kann
    • Tauri verwendet native Webviews und verhält sich daher je nach Plattform unterschiedlich. Blitz ist ein eigener Renderer

  • Interessant. Ich hatte ausgerechnet heute wegen puppeteer und headless Chromium eine schreckliche Zeit und war auf der Suche nach einem Ersatz für wkhtmltopdf Man sollte absolut niemals jemalloc über LD_PRELOAD injizieren und es dann ausführen. Ich habe das Problem zwar gelöst, aber ein einfacherer Renderer hätte mir besser gefallen

    • Du bist nicht der Erste, der Interesse am PDF-Rendering gezeigt hat Wahrscheinlich bräuchte es mehr Unterstützung für druckorientierte CSS-Eigenschaften und seitenbasiertes Layout. Also die Möglichkeit, ein Layout über mehrere einzelne Seiten zu verteilen und zu steuern, wo Seitenumbrüche stattfinden Trotzdem ist das klar ein Bereich, der irgendwann unterstützt werden sollte
    • Mein Anwendungsfall war etwas anders. Ich wollte mit Chromium Headless in Playwright ein Element einer Seite rendern, aber in Playwright traten zufällig oft „Page crashed“ und „Timed out after 30s“ auf Nach dem Wechsel zu Firefox Headless verschwanden diese Probleme, und tatsächlich war der Renderer mit Firefox etwa 3-mal schneller als mit Chromium Headless Blitz ist sehr interessant und näher an dem, was ich gebraucht habe. Ich hatte einen Headless-Browser verwendet, anstatt alles direkt mit Java Graphics2D zu rendern, weil das zu rendernde Layout etwas komplex war und ich nicht das Rad neu erfinden wollte, indem ich selbst eine Layout-Engine baue
    • Schau dir gotenberg[0] an, das könnte den Bedarf decken. Ich nutze es in GitHub Actions, um einen Lebenslauf in PDF umzuwandeln [0]: https://github.com/gotenberg/gotenberg
    • Stimmt, Wkhtmltopdf ist wirklich ein Ressourcenfresser Andere Lösungen unterstützen die HTML-Spezifikation nur unvollständig, sodass es schwer ist, das gewünschte PDF sauber zu erzeugen. Es sei denn, jemand findet einen Weg mit weniger modernen Funktionen

  • Es geht zwar nicht direkt um Blitz selbst, aber ich habe dadurch zum ersten Mal von Dioxus erfahren Ich frage mich, ob es bei Frameworks, die nach WASM kompiliert werden, eine unausgesprochene Regel gibt, dass sie entweder keine ordentliche Demo zeigen oder ihre eigene Website nicht mit dem Framework selbst hosten. Ich habe das bestimmt schon 5- oder 6-mal gesehen Auf der Dioxus-Website sieht man zwar, dass WASM-Dateien geladen werden, aber es ist nicht klar, wofür sie verwendet werden oder ob sie überhaupt wirklich verwendet werden

    • Die Dioxus-Website wird mit dem eigenen Framework betrieben, unterstützt aber Server-Side Rendering und Hydration, daher wird das WASM-Bundle nur für Interaktivität verwendet Wir arbeiten auch an einer Video-Demo. Mich würde interessieren, was du dir dabei besonders ansehen möchtest

  • Mit einem Backend und htmx zusammen könnte das großartig sein. Allerdings scheint überhaupt keine JS-Engine beteiligt zu sein, daher frage ich mich, wie man damit etwas machen könnte

    • Das könnte eine legendäre Kombination werden Im Idealfall sollte ein Web-Renderer HTMX nativ unterstützen Die grundlegende Idee hinter HTMX ist, Funktionen zu unterstützen, die HTML vollständiger machen. Warum sollten nur und HTTP-Anfragen auslösen können, warum sollten nur Klick- und Submit-Ereignisse Anfragen triggern, warum sollten nur GET und POST möglich sein und warum sollte man nur den gesamten Bildschirm ersetzen können Anders betrachtet macht HTMX HTML-Elemente weniger restriktiv und allgemeiner. Wenn ein Web-Renderer das von Anfang an im Design berücksichtigt, könnte er dadurch sogar einfacher werden
    • Es gibt eine Bewegung, zentrale HTMX-Funktionen in die HTML-Spezifikation aufzunehmen, sodass JS möglicherweise gar nicht mehr nötig wäre https://www.reddit.com/r/htmx/comments/1ehjw7v/comment/lg09w...
    • Ganz einfach. Ersetze htmx durch Dioxus oder vielleicht später durch leptos

  • Ich höre heute zum ersten Mal von Dioxus https://dioxuslabs.com/

  • Wirklich cool. Ich würde das gern in einem C++-Projekt ausprobieren Eine Frage, die mir sofort einfällt, ist die Performance. Ich frage mich, ob sich damit relativ komplexe Seiten mit hoher Bildrate rendern lassen Normalerweise verwende ich ImGUI, das so gut ist, dass ich bei der Anzeige von Echtzeitdaten über Performanceprobleme kaum nachdenken muss. Im Gegensatz dazu bringt Web-Rendering in Chromium schon bei einfachen DOM-Text-Updates mit nur 10 Bildern pro Sekunde die CPU zum Glühen; wenn das gelöst würde, könnte das alles verändern

    • Die aktuelle Performance ist miserabel Allerdings habe ich bislang überhaupt keine Mühe in Optimierung gesteckt, und es baut auf ziemlich schnellen Abhängigkeiten auf, daher könnte es noch deutlich besser werden In einem „fairen Kampf“ wird es Chromium wohl nicht schlagen, aber es hat das Potenzial, Dinge zu ermöglichen, die in Chrome nicht möglich sind. Zum Beispiel eine viel leistungsfähigere canvas-ähnliche API