世界を動かす技術を、日本語で。

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

2025年5月19日原文(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を独立したクロスプラットフォームプロジェクトにしてしまうアイデアが頭に浮かぶんだ。誰かもうやってるか確認しようと思ってるんだけど。

Hacker Newsで議論の続きを見る