めくるめく粗挽きWebブラウザエンジンの世界

EDIT: DOjS はp5.jsサブセットを実行できる MuJS ベースのJavaScript環境だ。DOM-less。 https://github.com/SuperIlu/DOjS 

EDIT: SerenityOSを忘れてた: http://serenityos.org/happy/1st/ 自作OSに自前ブラウザというかなりヤバいプロジェクト。ブラウザ部分は最近Qtなクロスプラットフォーム版が出来た https://awesomekling.github.io/Ladybird-a-new-cross-platform-browser-project/ 。

EDIT: [Geckoとか](https://twitter.com/kazuho/status/1283631416895365120) ServoとかMosaic系列は省いてしまった。まぁみんな知ってるよね多分。そもそも粗挽きというよりはかなりmature productだし。。

----

[2020 Web Milestones](https://mike.sherov.com/2020-web-milestones/) という記事で知ったんだけどflow( https://www.ekioh.com/flow-browser/ )というブラウザエンジンがclean-room実装で熱いらしい。まぁ実際にはHTMLベースのUIエンジンで消えた商用実装なんて一杯あるし...と思っていたが **[開発blogがめっちゃ面白い](https://www.ekioh.com/blog/)** 。

[内部精度を16.16固定小数点にしていたら互換性チェックに撥ねられた](https://www.ekioh.com/devblog/fixed-point-vs-floating-point/) とかUIエンジンあるあるだし、 [GMailを表示できる](https://www.ekioh.com/devblog/full-google-mail-in-a-clean-room-browser/) のは地味にすごい。 [開発者インタビューも興味深く](https://www.quirksmode.org/blog/archives/2020/01/new_browser_on.html) 、ついでに [インタビューされているco-founderのTwitter](https://twitter.com/_Piers_) も面白い。

> We chose Spidermonkey in 2006,

...意外と開発期間長いね。。(Servoより古いことになる)

というわけで、 KHTML 由来でないWebブラウザエンジン特集。

# 消えたHTML4 ソリューション達

現在のHTML5の世界では、KHTML → WebKit / Blink の世界征服はほぼ完了したと言って良い状況だが、HTML4時代には先のインタビューにも

> Back before we started our SVG engine, there were many HTML 4 browser engines for the TV market, such as ANT Fresco and Galio (which I also worked on), Access’s NetFront, Oregan, Espial and Opera. 

と言及されているように、それなりの数の製品が市場には存在した。

**Fresco** とその後継である **Galio** 、 **Oregan Media Browser** はいずれもいわゆるIPセットボックス、つまりTVに接続されるメディア端末をメインターゲットとしたUIエンジンとして販売されていた。これらの製品は現存しない。

**NetFront** と **Opera** はそれぞれ比較的高機能なWebブラウザエンジンを実装していて、上記のブラウザと同様の組込みマーケットの他にPC/PDA上でも動作する製品を出していた。特にOperaはPC上での展開の方が有名かもしれない。これらのブラウザと **Espiral** は、後にWebKit/Blinkベースのブラウザに転向している。

これらのうち現行製品として(WebKit以外のソリューションが)生きているのはNetFrontだけで、 [paneEとリブランドされた](https://www.access-company.com/news_event/archives/2015/20150324/) 後、[NetFront Console](https://www.access-company.com/products/browser/netfront-console/) という製品になっている。

ここで言及されていないものとしては、ガラケー時代のモバイルブラウザ、例えばibisBrowser等が存在した。

# 現行製品の比較

じゃぁHTML5の時代はどうなっているのかというと、まず、↑で挙げたようなブラウザはWebKit/Blink移植としてサービスを依然展開しているところもある。また、KHTML由来であるこれらはLGPLなので、他にも独自のWebKit移植はいくつか見られる。

- Chromium Embedded Framework(CEF) https://bitbucket.org/chromiumembedded/cef/src/master/ がこの界隈ではもっとも有名だろう。AdobeのAcrobatのようなアプリケーションに内蔵される他、SpotifyやAmazon MusicのようなオンラインサービスのPC版でも使用されている。
- EAWebKit https://gpl.ea.com/eawebkit.html ゲーム内蔵のための機能を備えたWebKitで、EAのアカウントサービス等との統合に使用される。

等。

要は、ElectronやNW.jsに代表されるような、 "HTMLでアプリケーションを書いてアプリケーションということにしたい" という需要自体は組込み分野でもそれなりに存在している。

## 組込みブラウザキット Cobalt

従来のHTML4ソリューションがターゲットしてきた、いわゆるセットトップボックスにこれだけのマーケットがあるのにオープンソースのソリューションが無いのかというと実は存在して、GoogleがYouTube TVの移植層として提供しているCobalt( https://cobalt.foo/ )がそれに当たる。Cobaltの名前は例えばPS4のYouTubeアプリのバージョン情報に確認できる。

![SnapCrab_NoName_2020-3-1_18-4-58_No-00.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/67446/e9d8dadc-28ff-8c64-3ea0-75a6b6249551.jpeg)

Cobaltはフルスクリーンアプリ限定に機能を絞った独自レイアウトエンジンとV8 JavaScriptエンジンを組み合わせて、主にゲーム機上でのWebGL実装を想定したOpenGL ES2移植レイヤを備えている。

Flowは見たところCobaltよりも高機能だが、現状のYouTube以上の機能性を必要としているマーケットがどの程度あるかは難しいところではないかと思う。つまり、ストリーミングソリューションのベンダ側がCobaltをターゲットにした開発ノウハウを蓄積してしまうと、Flowのようなブラウザには席が無くなってしまうのではないかという懸念がある。

[CobaltがサポートしているHTMLタグはかなり少い](https://cobalt.foo/development/reference/supported-features.html) が、メディアコンテナ類は当然の権利のように充実したサポートを誇っている。

## ネイティブソリューション

そもそも、素のHTMLを手書きする人口自体もそこまで多くなく、もっと高レベルなワークフローにターゲットして提供されるソリューションもある。

You.I TVのEngine One( https://www.youi.tv/ )はReact + After Effectsの開発を想定したフレームワークで、要するに **オンラインストリーミングサービスの開発に特化したReactNative** と言える。... 要は、ReactNativeがあるのにフルのHTML実装なんか必要なのかという問題が商用ブラウザにはたちはだかることになる。

ネイティブソリューションはプラットフォームの制約に左右されやすい弱点があるが、Engine Oneはネイティブコードを事実上動かせないRokuでサービスを提供するために [シーングラフ構築をクラウド側にやらせる](https://www.youi.tv/react-native-roku-cloud/) という **とんでもない力技** でこれを解決している。

- https://youtu.be/hWjX3T6esWE?t=1563

![SnapCrab_NoName_2020-3-1_18-4-46_No-00.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/67446/f874f30e-736b-b167-452d-bd774cd9d25b.jpeg)

# ゲーム向け(DOM less)

先のEAWebKitのようにゲームに内蔵されるブラウザもあるが、逆に、ブラウザゲームを動かすためのブラウザという枠も一応存在する。

(エマージングプロダクトの警告: ここから下はかなり粗挽きになっているのに注意。)

## Ejecta

- https://impactjs.com/ejecta - 公式サイト
- https://github.com/phoboslab/Ejecta - リポジトリ

Ejectaは既にアクティブに開発されてはいないものの依然興味深いプロジェクトで、元々はHTML5ゲームエンジンであるImpact( https://github.com/phoboslab/impact )のゲームをiOS上でネイティブ動作させるために開発された。iOS以外のプラットフォームには対応していない。

ブラウザというか、表示できるのは `<canvas>` の2d/3d(WebGL)コンテキストだけという潔さでこのelementもHTMLでは作成できずエンジン側が生成する。JavaScriptの実行はiOS提供のJavaScriptCore。入力は各種windowイベントやモーションに対応。また部分的にWebAudioを実装している。

EjectaはWebGLを実装しているため、three.jsのような他のエンジンで実装されたゲームもホストできる。

## BabylonNative

- https://aka.ms/Bnative - 公式サイト
- https://github.com/BabylonJS/BabylonNative

MSが開発しているBabylonNativeは、同社のHTML5ゲームエンジンであるBabylon.jsのコンテンツを動作させることに特化した実装で、Win32、UWP、iOSをサポートしている。Android実装は途上。

こちらはBabylon.js自体のレンダリングパイプラインを置き換えて動作するためWebGLは実装しておらず、クロスプラットフォームのレンダリングAPIであるbgfx( https://github.com/bkaradzic/bgfx )とKhronosのGLSL実装の上に構築されている。

また、JavaScriptエンジンを置き換え可能にするため、Node.jsの抽象化層であるN-APIを一部採用している。...もっともMS Edgeの現状を考えるとChakraがどうなるのかは何も言えないが。。

WebAPI実装はXMLHttpRequestのみで、入力やアセットのロードなど他の機能は全てBabylon.js側の抽象化層に実装している。

# HTML向けのもの

Web上にはいくつかCSSに対応したレイアウトエンジンの実装を目指したプロジェクトがある。日本語圏だけでも:

- https://github.com/esrille/escudo Escudoは [ES Operating System](https://shiki.esrille.com/2017/07/XV_Semana_Informatica.html) の流れで開発開始されたWebエンジンだが 開発blogは [2013年の更新](https://shiki.esrille.com/2013/09/es-escudo-04.html) が最後になっている
- https://github.com/maekawatoshiki/naglfar NaglfarはRustで書かれたWebブラウザエンジンで、パーサについては [Qiitaにも記事がある](https://qiita.com/uint256_t/items/01308b46ea839ba4a919)

などが有り、世間的にもかなりの量がある。

![SnapCrab_NoName_2020-3-1_19-11-33_No-00.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/67446/400e8c0f-916c-b172-5659-78249b8ca9d8.jpeg)

最も完成度が高いのは **NetSurf** (http://www.netsurf-browser.org/) だと思うが、それでもDOMに関してはかなり途上で、かつ、非latinのレンダリングは壊滅的になっている。NetSurfは C で実装されたHTML5パーサなどの部品を提供している。

![SnapCrab_NoName_2020-3-1_19-11-45_No-00.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/67446/3774381d-b7b5-35bc-68e7-0742296c7717.jpeg)

**Litehtml** ( https://github.com/litehtml/litehtml ) はC++実装のレイアウトエンジンで、Googleのgumbo HTML5パーサ( https://github.com/google/gumbo-parser ) をHTML5パーサとして採用している。少くとも公式サイト( http://www.litehtml.com/ )は正常にレンダリングできる。

<blockquote class="twitter-tweet"><p lang="de" dir="ltr">litehtml (<a href="https://t.co/0C0XnjjfBY">https://t.co/0C0XnjjfBY</a>) + imgui render hooks + lumix glue+net code (<a href="https://t.co/TiYppPnLhp">https://t.co/TiYppPnLhp</a>) = basic web renderer <a href="https://twitter.com/mikulasflorek?ref_src=twsrc%5Etfw">@mikulasflorek</a> <a href="https://t.co/wV5K7Iuhyv">pic.twitter.com/wV5K7Iuhyv</a></p>&mdash; Omar (@ocornut) <a href="https://twitter.com/ocornut/status/890210588600565762?ref_src=twsrc%5Etfw">July 26, 2017</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> 

Litehtmlは(CSSフレームワークの)Bootstrapで書かれたサイトや↑のtweetのようにHackerNewsをレンダリングできる程度の互換性はあり、NetSurfよりもコンパクトな実装も相俟って興味深い。

**Lexbor** ( https://github.com/lexbor/lexbor ) はもっと野心的でNetSurfのように関連ライブラリもフルスクラッチで実装しているが、NetSurfやLitehtmlと異なりレイアウトエンジンをまだ備えていないためブラウザとしてはまだ使えない。

# かんそう

残念ながら現状はFlowのようなプロダクトが生き残るには大変厳しい環境と言わざるを得ないが、どういうビジネスを今後展開していくのかは興味深い。

WebKit/Blink以外のブラウザが今後生きる道があるかというのも微妙な問題だが、 [以前のエントリでNode.js + jsdomにUnityのゲームを載せた](https://qiita.com/okuoku/items/60ea7bb9c20b38505531) ように **Webプラットフォーム上で書かれたアプリを動作させるための特化環境** はそれなりにチャンスが有るんじゃないかという気がしている。

ReactNativeに代表されるような、"DOM less" Webプラットフォームが隆興している現状を考えると、traditionalで"完全"なWebブラウザよりも、部分的でも現実的なワークロードを提供できるレベルのものに割と需要が有るのではないだろうか。