Zebkitは、開発者がChromiumのBlink、V8、PDFium、およびFFmpegコンポーネントを、フルランタイム環境としてではなく共有ライブラリとして統合することを可能にします。このアプローチにより、ホストアプリケーションは独自のネイティブイベントループ、ウィンドウ、ツールキットを維持しながら、Webビューを自身のUIの子要素として、あるいはオフスクリーンフレームとして追加することができます。
Zebkitのアーキテクチャ
プロジェクトの作成者であるRiiiiichardは、ZebkitをSQLiteのようなライブラリを追加するのと同じ方法で、プログラムにWeb機能を追加するための手段として説明しています。それは、レンダリング用のBlink、JavaScript用のV8、PDF処理用のPDFium、メディア用のFFmpegといったコアエンジンコンポーネントを、ネイティブコードにリンクする単一のライブラリとして提供します。
アプリケーションを独自のランタイムとパッケージングの中にバンドルするElectronとは異なり、Zebkitはホストアプリケーションが独自のイベントループとウィンドウを保持することを可能にします。エンジンは、ウィンドウとして、既存のウィンドウ（X11、NSView、またはHWNDなど）の子として、あるいはライブラリがアプリケーションにフレームを返して描画させるオフスクリーンコンポーネントとして統合できます。
パフォーマンスとサイズの比較
Riiiiichardは、ZebkitがLinux上の最新のElectronバージョンと比較して大幅な効率の向上を提供していると報告しています。具体的には、サイズが34%小さく（圧縮時62 MB）、コールドスタート時間はElectronの6.6秒に対し2.3秒であり、DOMおよびJavaScriptの速度を維持しながら、ページに対するメモリ使用量を29%削減しています。
サイズの削減は、不要な機能をオフにする特定のビルドオプションによって達成されています。しかし、作成者は、Blinkがそれらに依存しており、ほとんどのアプリケーションがメディアサポートを必要とするため、WebRTCやビデオ再生などの特定のコンポーネントは残しておく必要があると指摘しています。
コミュニティの議論とトレードオフ
Hacker Newsのコメントでは、ZebkitがChromium Embedded Framework (CEF)とどのように異なるかについて議論されました。torginusというハンドルネームのコメント投稿者は、CEFはゲームロビーやオーバーレイに広く使用されている一方で、多くの場合Chromeを「バニラ」な状態に保つため、新しいバージョンへのアップストリームが困難になることがあると指摘しました。対照的に、Zebkitのよりきめ細かなアプローチは、より特定の最適化を可能にする可能性がありますが、それらの変更の複雑さをどのように処理するかは今後の課題です。
他の参加者は、セキュリティとプロセス管理に関する懸念を提起しました。joahnn_sというコメント投稿者は、CFFIを介してChromiumを共有ライブラリとしてロードすることの安全性に疑問を呈し、エンジンでのクラッシュがアプリケーションプロセス全体をクラッシュさせる可能性があると指摘しました。Riiiiichardは、埋め込みインターフェースはC APIであるものの、Zebkitは依然として隔離を維持するためにChromiumの内部サンドボックス化されたレンダラープロセスと共有メモリを使用していると説明しました。
統合と制限事項
ZebkitはBoringSSL、zstd、FFmpegなどのいくつかのChromium Cライブラリをエクスポートするため、ホストアプリケーションはそれらを二重にコンパイルしたり出荷したりする必要がありません。これにより、ホストアプリケーションのフットプリントを管理可能な範囲に保ちつつ、基礎となるエンジンの依存関係を管理するのに役立ちます。
このプロジェクトはRust、Python、JavaScript用のバインディングを提供していますが、一部の特定の統合は現在進行中です。例えば、現時点ではネイティブなGoバインディングはありませんが、C APIはcgoを通じて使用可能になることを意図しています。プロジェクトの主な目標は、ホストアプリケーションに権限、ダウンロード、証明書に対する完全な制御を与える「スリム」なバージョンのChromiumを提供することです。