HNに表示: Vaev – ゼロから構築されたブラウザエンジン（google.comをレンダリングします）

372日前原文(github.com)

概要

Veavは 実験的なWebブラウザエンジン で、主要なWeb標準の一部をサポート。
HTML/XHTML、CSSカスケード、@page規則、PDF印刷 などに対応。
calc()、var()、パーセンテージ単位 を含む全CSS単位を処理可能。
ネットワークはhttp://とfile://のみ 対応し、グリッドレイアウトは未対応。
開発・学習目的 のプロジェクトであり、フィードバックを歓迎。

Veav：実験的Webブラウザエンジンの特徴と利用方法

主な機能と対応標準

多くのディスプレイタイプ をサポート（ただしgridは未対応） → 表示対応範囲の確認
標準CSSカスケード動作 を実装 → スタイル継承・上書き挙動の再現
@page規則によるページ分割 をサポート → ページネーションの実現
PDFへの印刷出力 が可能 → 印刷・保存機能の提供
calc()、var()、パーセンテージを含む全CSS単位 に対応 → 柔軟なレイアウト指定
HTMLおよびXHTMLドキュメントの読み込み が可能 → ドキュメント互換性の確保
基本的なネットワーク機能 （http://、file://のみ）を搭載 → 通信手段の限定

詳細な互換性・進捗状況

WPT statusページ で互換性と機能の進捗状況を確認 → 機能追跡・互換性確認

Veavの試用方法

以下のコマンドでインストール・実行 が可能 → 環境構築・体験
- pacman -S base-devel git ninja sdl2 nasm gcc-multilib liburing clang libseccomp
- yay -S clang-prefixed-release
- git clone https://github.com/skift-org/vaev.git
- cd vaev
- pip install git+https://github.com/cute-engineering/cutekit
- python -m ck run --release vaev-browser -- file.html

アーキテクチャ

アーキテクチャ図 は本ファイル横にtldraw形式で配置 → 全体構造の把握

著者

Lou !
LuneMercier
Paulo Medeiros
Sleepy Monax → 開発メンバーの確認

Vaev開発の目的と現状

Vaevは学習・実験を目的とした最小限のWebブラウザエンジン → 教育・研究用途
HTML/XHTML、CSSカスケード、@page規則、PDF印刷 に対応 → 基本機能の実装
calc()、var()、パーセンテージ単位 を含むCSS機能をサポート → 柔軟なスタイリング
Google.comの表示も（ほぼ）可能 → 実用レベルの互換性
ネットワークはhttp://とfile://のみ、グリッドレイアウト未対応 → 制限事項の明確化
急速に開発が進行中 → 進捗状況の把握
意見・フィードバックを歓迎 → コミュニティ参加の提案

Hackerたちの意見

このプロジェクトの長期的な目標は学ぶこと以外に何があるの？現代のウェブをサポートするブラウザを作るのは、個人的にはすごく大変な仕事だと思う。

└

主な目標は、静的ドキュメントのレンダリングをしっかりサポートすることだよ。これは、odooのwkhtmltopdfを置き換えるために使われるpaper-muncher [1] PDFレンダリングエンジンのコアで使われているんだ。でも、将来的には一般的なウェブブラウジングやJavaScriptのサポートも考えてるよ。 [1] https://github.com/odoo/paper-muncher

└

skiftは、Ladybirdが派生したSerenity OSみたいな趣味のOSっぽいね。同じ道を進むつもりなのかな？

新しいミニマリストブラウザが出るたびにこれをリクエストしちゃうんだよね：代替ブラウザを一貫したウェブ標準のサブセットで標準化して、ドキュメント化できたらいいなと思う。そうすれば「smolweb」愛好者たちがそれをターゲットにしてウェブサイトを作れるし、代替ブラウザの開発者たちも無駄に広い範囲を考えずに役立つものを目指せる。個人的には、Geminiみたいな新しいプロトコルよりもこのアプローチが好き。人気のあるブラウザとの後方互換性を保ちながら、オフランプを提供できるからね。

└

小規模なウェブ出版にはすごくいいと思うけど、ブラウザの標準のサブセットにするのは、ブラウザを作ってる人たちには難しい提案かもしれないね。そんなに膨大な仕様のサブセットを作るのは簡単だけど、そのサブセットは決まった後すぐに「似てるけど少し互換性がない標準」に流れていくと思う。Ladybirdの開発を追ってると、ウェブの「仕様」がどれだけ頻繁に変わるかがわかるよ。（小さな変化が、毎日。）それが新しいブラウザの実装を分岐した標準の道に固定しちゃうから、そこから抜け出すのはすごく難しい。参考実装（Ladybird、Servo、もしくはVaevみたいなもの）が小さなウェブの生きた標準として採用されるのが一番の賭けだと思う。それならブラウザプロジェクトも大きなウェブでの作業のために大きな資金を得られるしね。「Ladybird/Vaev/etcで見栄えが良くないとダメだよ」。アイデアとしては、Ladybirdのlibwebを使ったウェブオーサリングツール！(もしくは簡単に埋め込める他の新しいウェブ実装) そのスロットに入るものの暗黙の標準性は、自然に得られると思うよ。（十分な人が使っていればね！）

└

サブセットは、例えばHTML 4.01やCSS 2.1みたいな古いバージョンの仕様でもいいかもね。（自分のブラウザエンジンをゆっくり作っている者としての意見。）

└

BSなしのAMPってこと？

└

代替ブラウザを一貫したウェブ標準のサブセットで標準化して、ドキュメント化することで「smolweb」愛好者たちがそれをターゲットにできるようにそんな標準は、メールで許可されているHTML/CSSのサブセットに基づくことができるかな？インタラクティブ性のためにいくつかの追加要素を加えて。

└

この場合、新しい標準を作る方がいいと思う。HTML/CSSにはレガシーなものや癖がたくさんあって、取り除いた方がいいものが多いから（例えば、タグとか、テーブルセルがフォントサイズを継承しないとか）。

└

私も同じことを望んでいて、ずっとそれを求めてきたよ。あるいは、一貫したウェブ標準のサブセットにコンパイルできる新しい標準があればいいな。

└

これには賛成だよ。何年もかけて追加されてきた癖やエッジケースがない、完全にシンプルなHTMLのバージョン + Javascriptが欲しいね。

それはちょっと脱線だけど、毎回この問題が出るたびに、Android WebViewを独立したクロスプラットフォームプロジェクトにしてしまうアイデアが頭に浮かぶんだ。誰かもうやってるか確認しようと思ってるんだけど。

└

それってどういう意味？WebViewはAndroidアプリ内に埋め込まれたChromeに過ぎないよ。同じようなものはWindows（Edge WebView2）、macOS（WKWebView）、Linux（WebKitGTK）にもあるし、全部を一つのインターフェースにまとめたライブラリもあるよ：https://github.com/webview/webview WebViewの本質は、別のアプリケーション内に埋め込まれたブラウザなんだから、「独立したプロジェクト」になるなんてどういうこと？

└

Google自体が、あなたが考えている方向に少しだけ進んでいるんだよね、Cobaltという形でね。これはChromiumの簡易版で、特定の「クセ」があって、長時間動作するアプリケーションでのメモリの割り当てや膨張を最小限に抑えているんだ。GoogleはこれをYouTube TVの運営に使ってる。残念ながら、しばらく前にLinuxのX11バイナリをダウンロードしたはずなんだけど、もう見つからないんだよね。リリースパッケージには共有ライブラリしか入ってなくて、レジストリのコンテナにはコンパイラツールチェーンがいっぱい（ncduをインストールして確認したよ）。全体のシステムはハードウェア統合のフラフが重なり合っていて（Cobaltはセットトップボックスに組み込むためのものだから）、バッテリー付きのデモがほとんどないんだ。これは、Cobaltが特定のCSSルールに従っていないからで、JSサポートがどこまで進んでいるのかもよくわからない。 https://developers.google.com/youtube/cobalt コンパイルのドキュメントはChromiumのと同じくらい難解だね -.- https://developers.google.com/youtube/cobalt/docs/developmen...

なんでC++が選ばれたのか興味あるな。ブラウザはセキュリティが難しいことで有名だし、実際にRCEの脆弱性を持つように設計されてるからね！C++のバイナリを安全にするのは難しくて、最近では多くの組織や企業がそれが多くのセキュリティ脆弱性の根本原因だって指摘してる。Rustみたいな言語がある今、もっといい選択肢があるよね。

└

同じこと考えてた。プロジェクトの説明：>セキュアなHTML/CSSエンジンこれらの人たちに悪気はないけど、ファジングの証拠が見当たらないから、コードベースに悪用可能なバグがないとは信じがたいよ。Googleには世界最高のブラウザ開発者とツールがいるのに、やっぱり悪用可能なバグを書いちゃうんだよね :p （AppleやMozillaには世界最高のブラウザ開発者がいるけど、ツールについてはあまり知らない。Microsoftは意図的に省略したけど）そう、レンダラーにはそういうバグはほとんどないけど、やっぱり起こるんだよね！

└

[フラグが立てられました]

└

その通りだね。ブラウザが少ない理由は、誰もRustで作ってないからだよ。

└

すでにRustのウェブエンジンがあって、それはServoって呼ばれてるんだけど、今はC++のLadybirdプロジェクトに追い抜かれそうなんだ。ブラウザをオープンソースで書くにはRustはあまり良い言語じゃない。なぜなら、ブラウザを作る上で最も難しい問題はセキュリティではなく、どれだけ多くの人を説得して働いてもらえるかだから。C++プログラマーはたくさんいるし、毎日8時間C++を書く人が大勢いるんだ。Rustコミュニティは、私のようなちょっとした興味を持っている人たちが多い。

└

なんでC++が選ばれたのか興味がある？多くのプロジェクトでC++が選ばれるのと同じ理由だよ。おそらく著者たちはC++に豊富な経験があるんだ。非常に複雑で大規模なプロジェクトには、自分が非常に熟練している言語を選ぶのが本当に重要なんだ。何年も何年も経験があるレベルでね。Rustに経験がないなら、それは持っていないってことだし、ここで考慮できるのはRustだけなんだ。SwiftやC#などは、エンジンを書くにはちょっと高レベルすぎる。少なくとも、使いやすさの面ではね。ソースコードをざっと見たけど、非常に高品質なコードだよ。良いC++を書くのは難しいし、ほとんどの他の言語よりも難しい。モダンで、一貫性があって、読みやすく、型もよく定義されている。

└

確かに、Rustはブラウザを書くにはあまり向いてないと思う。HTML/DOMが必要とするパターンはRustが標準でサポートしてないし、いろんなところにポインタが必要になるからね。確かアンドレアス・クリング（レディバードの開発者）が、Swiftの方がRustよりもこの仕事に適しているか、少なくともチームがいくつかの言語を評価した後は作業がしやすいって言ってた気がする。

このC++コードはめっちゃモダンだね。すごい！GitHubのウェブインターフェースだけではGc::Refの定義が見つけられなかったんだけど、どこで見つけられる？

└

おそらくこれだよ - https://github.com/skift-org/karm/blob/main/src/libs/karm-gc... これは従来の意味でのガーベジコレクタではなく、スマートポインタを使ったアリーナみたいなものだね。

└

ソースコードを読んでいて同じように感じたよ。伝統的なC++と、いくつかのプロジェクトが最新のC++20の機能を使っている興味深いミックスだね。GC::Refはkarm-gcライブラリから来ているみたい。（コパイロットによると）

ハハ！ほんの数日前に、ブラウザは新しいマウスだって主張してたんだ。つまり、一人の人間がコンピューターマウスを作ることはできないってこと。金属、プラスチック、トランジスタ、レーザーなどの専門家が必要なんだよね（セス・ゴーディン？）。同じように、どんな接続デバイスにも通じるウェブブラウザを作るには、無数の分野の専門家が必要なんだ。だから、ここまで作り上げたのは素晴らしいことだよ。さて、帽子を食べる前にWebGLが動くか見てみよう。

└

このプロジェクトには4人が関わっているんだよ、1人じゃない。

あと、https://sciter.com/ もあって、著者はそれをオープンソースにするための資金を探してたけど、十分なサポーターを見つけられなかったみたい。

└

これはブラウザじゃないよ。

よくやった、これは本当にクールだね。もっとモダンなC++が使われているのを見るのはいいことだ。コードベースは本当に読みやすくて理解しやすい。ここにいる人たちは、Rustじゃないってことを乗り越えないといけないね。私は自分のプロジェクトにC++を使っているけど、C++で書くのが楽しいからなんだ。もしRustや他の何かを使うことを強いられたら、書かないと思う。

これめっちゃクールだね！ブラウザエンジンをゼロから作るのは簡単じゃないし、calc()やvar()、パーセンテージ単位みたいな複雑なCSS機能を扱うのは特に大変だよね。ウェブの内部動作を学ぶには最高の方法だと思う。ネットワークスタックへのアプローチが気になるんだけど、将来的にHTTPSやWebSocketみたいなもっと多くのプロトコルをサポートする予定なの？それとも、今は軽量でミニマルな状態を保つことに重点を置いてるのかな？

Vaevチームが自由な技術探求を推進していることに拍手！C++の選択は大胆だね。よく言われるセキュリティの懸念があるけど、モダンC++はスマートポインタやRAIIパターンを使えば、正しくやればRustと同じくらい安全になり得るよ。Vaevのセキュリティモデルはプロセスの分離やサンドボックス技術、モダンC++の機能を活用して脆弱性を最小限に抑えることに焦点を当てるべきだね。こういう生の革新と、クロミウムみたいな巨大企業が独占するような大きな課題に挑む勇気を見るのがすごく楽しみだよ。

└

... ありがとう、LLM、あなたの意見に感謝！

ハクソク