zebkitがChromiumのエンジンを「リンクするライブラリ」に変えた
Zebkit – Chromium's engine as a library you link, not a runtime you live in
zebkitはBlinkやV8、PDFium、FFmpegなどChromeの中核を1つのライブラリとしてアプリに組み込めるようにする。Electronのようにランタイム上にアプリを構築するのではなく、SQLiteを足す感覚で自分のプロセスとUIを保ったままWeb機能を追加できる。最新Electron比でサイズ34%減、コールドスタート2.3秒対6.6秒、メモリ29%削減。C/Rust/Python/JavaScriptから利用可能。
Electronは土台であり、アプリケーションはそのランタイム、ウィンドウ、パッケージングの上に構築される。zebkitは部品であり、アプリケーションはSQLiteを追加するようにそれを加え、自分のプロセス、ツールキット、出荷方法を保つ。
HNでの議論
42- torginus
これはCEF（Chromium Embedded Framework）とどう違うの？
CEFもかなり削ぎ落とされたChromeエンジンで、ゲームのゲーム内ロビーやOBSのWebオーバーレイなど、多数のプロジェクトで組み込み用に使われているよね。
個人的にCEFの問題だと思うのは、Chromeをかなりバニラなまま保っていること。ユーザーアプリに含めたくないものがたくさん入っているんだ。
でも彼らがこうしたのには理由がある。もし本当にChromeのコードベースにメスを入れたら、新しいバージョンをアップストリームする能力を基本的に失ってしまうからね。
一方、Zebkitはもっと細かい粒度になりそうだ。彼らがこれをうまく扱えるか見てみよう。でも、広く互換性のあるもっと軽量なブラウザエンジンには間違いなく市場があると思う。例えば、サンドボックスとプロセス分離を単に取り除くだけでも、大きな非互換変更になる。
WebRTCや動画再生、webusbなど、99%のアプリが結局使わないような大きなモジュールを落とすのも同じだ。
- joahnn_s
よくわからない。CEFがあるのに、なぜ共有ライブラリ/CFFIとして読み込むの？ブラウザが抱えうる問題すべてに、セキュリティ問題も含めて、アプリのプロセスをさらすだけだよ。
ほとんどの言語では、CFFIは同じプロセスなのでアプリ全体がクラッシュする。個人的な用途なら適しているかもしれないけど、真面目な用途には向かない。
- saidnooneever
なぜ「zeb」なの？ペニスの俗語だよ。他に関連するものがないように見えるから、もっと良い名前が選べたはず…意図的なら、プロジェクトの品質を疑ってしまう。他のコメンテーターも議論しているようだね。
- netshade
いいね。私はZShot（ https://zshot-app.com 、 https://zshot-cli.com ）でCEFをヘビーに使っているけど、こういうのはもっと統合が簡単であるべきという点に強く賛成。
それに、そうしたライブラリ（PDFiumやFFmpegなど）をコンシューマーに公開するという点でも大賛成。出荷の負担がかなり減って、いろいろなことが可能になる。
この道を行く人への余談として一言：実際にChromium（特にFFmpeg）と一緒に出荷するのは複雑になり得る。Mac OSで出荷するなら、メインプロセスと一緒にすべてのヘルパーの公証を気にする必要がある（Zebkitもまだヘルパープロセスで動いていると仮定している）。FFmpegのライブラリにリンクするならFFmpegも同様。そしてFFmpegについては、ライセンスコンプライアンスが本当に出荷したいものと一致しているかを確認することが重要。FFmpegにはGPLモードとLGPLモードがあるので、正しいものを選んでいることの確認が大切だ。記憶が正しければBlinkもLGPLなので、そこで求められる要件を満たすことが配布に重要な影響を与える。
- prologic
これはかなり面白い！私はGoNix（https://gonix.dev）用にCEF（Chromium Embedded Framework）を使ってWebブラウザを作ったことがある。かなりうまく動くけど、共有メモリとパイプが必要になる。でもChromiumをライブラリとして埋め込むのはさらに魅力的に聞こえる。試してみようかな！共有ありがとう！