- BlitzはHTML/CSSレンダリングに焦点を当てたモジュール型レンダリングエンジンであり、ブラウザーの全機能を標準では提供せず、必要な追加機能を選択的に導入できる設計を採用している
- 現在の状態はpre-alphaで、レンダラー自体はすでにかなりの機能を備えているものの、バグや未実装機能が多く、アプリ開発に使うことはまだ推奨されていない
- 対応目標はmodern HTML layout、advanced CSS、HTML form controls、AccessKitベースのアクセシビリティ、custom widgetsによる拡張性であり、WebRTC、WebSockets、Bluetooth、localStorageのような機能は提供しない
- 構成はcore DOM abstractionと、ネットワーキング、レンダリング、ウィンドウ、状態管理モジュールに分かれており、
blitzとdioxus-nativeという上位ラッパーcrateがHTML/MarkdownまたはDioxus VirtualDomのレンダリングを担う
- 新バージョンのBlitz v0.2+はStyloを使用しており、v0.1のソースは
legacyブランチに残されているが、活発には開発されていない
HTML/CSSレンダリングに集中するエンジン
- BlitzはHTML/CSSレンダリングエンジンであり、HTML/CSSレンダリングという基本的なユースケースに比べて、ブラウザーは肥大化しすぎているという問題意識から出発している
- 目標はブラウザーの全機能を実装することではなく、HTML/CSSレンダリングに必要な機能を中心に据え、それ以外の機能は可能な限りopt-inにすることにある
- 現在はpre-alpha段階
- レンダラーはすでにかなりの機能を備えている
- まだバグや未実装機能が多い
- アプリ作成に使うことはまだ推奨されない
- より詳しい進捗状況はroadmap issueで確認できる
対応を目指す機能と対象外の機能
- Blitzが対応を目指す範囲はHTML/CSS UIレンダリングに合わせられている
- flexbox、grid、table、block、inline、absolute/fixedなどのmodern HTML layout
- complex selectors、media queries、CSS variablesのようなadvanced CSS
- HTML form controls
- AccessKitベースのアクセシビリティ
- custom widgetsによる拡張性
- BlitzはWebRTC、WebSockets、Bluetooth、localStorageのような機能を提供しない
- ネイティブアプリでは、これらの機能の多くを一般的なRust crateで処理できる
- こうした機能をレンダラーと結合する必要はないという立場を取っている
- JavaScript、Pythonなど他言語バインディングはまだ存在しないが、関連する貢献は歓迎される
実行方法と例
- リポジトリをクローンした後、
browserパッケージを実行できる
cargo run --release --package browser
- 例として、小さなTODOアプリ、Markdownレンダラー、raw WGPUレンダリング統合が提供されている
cargo run --release --package todomvc
cargo run --release --package readme ./README.md
cargo run --release --package wgpu_texture
モジュール型アーキテクチャ
- Blitzはcore DOM abstraction、追加機能モジュール、2つの上位ラッパーで構成される
- ネットワーキング、レンダリング、ウィンドウ、状態管理のような機能は個別のモジュールに分かれている
- これらの部品を組み合わせて1つのWebエンジンを構築できる
-
上位ラッパーcrate
blitz: HTML文字列をレンダリングできるHTML/Markdown frontend- HTMLまたはMarkdownファイルのプレビューに便利
- 現時点ではインタラクションはない
blitz-dom、blitz-html、blitz-shell、blitz-renderer-velloを使用するdioxus-native: Dioxus VirtualDomをレンダリングするDioxus frontend- Dioxusのイベント処理を通じて完全なインタラクションをサポートする
blitz-dom、dioxus-core、blitz-shell、blitz-renderer-velloを使用する- 両ラッパーとも、下位リソースを取得するために
blitz-netをオプションで使用できる
-
コアcrateと追加crate
blitz-dom: style resolution、layout、event handlingを含むcore DOM abstraction- parsing、rendering、system integrationは含まない
- Stylo、Taffy、Parleyを使用する
blitz-traits: 他のcrate同士が直接依存せずに相互運用できるようにする最小基盤crateblitz-net: HTTP、ファイルシステム、encoded data URIからリソースを取得するネットワーキングモジュール- reqwestを使用する
blitz-paint: blitz-domツリーをanyrender draw commandsに変換する- anyrenderを使用する
blitz-html: blitz-domにHTML parsingを追加する- html5everとxml5everを使用する
blitz-shell: Blitzがウィンドウにレンダリングできるようにするshell- Winit event loop、AccessKit、Mudaなどを統合する
- winit、accesskit、mudaを使用する
- AnyRenderレンダリング抽象化は別リポジトリのanyrenderへ移された
Dioxus Native開発版の利用
- 最新の開発版Dioxus Nativeはこのリポジトリにある
- Dioxus Nativeは急速に開発が進んでいるため、正式リリースより先に最新機能やバグ修正を使いたい場合はgit版を利用できる
- git版の利用手順は次のとおり
dioxus crate依存を完全に削除するdioxus-native = { git = "https://github.com/DioxusLabs/blitz";, rev = "e64a3d8", features = ["prelude"] }を追加するe64a3d8は使用したいバージョンのgit commit idに置き換える- Rustコード内で
use dioxus::prelude::*をuse dioxus_native::prelude::*に変更する
- Dioxus Native preludeがエクスポートしない
dioxus機能が必要な場合は、dioxus-html、dioxus-signals、dioxus-routerなど個別のsub-crateからimportする
- Dioxus Nativeのgit版は、crates.ioの安定版Dioxus v0.7.xに引き続き依存している
dioxus-sdk、dioxus-components、dioxus-free-iconsのような追加ライブラリはそのまま動作するはず
バージョンとライセンス
- このリポジトリには**Blitz v0.2+**の新バージョンが含まれており、Styloを使用する
- 以前のバージョンであるv0.1のソースはlegacyブランチに残っている
- プロジェクトはApache 2.0とMITのデュアルライセンスで配布される
stylo_taffy crateには、Servoプロジェクトとの相互運用を容易にするため、追加でMPL 2.0も適用される
- したがって
stylo_taffyはApache 2.0、MIT、MPL 2.0のトリプルライセンスとなる
- Blitzに意図的に提出された貢献は、別条件がない限りApache 2.0とMITのデュアルライセンスとして扱われる
stylo_taffyに提出した貢献にはMPL 2.0も含まれる
1件のコメント
Hacker News の意見
Blitz のリード開発者です。まだ完成段階ではなく、テキスト入力／フォーカスシステムは基本的なものにとどまり、ルートビューポート以外のスクロールには対応していません
nth-child、:hasのような複雑な CSS セレクタはまだ正しく動作せず、Blitz の上で動く React 風フレームワークである Dioxus とのイベント処理統合もクリックだけが機能する程度で、preventDefaultもありません ネットワーキングは現状非常に単純で、メインスレッドで同期リクエストを行っており、きちんとした非同期またはマルチスレッドのネットワーキングが必要です パフォーマンス対応もほとんどしていないため、毎フレームごとにスタイル／レイアウト／ペイントを再計算しており、クリーンアップされないノードによるメモリリークもいくつかあります シャドウ、Web フォント、calc、フロートレイアウト、テキスト入力以外のフォームコントロールもまだ欠けています。要するに「WebView を作るのは大仕事で、まだそこまでは到達していない」に近く、2〜3か月以内にもう少し完成度の高い形になることを期待しています スクリーンショットはこちらにもあります: https://github.com/DioxusLabs/blitz/issues/23このプロジェクトは一見しただけでも非常に有用に見えます 広く使われているHTML/CSS レイアウトのパラダイムでネイティブアプリを作りつつ、完全な JS/DOM/ブラウザ API が示唆する重い部分は取り除くという方式です。Electron のようにブラウザエンジンをパッケージするより、はるかに大きな改善を可能にしそうです ちょうど最近、Richard Feldman のポッドキャストで Casey Muratori が CSS を非常に批判的に語っているのを聞きました。単純なレイアウト関係を作るために Web ページを事前にレンダリングし、動的に測定しなければならなかったという事例が特に印象に残りました Muratori の言うように、CSS を書くことは単純な基本要素の上に積み上げるというより、法廷で事件を弁論する感覚に近いです もちろん、慣れ、互換性、そして「うまくいく範囲の CSS」が非常に生産的であることから、こうしたプロジェクトが満たす需要は大きいです。ただ、ユーザーが下の層に降りて使える、より単純で一般的なレイヤーを提供する機会もありそうです CSS を JS API で拡張可能にしようとする CSS Houdini から着想を得ることもできるでしょうし、もしかするとこれが「Custom Widgets」の意味するところなのかもしれません
floatを除くだけでもよいはずです数年前、いや20年前に Flying Saucer という似たようなオープンソースプロジェクトを作りました。純粋な Java ベースの HTML + CSS2 レンダラーでした ゲームでリッチなテキスト UI をレンダリングするのに使われると想像していましたが、実際の主な用途はサーバーサイドの PDF 生成でした。当時提供されていたさまざまな PDF レポート生成 API を使うより、HTML を生成して PDF にレンダリングするほうがずっと簡単でした Blitz は素晴らしく見えますし、Rust の GUI ライブラリが増えることを楽しみにしています https://en.wikipedia.org/wiki/Flying_Saucer_(library) 驚くことに、今もまだ更新されています: https://github.com/flyingsaucerproject/flyingsaucer/releases...
「JavaScript エンジンをネイティブ Rust API に置き換えた軽量 WebView」とは有望に見える。基本的に JS が経路上にない Tauri のようなものなら、聞くだけで良さそう
興味深い。ちょうど今日、puppeteer とヘッドレス Chromium でひどい目に遭い、wkhtmltopdf の代替を探していた
LD_PRELOADに jemalloc を入れて実行するのは絶対にやってはいけない。問題は解決したが、もっと単純なレンダラーのほうが好みだったBlitz 自体の話ではないが、Dioxus を初めて知った WASM にコンパイルされるフレームワークには、デモをきちんと見せない、または自分のサイトをそのフレームワークで直接ホストしないという 暗黙のルール でもあるのか気になる。こういうのを 5〜6 回は見た気がする Dioxus のホームページで WASM ファイルがロードされるのは見えるが、どこで使われているのか、あるいは実際に使われているのかは明確ではない
バックエンドと htmx を一緒に使うと面白そう。ただ JS エンジンがまったく混ざらないようなので、どうできるのか気になる
とだけが HTTP リクエストを送れるべきなのか、なぜクリックと送信イベントだけがリクエストをトリガーすべきなのか、なぜ GET と POST だけが可能なのか、なぜ画面全体だけしか差し替えられないのか 別の見方をすると、HTMX は HTML 要素をより制約が少なく、より汎用的にする。Web レンダラーが設計時にこれを考慮すれば、むしろより単純になる可能性もあるDioxus を今日初めて知った https://dioxuslabs.com/
本当に素晴らしい。C++ プロジェクトで使ってみたい ひとつ浮かんだ疑問は 性能 だ。比較的複雑なページを高いフレームレートでレンダリングできるのか気になる 普段は ImGUI を使っているが、リアルタイムデータを表示するときに性能問題をほとんど気にしなくていいほど優れている。一方 Chromium の Web レンダリングは、単純な DOM テキスト更新を毎秒 10 フレームで行うだけでも CPU を燃やしてしまうので、これが解決されればゲームチェンジャーになり得る