saneyuki_s log

Opinions are my ownだってばよ

EdgeHTMLを悼む

久々に色々書きたい気持ちになった + 矢倉さんの書かれたものを見て、彼とは微妙に考えることは違うかなあと思ったので書くだけ書いてみる。意見似てるなと思ってるところは書かないようにはした(標準化方面周りとか)。あと、Webブラウザ周りの現状に明るくない同僚や友人向けのテイストは含んでいる。

そもそもの大前提

まず、Webという文書・アプリケーションプラットフォームの価値は「標準仕様に基づく相互運用性」「インストールせずとも使える」の二点に集約されると自分は思っている。

最近はずいぶん聞かなくなった「Webは簡単に作りやすい」というメリットは、「Win32のデスクトップアプリに比べると」という但し書き付きで、90年代は事実だったと思うけど.NET Frameworkの進化とかモバイルOSアプリが出たりとか業界の成熟に伴って事実ではなくなって久しいと思う。

この「標準仕様に基づく相互運用性」というのは、標準仕様を実装しているソフトウェアがあればあるほど担保されやすくなっている。単一の実装と単一のテストケースだけでは、どうしても特定の実装に依存する標準仕様になっていることがあって、まず相互運用性なんてものは実現されないと思っていい。複数の実装があって、それぞれで相互に検証して、どれが実装のバグなのかどうかを試しかめるフェーズが非常に重要になってくる。

ここで問題になるのが、「今日の商用利用に耐えうるWebブラウザをゼロから新規に作り直すのは現実的には不可能である」ということ。理由は

  1. Webブラウザに求められる機能が非常に多いため、開発には多大なる人間や金や時間が必要であるため
  2. 歴史的経緯に基づく挙動や標準仕様、意図的に無視する必要のある仕様もいくつか存在するため、それらを含めて相互運用可能な状態にするには本当に大変な労力が必要となる
  3. 今日の商用利用に耐えうるWebブラウザは化石ではないため、日進月歩で進化を続けていく。仮に再実装する場合は、彼らに追いつく速度で進化させつつ足りない歴史的な機能を実装し続けていく必要がある
  4. そのような大事業を新規でやることに経済合理性がある会社は世界中のどこにも存在しない。
    • 2008年にGoogle ChromeをリリースしたGoogleでさえWebKitを利用することを選んだし、そのWebKitを生み出したSafariでさえ2001年の時点でKHTMLをforkすることを選んだ。どのエンジンも90年代のWeb黎明期に作られたエンジンを20年かけて改良し続けることで今日の日常的な商用利用に耐えうるソフトウェア足り得ている

などが挙げられる。

おもちゃ程度であれば一人でも十分に再実装は可能だし、00年代の中盤に求められた程度の機能であればエース級エンジニアを10人ほど集めて2~3年やれば近しいところまで実現できるというのはMozillaのServo Projectが2013~15年ごろに証明したけれども、アクセシビリティとかコーナーケースなどの対応を考えるともっと人数がいるし時間もいる。

そこまでやってもゼロからの新規開発では15年近く前の環境しか作れないので、何も経済合理性が存在せず、むしろ既存の実装を捨てることで影響力が消えたり、イニシアチブを取れなくなったり、相互運用性を損なう業界へのリスクを考慮して継続しているのがWebプラットフォームないしWebブラウザ開発の現場だったりする。

Opera (Presto)の思い出とwebでコードを書く話

そんな状況に陥ったWebブラウザの開発が中断されるのは別に今回が初めてじゃない。2013年には組み込み向けビジネスを当時のWebKitに破壊され、収益の柱を失ったOperaが自社製エンジンの開発を断念してChromiumに移っている。

自分はPrestoの死を悼むし、今回のEdgeHTMLの死も悼むけれども、それらが別にコードを書いていて楽しい相手だったかといえば必ずしもそうではない。

ソフトウェアなのでもちろんバグってることはあるし、「このブラウザ向けに対応しても喜ぶユーザーは滅茶苦茶少ないかもなあ」と思ってそれら専用のworkaroundを書くときは複雑な心境ではあった。だけどそれはPrestoやEdgeHTMLに限った話ではない。あらゆるソフトウェアにおいてバグが存在しているので、それに出会うかどうかの運の問題でしかないし、ユーザーが多いブラウザの方がバグが見つかりやすくて直されやすいというだけでしかない。Google ChromeだってSafariだってFirefoxだって、ブラウザの実装バグに悩まされなかったブラウザなんて一つもない。むしろインターネットの声の大きな人たちから好かれて絶賛されているメジャーなブラウザがバグっていて、普段は嫌われ者のあいつがちゃんと動いてるときは本当に複雑な気持ちだった。だけど、それが相互運用性のあるプラットフォームというものなのであるし、そうしたバグを踏んでしまった場合に誰が悪いかを決めるのが標準仕様なんだ。僕たちはそのメンドくささを飲み込んで、その上にあるメリットを掴み取ることにした。だからそこに愚痴は言えども、ちゃんとissue trackerにバグを報告して次のリリースで直ってくれればいい。それで終わりだ。

そんな心持ちでいたからこそOperaがPrestroを止めたときはショックだったし、その後にBlinkに移行した結果、Presto時代のOperaの開発者の多くがレイオフないしは自主的な退職でOperaを去り、Opera Software所属の社員の姿を標準化のメーリングリストや議事録から消えるのを見るのは複雑な心境だった。もちろんAnneみたいに他のベンダに転職して継続して活動している人もいるけど、全体としては標準化の要である「目」と実装の数が減ってしまったのは事実だ。

そうした過去や、MicrosoftIEで市場を一旦破壊・独占した結果として標準仕様の価値が無に帰した時代を知っているだけに、少なくともWebでコードを書いて銭を稼いでいた人間としてはこれ以上エンジンが消えることはWebの相互運用性に悪影響を及ぼす可能性というものは心配していた。

ましてやGoogle Chromeが、Googleの多大なる投資の結果、彼らのWebサービスとの強い結合とともにWebにおいて、かつてのIEの権勢を思い出すような強いシェアをモバイルとデスクトップの両面で持ち始めている。私企業の経済活動が「うっかりやり過ぎてしまって」、結果として全体としては不幸なことにになリかねないという懸念の矢先にEgdeHTMLの開発停止が発表されてしまった。

EdgeHTML

EdgeHTMLは、TridentをforkしてIE時代の互換コードをバッサリと落としたり、内部の文書構造がWebブラウザ向けではなかったのをDOMベースにするなどのリファクタリング話をある時期までよく発表していた。Chromium互換っぽく見せることに注力する傾向があったため、悪い意味でChromiumのダメな箇所を引きずったりもしているなと思ったし(Extension周りのAPIの作り方とか。あれは今やるならMozillaみたいにPromise使わないとダメだよ)、Windows 10のややこしすぎるサポートポリシーのために厳密な市場シェアの高いバージョンを調べるにはサービスごとのユーザー動向を見る必要はあったけれども、総体としてはずいぶんサクサクと動いてくれるし、IEと比べてwebdevとしてもすごくユーザーに勧めやすいブラウザの中身になっていたと思う。

動画系のAPIのように標準化の隙間が結構見え隠れするAPIの挙動は不安定だったりするし、Microsoft Connectに登録しても本当に直してくれるのか不安なところはあった。けれども、それは各OSに特化して作ったブラウザのあるあるなところで、Safariみたいなものだと思えば先述の通り問題なかった。少なくともEdgeHTMLについては、標準仕様に基づく相互運用性が高く、かつ時代や業界の要求してくるAPIについても大きなタイムラグなく実装してくれていたので、開発者としてもユーザーとしても期待が持てるブラウザだった。実家の父親がパソコンを買った時に「新しくGoogle Chromeをインストールして....」とヘルプしなくても済むし、サポートしがいのある(ナーバスな気持ちにならずに積極的にコードを書いていいと思える)ブラウザだと思っていた。

しかしながら、MicrosoftWindows Phoneを止め、Android向けに出したEdgeはBlinkベースになり、Microsoft自体はナデラがOpenを謳う一方でconsumer clientへの会社としてやる気の薄さとAzure/Officeの稼ぎぶりが目立つようになっていったあたりから次第にEdgeHTMLやChakraCoreも新機能開発してる話も細々とアナウンスされるようになったり、かつてはやる気に満ち溢れていたリファクタリングの話も聞こえなくなり、Chromiumが押しに押しているWeb Componentもなかなか実装されないなあと感じるようになった。

正直、FirefoxOSに全賭けして大敗北した間にAndrod版の投資をサボりにサボった結果の果てにモバイルにおける影響力をほぼ全て失ったMozillaよりも先にWebブラウザを諦めても不思議じゃないなと思うようになっていた。それでも、WebViewをGUI環境のAPIとしてWindowsのいろんなところで使っていたり、WebベースのOffice製品やVisual Studio関連製品を出しており、収益も株価も決して不調とは言えないMicrosoftが今更ブラウザエンジンを止めるとも思えず、杞憂に終わるのではないかと思っていた。そんなことを1年ほどぼんやりと心の片隅に置いていたところで、MicrosoftがEdgeHTMLが止めるかもしれないという噂が報道され、そして数日後にそれは現実のものとなった。

止める理由は漠然とわかる。Web標準への準拠ならびに市場最大シェアとなっていたChromiumとの互換性を強く押し出し、Windows 10のデフォルトブラウザとしての地位を使い、あの手この手でユーザーに使わせようとしていた割にはシェアが零細のまま伸び悩んでいたし、スマートフォンタブレットの普及の進展に伴い、モバイルで大敗北したWindowsはインターネット接続デバイスの総数における影響度は落ち始めていた。それにいくらスマートフォン市場で全く勝てなかったにしてもモバイルOSは時代の華でであり、Holo LensなどのXRの橋頭堡としての利用価値だってあったはずのWindows PhoneのGUIシェルのチームすらも解散させるような前科のある、今のMicrosoftがPersonal Computingをいつ諦めても不思議ではないという雰囲気は1ユーザーからも見てわかるように漂っていた。それ故に驚きはなく、ただただ切なさだけがこみ上げてくるだけだ。ましてや実装のdiversityの懸念がPrestoの脱落以後ずっと気にされていた中で、KHTML出身なWebKitやBlinkとは由来が全く違うTrident由来の、最も実装のdiversityにとって重要なエンジンの一つと目されていたものの脱落だけに、なおさらに切ない。今後、ORTCのようなcounter proposalが出る機会も失われるのだろうと思うと、単純に実装の一角が落ちたという以上の悲しみがある。

Mozillaの公式声明について

この件についてMozillaがChris Beard名義で以下のような内容を出している.

Goodbye, EdgeHTML - The Mozilla Blog

自分はこの声明の語調の強さには少々顔をしかめたくなるのだけれど、独立系ベンダーとしてのOperaも今は無く、WebKitも(胴元のAppleの方針も相まって)プロジェクトとして何か言うことは無いだろうし、Googleは当然何もいうはずがない。今や Google ChromeのVPであるGoogleのDarin Fisherは、彼には彼のポジショントークがあるにしても、こんな感じのことを言ってしまう状況だからね...... そのような状況を踏まえると、もはやMozillaしか言えないからMozillaが語調を荒げていうことに対しては一定の理解はできる。

だけど、この状況において(ある意味ではチャンスとも言える状況において)、FirefoxOSの失敗と同時にFirefox Androidに投資を殆どしていなかった結果、ことモバイルにおいてはMozillaは影響力が皆無に等しい状態にある。また、Web Engineのコアバリューの一つである速度の面で、総合的な結果として他二つに後塵を拝することになっているGeckoがユーザーに選んでもらえるかというと、短期的には厳しいんじゃないか。一番速い必要はなくとも、競合と比較した場合に遅いというのは選び続ける理由としては厳しいものがある。

そして、MicrosoftChromium Projectに(どの程度かは知らないけれども)参加する意向を示している以上は、少なくともWindows向けのIntegrationくらいはやるだろう。そうなるとMozillaは最後にして唯一のプロプラOSベンダーからの支援が名実ともに一切無いProjectになるわけで、モバイルやWeb全盛の中では開発チームを動態保存するだけでも精一杯とまで揶揄されるようなデスクトップOS向けアプリケーション開発としては長期的には競合比で不利になるのではないかと懸念する。

なので、頑張っては欲しい。自分はcontributorとしては退いてしまった身なのであんまり偉そうなことは言えないけども......

WebKitについて

Mozillaについて書いたので、一応こちらにも触れておく。

従来、WebKitについては結構心情としては複雑。彼らのsoftware engineeringにおけるuser first主義とそのためのperformance first主義、そして「Web BrowserはOSの1コンポーネントであるが、同時に1コンポーネントに過ぎない」と言わんばかりの姿勢には大変なる尊敬を自分は抱いている。だいたい2015年ぐらいからは標準化されている範囲に関しても、きっちりと作り込んで来ている印象もある。

一方で、specに書かれていないことの合間を縫っていると思しき最適化の結果や、モバイル環境向けにメモリリソースなどを削りこんでいると思しき最適化、彼らのprivacy重視の実装の結果として発生するバグについてはwebdevとしては本当に厄介。しかし標準化されていない・解釈次第ともいうべき箇所であったりするので強く文句も言えないし、標準化されていない範囲に関してはそれぞれの実装方針は自由であるというのがWebの多様性を支えている重要な点でもある。地道に「せめてデバッグしやすくしてくれ」「せめて動かない理由がわかるようにしてくれ」とbugzillaに要望を書いたりしていくとかするしかないんだろう。面倒だけど仕方ないね。

めんどくさい奴だけど、現状においてはそのシェアの問題とスタンスの違いから、WebUSB/WebBluetoothのように、WebのOS化の夢を諦めていないGoogle Chromeに対する非常に重要なカウンターパートなので、Webのdiversityの観点からは非常に重要なキーファクターであり、当面は応援したいところ。

まさか2012年にWebKitに市場が席巻されるのを心配していた頃に、6年後の2018年の今ではApple WebKitがWebの相互運用性のための一角を担うことになるとは誰が思っていただろうか。

Microsoftについて

あんまりWeb関係ない感想なんだけど。

2014~2015年ごろのMicrosoft Buildの様子とは大きく変わって、最近のMicrosoftは次々とconsumer client deviceについては少なくともWindowsとしては放置を決め込んでいるように見える。Windows Phoneはシェルの開発チームごと消えてしまったし、捨てるに捨てられない戦略物資だったはずのWeb Engineは今回の件で捨ててしまったし、相変わらずHolo Lensは生きているのか死んでいるのかわからないし...... CortanaもAlexaとコラボするみたいな話があったし、Windows 10 on ARMもやる気あるのかないのかわからないし、Surfaceはハードウェアの話でSotfwareとしてのWindowsそこまで関係ないし。AzureがあるからNTカーネル自体は維持するんだろうけれども、GUIシェルよりも上に関してはもうやる気がないのかな....と邪推してしまう。

ちょっと脱線した。

webdevとして

webdevとしては「Edgeを冠するWindowsのデフォルトブラウザのリリース間隔が短くなる(かも)」という点に関してのみは嬉しい。非常に惜しむらくはそれがEdgeHTMLによって為されなかった点。半年に一度のWindows 10のUpgradeに紐付く上に、そのUpgrade対象ポリシーが非常にややこしいために「だいたい最新のEdgeが使われていると信じる」ような推定からは脱出できるからだ。しかし、それがEdgeHTMLによって為されていないという点が悔やまれる。

率直に言って、現在のWebクライアントサイドの開発においてEdgeHTMLの対応に苦心するというのは例外を除いてそんなにない。彼らがChromium互換を狙っていたというのもあるけれども、後述する例外を除いて苦心するようなケースは、経験上、そもそもの問題として何かしらcross browserで動くことを一切想定していないような事例が多い。

故に、EdgeHTMLが消失したことに対してシャンパン祝賀会を開こうと主張している、どこぞのカメラアイコンの人は、少なくとも直近数年においてはEdgeHTMLのサポートを含むまともなWebクライアントサイドの開発をしていなかったか、そもそもまともなコードを書いたことがないか、後述する例外ケースばかり泥臭くやっていて心を病んでいたんじゃないかな?と思った。そういえばiOS黎明期に一発当てて以後の最近はもっぱらUI/UXコンサルタントでしたっけ? 私は彼を詳しく存じあげていないのでよくわかりませんが。Web周りは専門外なんじゃないかな? 間違ってたらごめんなさいね。

一応例外はある。それはWebRTCであったり動画配信のように、OSやベンダーとブラウザの組み合わせごとに、バックエンドの実装が変わってしまう場合。自分はWebRTCについては詳しくはないけれども、少なくとも動画周りに関してはDRMデコーダバックエンド、再生しているフォーマットやコンテンツファイルの相性というものがいまだに残っている。しかし、ライトに使っている限りは顕在化しないし、ヘビーに使っている場合はEdgeHTMLとWindowsの組み合わせに限った問題ではなく、どのWebブラウザでも大なり小なり抱えている問題で、それを踏み抜くかは運の問題でしかない。何度も繰り返すが、相互運用が価値のプラットフォームにおいてその問題は日常茶飯事であり、瞬間的には怒りこそすれども、そのようなプラットフォーム向けにコードを書いている以上は仕方ないのないことで、統合という方向性よりもそのようなバグが修正させる方向に向かった方が健全ではある。非常に面倒くさいけどね。。。。

EdgeブランドがChromiumに移行した結果であっても、おそらく類似の問題は発生するだろう。Microsoftが今後ChromiumベースのEdgeをリリースする時に、もしEdge向けのバックエンドがWindowsとの強固なintegrationを志向して、Google Chromeとは別の実装である場合、もしかするとEdgeHTMLの時以上にブラウザのバグ回避が困難な可能性だってありえる。故に、相互運用性だのWebの価値だのと言った問題をすべて外した上でも、一概にChromiumに移行することがwebdevにとって幸せだとは言えないと自分は思っているし、むしろGoogle Chromeに真の意味で一本化されていない以上、実装のモノカルチャーが中途半端に進展して中途半端な差異が生まれるだけで不幸でさえあるかもしれない。

長くなってきた

もう少し色々ダラダラ書きたかったんだけど、いったん切ることにする。

EdgeHTMLを諦めるというMicrosoftの判断は残念ではならない。非常に悲しい。