Subscribed unsubscribe Subscribe Subscribe

Chromeの新エンジンBlink ― どうなるんだろう篇

なぜなに篇Webプラットフォーム篇ではBlinkに至った背景や、Blinkの互換性への取り組みについてだーっと書いた。
今回はBlinkの登場が何にどんな影響を与えるか、だらだら考えてみる。

Chrome

すでに色々書いてはいるけれど。

WebKitから離れ、Chrome専用エンジンとなるので、これまでWebKitでは合意を得られなかった機能について抵抗なく入れられるのはGoogleにとってはよいことだろう。Pointer EventsとかIME APIとか。Launch Processのもとでだけど、試験実装は進めやすくなる。

WebKitから離れることでの最大の損失は、WebKitに参加している人のタレントだろう。BlinkチームのQ&Aセッションによると、BlinkとWebKitとの間に「フォーマルな関係」はないとのこと。パッチを自動的にやりとりするような仕組みは用意されないから、コントリビュータがボランティアで、パッチをどちらにも投げる、あるいはマージするしかない。BlinkとWebKitが離れていくにつれて難しくなっていく。

あとは、これまでWebKitにあったバグはBlinkにも引き継がれるわけだけど、WebKit BugzillaからChromium issuesに自動インポートするとかそういうのもない。誰かがそれをしないといけない。やんないとなあ。面倒だよねえ……

(追記: Syoichiさんに一部バグ移行をしてる方がいると教えてもらった。)

Opera

OperaがWebKitに移行した時に、WebKitプロジェクト内でどうOperaのユニークネスを活かせるのか、不安を交え書いた。ただ、Blinkに移行したことで政治に関わるプレーヤーが減った、というか決定者に近い立場になった。

Launch Processにある、標準へのコミットやテストへの言及はOperaがこれまでWebに大きく貢献してきたことだ(標準化については、関わってたひとが結構辞めちゃってる印象があるけど……)。BlinkになってOperaはとてもよかったのではないか。

AndroidとWebView

AndroidのWebViewもChromiumベースになっていくので、Blinkがそのうち入ることになる。よりよい設計のものがもたらされるはずなので、よいことなんだろう。

アップデートやフラグメンテーションについては、わからない。たまに家電量販店に行って新しい端末を見るんだけど、Androidのバージョンは4.1だし、Chromeの他にもAndroidブラウザが入っちゃってたりするし、Web開発者にとっては好ましい状況ではまだない。

WebViewに手が入ってしまう問題は解決するのか。なってほしいけど、エンジンが変わったくらいで変わる問題じゃなさそうな気がする。Android 5.0の発表が噂されているけど、WebViewまわりはどうなるのだろう。

あと、WebViewのバージョンはChromeのように6週間でバージョンアップ、なんてしないだろうし、できないだろう。Webなら「これからChromeになるんで〜」とそのうち言えるようになるんだろうけれど、WebViewを使ったハイブリッドアプリとかだと、苦しい状況が続くのかもしれない。

強制的なアップグレード機能をもつChromeの下にAndroidが入ることで、アップデートについて改善したりするといいんだけど。

WebKit

やっぱり気になるのが、WebKitプロジェクトへの影響だ。

BlinkがChromiumに必要ないコードを削除している一方で、WebKitもChromium関連のコードやV8バインディングを削除しているメンテナがいない機能もまとめている。こういうのが削除されて行くと「違うエンジン」になるのは案外早いのかもしれない。

WebKitに集っている他のパーティはどうなるんだろう。GoogleがいたからWebKitを選択したっていうのがひとつの理由だったパーティも少なくないのかなと思う。でも、BlinkはChromiumのContent API上での利用しか検討していない。使うのであればと、Chromium Embedded Frameworkが提示されているけれど、すぽっとWebKit→Blinkに移行ってのはできるんだろうか。

加藤さんが言っているWebKit発のイノベーションが消えないか、主要スポンサーが一つ失われたOSSプロジェクトはどうなるのかというところも気になる。

WebKitが終わりだ、とは思わないんだけれど、WebKitであることの大変さは、Blinkの登場によって今まで以上に表面化してしまった。ほんと、今後どうなるんだろう。

テキスト選択のハイライト範囲が気持ち悪いのと、いろいろあるバグを除いて、WebKitは好きなので、今後も発展し続けてほしい。

Adobe

注目したいのが、Adobe

AdobeのWebプラットフォームへの貢献は、ブラウザベンダーではないという彼らの業態もあってユニークだ。WebKitにはRegions, Exclusionsなどレイアウト機能についてパッチを提供してきた。ほかにも、MaskingやCompositing、Custom Filtersなど、画像合成・変形にも多くのリソースを提供している。

彼らが貢献していく領域は、Adobe & the Webというページに書かれている。“Robust graphical foundation”, “Magazine-like layout”, “Cinematic visual effects”, “Typography”, “Consistency”, “App platform”とあるけれど、とくに最初の4つはAdobeの強みがはっきりわかるのではないだろうか。

WebKitに貢献している理由は書かれてないけど、おそらくiBooks登場→EPUB使う→CSSへぼい→InDesign使うパブリッシャーから要望→WebKitに手を入れるしか、的な流れなんだと思う。

なので、今後も基本はMac port, つまりWebKitがプライマリなターゲットなのかなとは思う。ただ、人材募集を見るとWebKitだけでなくGeckoにも詳しい人を探しているし、実際Geckoにもパッチ提供したりしてるし。Blinkについても、Blendingについてのパッチ投げるよ的なことも言ってるので、特定の領域にはAdobeが絡んできそう。彼らの提案する機能はWebから見ると「新しい」ので、成熟させてWebで使えるようになってほしい。

あと、BracketsなどはCEFを使っているので、そっちからBlink/Chromiumへのコミットもあるかもしれない。もうあったりするんだろうか。

Apple

気になるというか懸念してるのが、roc先生も書いてるけど、SafariというかAppleが今後閉じてしまわないかということ。

AppleWebKitに果たした影響はもちろん大きい。立ち上げたというのももちろん、CSSへのグラデーションやマスク、変形、アニメーションなど、Appleがむりくり導入したから可能性が広がったってのもあると思う(そうじゃなかったら未だにSMILSVGとか言って、あまり進んでなかったかもしれない)。

ただ、Appleが導入した機能って、設計がまずいといわれることが多々ある。古くはCanvas API、もうちょっと新しいのが<meta name="viewport">とか。あと -webkit-gradient() も評判が良くなかった記憶がある(これは構文変えまくったりとか、標準トラックでの設計もまずかったけど……)。標準化への進みが遅れると、いけてない機能から何年も移行できなくなる。viewportとか、いつCSS側にもってこれるんだろう……

新しい機能の追加は、webkit-devにメールを投げてラフな合意のもと実装というプロセスが2年前くらいから運用が始まっていた。標準に入っていない機能が提案されると「WGに投げとき」てきな返答が返ってくるとか、よい流れになってきたんだけど、そこからGoogleがいなくなる。このプロセスは、今後も維持されるのか。

独自拡張が悪だとはそんな言いたくないけれど、Appleの独自拡張はモバイルでの影響が無視できない。その後標準化が始まったとしても、他での実装やSafariの挙動の修正には時間がかかる。

Appleは今後どれくらい、標準化にリソースを割いてくれるのか。今と同じ、もしくはそれ以上でいてくれるのか。

標準化・Webプラットフォーム

新しいエンジンとはいえ、現段階では「ほとんどWebKit」なので、標準化にあたっての「2つの独立した実装」という要件にBlinkがカウントできるかというと、現時点では無理だろう。Prestoの抜けた穴はすぐには埋まらない。

ただ、今後Blink, WebKit双方に追加されていく機能については、コードが独立する可能性があるので、そうなれば独立した実装と認められるだろう。既存機能については、そこにタッチする何かで大規模なリファクタリングや書き直しが行われたりしないと、WebKitとしてカウントされるんじゃないかなあ。

Webプラットフォームとしてみると、GoogleのリソースとAppleのリソースが離れるので、機能の進みが「鈍化」したと感じるのかもしれない。

Launch Processで明文化された、標準へのコミット。Chromium Feature Dashboardを見ると、けっこう色んな所でベンダー間の思惑に違いがあることがわかる。Webは進んでくれるのか。Blinkプロジェクトは、彼らのプライオリティとしてあまり高くないものについての標準化に、どれくらい貢献してくれるのか。

しかし、他のベンダーの反応が視覚化されると、スタンスがいろいろあるのだなあ、みんなせーので同じものとはいかないのだなあ、と、すこし憂う。良く言えば多様で、よいことなのだけれど、「これが今使えたらなあ」と思うものがちらほらとあるので。

Web開発

Web開発に変化が起こるか。短期的にはもちろんだけど、中期的にも変化が起こるかというと、そんなないと思ってしまう。憂う。

下を見てしまいがちなんだ。デスクトップならIE8(以下)、モバイルならAndroidブラウザ、そこを最低ラインとして作り方を考えてしまう。

モバイルについては、Androidブラウザ+Safari+(UI)WebViewというWebKit寡占状態がしばらく変わりそうにない。Chromeががんばっても、Blinkがしばらくは「ほとんどWebKit」だし、WebKit依存なコードが減るのかというと、そんな気はあまりしない。減ってほしいけど、ずっとゆっくりなのかなとも思う。

モバイルに非WebKitなブラウザが増えるか。どうなんだろう。Firefoxが起こせたようなことが、モバイルでも起こるといいなあとは思うけど、ただでさえダイバーシティが少ないので……

標準においても、UI関連イベントやスクロールとか、追いついてない部分が多い。WebKit依存や開発者への訴えかけで問題が解決するわけでもない。これを「発展の余地がある」と捉え続けられるのか。

ぼく

Blink関連の情報を読んで、Blinkにはとてもポジティブな見方をしている。ひねくれているので、まあ今とそんなに変わんないなとも思うし、プロセスの「例外」が増えることへの危惧は否定できない。けれど、WebKitでなくなったことの利点って、

Blinkで驚きだったのが「こういうことになりまして、これです」という事後発表ではなく、「こうします」という発表だったこと。準備はしていたんだろうけど、MLやレポジトリ、他のいろいろも発表後から始めている。スタートのアピールとして、とても上手いなと思った。

このアピールは何なのだろうかと考えて、Blinkはコミュニティを欲しているのかもしれない、と思った。やはりWebKitのエンジニアを失うのは痛いし、これからは自立してかないといけない。Chromium/Blinkに貢献してくれる人、ほしいのかなあと。「コミュニティ」感が出ると、言ってることの「いい子ちゃん」感も薄れるだろうし。そういう点でMozillaってやっぱ「コミュニティ」としてとても強い気がする。

1週間立ち、要らないコードががーっと削られている。DevToolsは変更が入り始めた。ディスカッションでは、今後どうして行こうかという話が進んでいる。「いま起こっていることとして感じられて」わくわくがある。今まで「『スピード感』て何よ、とくに『感』って」と思ってたのだけど、これがそういうことなのかなあと思った。

標準/ブラウザウォッチャーとしては、WebKit依存でWebが終わる感じが少し薄れたのでよいと思うし、対象が増えて素敵。一方で、対象が増えて、しかも開発スピード上がるとか言うんで、しんどそうとも思う。Peter BeverlooもBlinkウォッチャーになるので、WebKitは有用なソースも減ってしまうし。ウォッチャーとしてはチャンス(なんの)でもあるけれど。

いま気になってるのは、ChromiumとBlinkのレポジトリ統合が提案されて、それが支持されてる感じなこと。開発としてはよいのだろうけど、これされると、Chromiumレポジトリを追いかけないといけなくて、Blinkだけの変更が追いかけづらくなってしまう気がするんだよなあ……。何かいい方法とツールを探したり、場合によっては作ったりしないと……

ただ、いまのやり方はだいぶ非生産的なかたちをとってるので、もうちょい良くしてかないといけない。あと、いつまでもウォッチャーのままでなく、もう少しブラウザやら標準にコミットしないとね。自分にできること見つけないと。そういう点でChromium Feature Dashboardができたのはとても嬉しい。ちょっと突っ込んで参加してみようと思う。


感想なのでだいぶ雑になってしまった。MicrosoftやMozillaについては思いつくことがなかった。Dartについては詳しく知らないので何も書けず。

これにてBlinkについてのエントリはひとまず終了。引き続きウォッチ的なエントリとかを書くよ。