Vaev 爆誕！ゼロから構築されたブラウザエンジンがgoogle.comのレンダリングに成功
引用元：https://news.ycombinator.com/item?id=44023144
よくやったね、これマジクールだよ。モダンなC++が使われてるの見るのいいね。コードベースも読みやすくて分かりやすいわ。みんな Rust じゃないって事実を受け入れるべきだよ。俺は自分のプロジェクトで C++ 使うの好きだから使ってる。無理して Rust とか使わされたら書かないもん。
この C++ コードめっちゃモダンだね。超感心した。 GitHub のウェブインターフェースだけだと、 Gc::Ref の定義が見つけられなかったんだ。どこで見れるの？
多分これじゃないかな - https://github.com/skift-org/karm/blob/main/src/libs/karm-gc…
で、これ伝統的なガーベージコレクターじゃなくて、アリーナにスマートポインター合わせた感じかな。
これただのプレースホルダー実装だよ、そのうちちゃんと GC やるから。
俺もソースコード読んでて同じこと思ったよ - 伝統的な c++ と、最新の c++20 features 使ってるプロジェクトとの面白い組み合わせだね。 Gc::Ref は karm-gc ライブラリから来てるみたい。（ copilot によると）
これマジすごいね！ゼロからブラウザエンジン作るなんてマジで大変な偉業だよ、特に calc()、 var()、 percentage units みたいな複雑な CSS 機能扱うのとかさ。ウェブの内部の動き学ぶのに最高だね。
ネットワーキングスタックのアプローチに興味あるんだ。将来的には HTTPS とか WebSockets みたいなもっと多くのプロトコルサポートする予定なの、それとも今は軽量でミニマルにフォーカスする感じ？
学習以外で、このプロジェクトの長期的な目標って何？モダンウェブをサポートするブラウザ作るのって、俺的にはマジで途方もない仕事だと思うけど。
主な目標は静的ドキュメントのレンダリングをしっかりサポートすることだよ。 odoo で wkhtmltopdf を置き換えるための paper-muncher [1] PDF レンダリングエンジンのコアで使われてるからね。でも、いつか一般的なウェブブラウジングや JavaScript サポートも排除しないよ。
[1] https://github.com/odoo/paper-muncher
おお、過去の経験が蘇るね！前の会社で wkhtmltopdf から nodejs ( phantomjs / puppeteer ) に移行したんだ。 chrome の起動コストを避けるため、ページコンテキストを開きっぱなしにして、 Linux pipe 経由で html を渡すテクニックを使って高速化したんだよ。 WK よりマジで速かった（〜20ms）！
そうだよ！そのアイデアを思いついた午後のこと覚えてるよ。Beer Fridayで、ほんの数時間でPDFを数百ミリ秒でレンダリングする基本的なプロトタイプを書いたんだ。100倍の速度改善を初めてやった時で、すごく興奮したな。
おめでとう！このやり方って、ブラウザエンジンをゼロから書くよりずっと理にかなってると思わない？
何をレンダリングするかによるかな。うちは自分たちで作ったHTMLで楽だったけど、任意ユーザーのHTMLは大変そう。印刷レンダリングは当時も今も扱いにくいし、色の調整、SVGs、ページ割りが難しいんだ。ちゃんとやるのが大変だったよ。
セキュリティもリスク大だよ。ページ内でコード実行されたら、生成されるPDF覗き見されるかもね。
職場で最近、WkhtmltopdfからTypstに切り替えたんだけど、すごく快適になったよ。HTMLやブラウザエンジンを使わずPDFをゼロから生成するからめっちゃ速いんだ。Rust実装で自己完結バイナリだよ。
このブログで切り替えの価値を確信したな：https://zerodha.tech/blog/1-5-million-pdfs-in-25-minutes/
へえ、面白いね。彼らの”old stack”は小規模PJで問題なく動くけど、一つのファイル形式変換にChrome instance丸ごと立ち上げるのは、ちょっとばかげてる気もするね。
私もTypst大好きでよく使ってるよ。でも、これも念のためだけど：weasyprint.orgってのもあって、HTMLを入力として取るんだ。
ページのマージンボックスはサポートしてる？
うん、してるよ！
skiftはSerenity OSみたいにホビーOSっぽいね。Ladybirdはそこから派生？同じ道をたどるのかな？
SkiftとVaevはクロスプラットフォームだからずっと一緒にやるつもりだよ。構成上、変える理由になる対立もないね。
ハハ！数日前、ブラウザは新しいマウスだって言ってたんだ。マウスみたいに、metalとかplasticとかtransistorsとかlasersとか、色んな分野の専門家が必要なんだ。Gatewayとなるウェブブラウザも同じ。ここまで作ったのはすごいね！さあ、hatを食べる前にwebglが動くか見てみようかな。
このプロジェクトは一人じゃなくて、四人でやってるよ。
ミニマリストなブラウザが出るたびに、これ言いたくなるんだ。代替ブラウザでWeb標準の一貫したサブセットを標準化してドキュメント化できたら、”smolweb”好きの人がサイト作る時にそれをターゲットにできるし、代替ブラウザ作る人も全部実装しなくて済む。”Gemini”みたいな新しいプロトコルより、既存ブラウザとの後方互換性があるこのやり方が好きだな。
そのサブセットは、例えばHTML 4.01とかCSS 2.1みたいな古いバージョンの仕様でいいかもね。（これもブラウザエンジンをちまちま作ってる一人の意見だよ）
Web標準のサブセット化だけど、メールで使えるHTML/CSSのサブセットをベースにできるかな？インタラクティブな要素を少し足してさ。
知る限り、”email HTML”も標準化されてないんだよね。見栄えのいいHTMLメール作る組織は、色々なクライアントでテストして、全部同じに見えるように回避策をたくさん考えなきゃいけないんだ。
インタラクティブな要素を少しって… JavaScriptとか？
TableじゃなくてCSS Gridみたいな新しい標準の方がいいやり方だと思うな。HTML/CSSの改善の多くは単なる肥大化じゃなくて、実際により良い土台となる標準なんだよ。
email HTMLって標準化できるのかな？
Apple、Google、Microsoftに自分の標準を実装するよう説得できたら、そりゃすごいね。いろんな試みがあったけど、成功はいろいろだったよ。でも、その標準はWindowsのOutlookでもレンダリングできる必要があって、つまりヘンテコなOffice版のIE11を上限としてサポートしなきゃいけないんだよね。
小規模Web出版にはいいかもね。でも既存のブラウザ標準のサブセットにするのは難しいと思う。Webの仕様は毎日変わるから、新しい実装はすぐに互換性のない独自路線になっちゃう。Ladybird、Servo、Vaevみたいな参照実装が小規模Webの標準になるのが一番じゃないかな。そうすれば、ブラウザプロジェクトも大規模Web対応で資金を得られるしね。Ladybirdのlibwebを使ったWebオーサリングツールとかどうかな？それが標準になる可能性もあるしね。
もっとコメントを表示（1）
”Outlook (New)”はReact NativeとChromium webviewで動いてるよ。Outlook Mobileからの移行は進んだけど、Outlook (Classic)（法人向け）からの移行は、古いWordベースのIEを使い続けてて滞ってるみたい。Outlook MobileはIE11よりマシでChromiumになってるよ。
アクセシビリティに特化した標準サブセットはどうかな。不要な機能はアクセシビリティの悪夢だしね。政府が標準化して、複雑なHTMLサイトを取り締まるのに使えるかも。Webアプリは進歩だけど、動的なHTMLは悪夢。昔ながらのフォームは使いやすかったね。
（補足：昔jsフレームワークやSPAを書いてたよ。）
アクセシビリティの観点から：CSSでテーブルデータを表現するのをやめてください。それは俺のスクリーンリーダーには変換されません。
みんなもうCSSでflexboxないと嫌なんだってさ。必須になっちゃったね。
HTML/CSSは古い遺産や変な癖がいっぱいあるから（例えば＜hr＞タグとか、tableセルがフォントサイズ継承しないとか）、新しい標準作っちゃった方がいいかもね。
サイトってよく基本的なとこ間違えるんだよね。motherfuckingwebsite.comにあるタグ（＜p＞, ＜a＞, ＜h*＞, ＜img＞, ＜ruby＞みたいな）だけサポートして、他はwebcompat/fixbrowserみたいに対応したらいいんじゃない。
なんかDOM levelsみたいだね。結局みんな”Living Standard”って言って諦めちゃったけど。こういうのって今でも必要だと思うけど、仕様のバージョンに依存するのは昔のDOM levelsの失敗繰り返しそうで心配だな。
仕様としては簡単に決められるけど、余分な機能とか使われてないのがいっぱいあるんだよね。もっとスリムで今どきのセットの方が使えると思うな。
標準を作ることはできるよ。それが実際に広く使われたり、正式な標準になるかは全く別の話だけどね。
small-web Living Standardって言葉、”Living Standard”自体が矛盾語だよ。既得権益者が標準を支持してるフリして、絶え間ない変化を武器に自分たちの立場を守るために作った言葉だ。
“メールHTML”がまだHTML 2.5くらいで止まってて、限られたCSSサポートとFONTタグやTABLEレイアウトだらけなのが面白いね。smolwebでHTML 2みたいな古いサブセットに”集中”するのも面白いけど、超レトロで今っぽくないだろうね。今から始めるなら最新から始めて後方互換性に対応する方が面白いかも。HTML 2のTABLEとかCSS Gridの特殊化として実装するとかね。
そうそう！変なフォントとかカーソルとかはsmolwebにいらないけど、FlexとGridはほぼ必須だよ。捨てるべきものはいっぱいある気がする。こういうブラウザのどれかがちゃんとしたComboBox（テキスト入力できて検索もできてドロップダウンも出るやつ）を実装してくれたらいいんだけどね。
そうそう、グリッドってUIのいろんなとこにあるんだよね、テーブルだけじゃなくて。2000年代は今と逆で、他に配置方法がなかったからインターフェース全部がテーブルだらけだったんだよ。でも今はいいとこ取り！実際のテーブルには＜table＞使って、UIレイアウトにはCSS gridを使おうぜ。
うーん、それ悪くないかもね！CSS全部禁止して、マークアップタグだけ残すとか：Markdownとテーブルでできることだけとか。色も小さい文字も画像もなし。（HTMLじゃなくgemtextみたいな形式でもいいけど、クライアントの互換性ないな。）でも、これそこそこ使われてるメールクライアントが採用するわけないか :-(
なんでC＋＋がこれに選ばれたのか気になるんだよね。ブラウザってセキュリティ確保マジで難しくて、実質RCEの脆弱性の塊みたいなもんだし！C＋＋のバイナリ安全にするのは大変だし、最近色んなとこがセキュリティ脆弱性の根本原因って言ってるじゃん。Rustみたいな言語使えば、もっといい選択肢あるのにさ。
＞なんでC＋＋がこれに選ばれたのか気になるんだな。
他の多くのプロジェクトと同じで、たぶん作者がC＋＋にめっちゃ詳しいからだよ。マジでデカいプロジェクトは熟練した言語が良いんだ。Rustくらいしか候補ないけど、SwiftとかC＃はエンジン書くにはちょい高レベルかな。
コード見たけど、質めっちゃ高かったわ。良いC＋＋書くの難しいけど、ここのはモダンで読みやすいし型もちゃんとしてる。
もうRustのウェブエンジンならあるよ、Servoっていうの。今C＋＋のLadybirdプロジェクトに追い抜かれそうだけど。
Rustはオープンソースのブラウザ書くには向いてない言語だと思うわ。ブラウザ開発で一番大変なのはセキュリティじゃなくて、手伝ってくれる人集めることだからさ。
C＋＋プログラマーなんてゴロゴロいるじゃん。毎日8時間C＋＋書いてる人なんていっぱいいる。Rustのコミュニティは俺みたいな素人がほとんどだよ。
でもLadybirdってC＋＋からSwiftに乗り換えるんじゃないの？
俺の理解だと、C＋＋捨てるんじゃなくて、新しいSwiftのC＋＋連携機能使ってエンジンの一部をSwiftで書いてみようって検討してるだけだよ。全部Swiftに乗り換えるのは現実的じゃないみたい。
Andreasがどっかのインタビューでそんなこと言ってたのは覚えてるけど、リポジトリ［０］見るとそうは見えないな。
C＋＋ ６４．６％
HTML ２２．４％
JavaScript １１．０％
CMake ０．７％
Objective-C＋＋ ０．５％
Swift ０．３％
Other ０．５％
［０］ https://github.com/LadybirdBrowser/ladybird
俺だけかもしれないけど、10年以上毎日8時間 C++ やってたら、タダじゃ二度と触りたくないくらい疲れたよ。
”＞”現在は C++ の Ladybird プロジェクトに追い抜かれつつある”って書いてあるけどさ。今日日ほとんどのウェブで使える成熟したエンジンが、まだリリースされてないプリアルファのソフトに”追い抜かれつつある”って言うのは、”追い抜く”の定義が変じゃない？
Ladybird は数ヶ月前に WPT で Servo を追い抜いて、その差は広がる一方だよ。Servo は Ladybird の開発ペースに追いつけないし、Ladybird が持ってる C++ 開発者の巨大なプールが全てだよ、その理由は。
俺が知ってる限りだと、Rust はブラウザ開発にはそんなに良い言語じゃないんだよね。HTML/DOM が必要とするパターンは Rust がそのままサポートしてるわけじゃなくて、あちこちポインタが必要になるから。確か Andreas Kling （Ladybird の開発者）もそんなこと言ってた気がする。チームが Rust 含むいくつかの言語を評価した結果、Swift の方がこの仕事には向いてるか、少なくとも開発しやすいって言ってたよ。
俺も同じこと思ったよ。プロジェクトの説明に”安全な HTML/CSS エンジン”ってあるけど、ファジングやった証拠が見当たらないからバグがないって信じるのは難しいな。Google みたいに世界クラスの開発者でも悪用可能なバグ書いてるんだから。まあ、そういうバグの大部分はレンダラーにはないんだけど、起こることは起こるんだよ！
ちなみに俺は Rust 書かないし、だから「～に限らず」って言ったんだよ。Swift や Zig なんかも選択肢だし、遅くても安全なブラウザの方がいい。多分セキュリティ荒らしみたいに聞こえるかもだけど、こういうものを C++ で書くのは過去30年以上見ても事実上不可能だってわかってる。セキュリティはブラウザにとって一番大事なのにね。もっと貢献者が集めやすいとか、趣味だからとかが理由ならわかるけど、作者が俺とは違う考え方をしてるなら学びたいと思ったんだ。
俺は確信してるんだけど、今の”セキュリティ”への過剰な心配って、単なる冷やかし（concern-trolling）だよ。もっと権威主義的で企業が管理してる言語とか環境に人々を押しやろうとしてるだけだって。
そうだよね、急にみんな何も知らないセキュリティについて気にするようになったみたいだ。もし本当に気にしてたなら、 Rust の前から気にしてたはずだよ、ほら、 Ada とか SPARK を書いてさ。
セキュリティがしっかりしたブラウザがあんまりないのは、みんな C++ で作ってるからだよ。ちょっと違うやり方とか、セキュリティへのアプローチの多様性が欲しいだけなんだ。
それって達成可能だと思う？
君みたいな人なら、タスクを十分に小さく分割して、 Rust の初心者グループにそれぞれのピースをコードしてもらったりできるかな？
もっとコメントを表示（2）
話が脱線するけど、こういう問題が出るたびに、 Android WebView を独立したクロスプラットフォームプロジェクトとして切り出すってアイデアが頭に浮かぶんだ。誰かもう実際にやってないか、いつもチェックしようと思ってるんだけど。
Google 自身も、 Cobalt という形で似た方向に行ってるよ。これは Chromium を軽量化して、 YouTube TV などに使われている。長時間アプリでのメモリ効率が良いけど、セットトップボックス向けでハードウェア統合が複雑。簡単に試せるバイナリやデモはほぼなく、ドキュメントも Chromium 並みに難解だよ。
どういう意味？ WebView は単に Android アプリの中に埋め込まれた Chrome だよ。同じようなのは Windows ( Edge WebView2 ) や macOS ( WKWebView ) 、 Linux ( WebKitGTK ) にもある。これらを一つのインターフェースにまとめるライブラリもあるよ： https://github.com/webview/webview
WebView の全体的な目的は、別のアプリの中に埋め込まれるブラウザだってことだよ。それがどうやって「独立したプロジェクト」になることを期待してるの？
アイデアとしては、軽量（つまり数メガバイトのライブラリだけ）で、 android webview と同じ機能（つまり、読み込む HTML を送って JavaScript を実行し、結果を JSON で受け取る）を提供することだよ。似たようなことをやろうとしてるオプションはいくつかあるのは知ってる。でも、ネイティブアプリの UI に html5 を使いたいだけなのに、それらがどれも信じられないほど肥大化してるんだ。
もう一つ追加： QtWebEngine -＞ https://wiki.qt.io/QtWebEngine
Vaevチーム、技術探求を自由に追求する姿勢に拍手だね！
C++を選んだのは思い切ってる。
セキュリティの懸念はよく言われるけど、現代的なC++とRustはちゃんと使えば同じくらい安全だよ。
Vaevのセキュリティモデルはプロセス分離とかサンドボックスとか、最新のC++機能を使うことに集中すべきだね。
Chromiumみたいな巨大な存在に独占されてる巨大な課題に立ち向かう、こんな素直な革新と勇気を見られて超ワクワクするよ。
sciter.comっていうのもあるよ。作者がオープンソースにするため資金探してたけど、十分な支援者が見つからなかったみたい。
ドキュメントを充実させてくれるといいな。
tldrawファイル、ほとんど使い物にならないよ。オンラインで見られるサービスもないし。
手に入ったのはvscode拡張機能だけ。sublimeをやめる理由がない限り、あの不明なフォーマットで文書化されたアーキテクチャを見る選択肢があまりないんだよ。
ロゴの日本語、誰か意味知ってる？
ジブトって読んでみたけど、自分には意味不明なんだ。
貢献受け付けてる？
wkhtmltopdfのChromiumじゃない代替があったら最高だな！
wkhtmltopdfってChromiumじゃないでしょ？”Wk”は文字通りWebKitのことだよ。
weasyprint.orgっていうのもあって、これはブラウザエンジンじゃなくてカスタムレンダラを使ってるんだ。
それに、これら（あとPrinceも）はPandocのバックエンドとして使えるよ。
君の言う通りだね、コメント書いてるときにいくつか混同しちゃったみたいだ。
言いたかったのは（PrinceXMLを無視してFOSSに絞るなら）、選択肢は３つに絞られるってこと。最初のwkhtmltopdfは不安定だってわかったし、二番目のweasyprintはめちゃくちゃ遅いし、三番目のpuppeteerとかを使った（ヘッドレス）chromiumは扱いにくいことがあるんだ。
princexml.comみたいなやつ？
