NHN Cloud NHN Cloud Meetup!

Webコンポーネント(1):Keep calm and #UseThePlatform

Webコンポーネント:Keep calm and #UseThePlatform

このポスター(Keep Calm and Carry On, 平静を保ち、普段の生活を続けよ)は、英国政府が第二次世界大戦の直前、大規模空爆が予告された中で、国民にパニックや混乱に備え、平静を維持するようにと配布されたものです。ところが現在、WEBCOMPONENTS.ORGは、なぜか戦争時に使用されたポスターのパロディとして「Keep calm and #UseThePlatform」というモットーを採用しました。Googleは現在のJavaScriptの様相を「戦争状況」と表現したのでしょうか。

フレームワーク戦争

ここ数年のJavaScriptの世界は戦争といっても過言ではないほど、数多くのJavaScriptフレームワークが爆発的にリリースされています(AngularJS、React、Bootstrap、ExtJSなど)。以前はjQuery1つで何もかもできていたのに。当時のJavaScriptは、静的なページ内での限定的な役割を担い、複雑度はページを更新することで十分でした。Ajaxの導入により、JavaScriptの役割が増えると共にコードの複雑度が上がり、モバイルを筆頭としたSPAの勢力拡大は、コードを限りなく複雑にしました。これを解決するために様々なフレームワークの登場は必然であったとも言えます。

毎日のように現れるJavaScriptフレームワークと対面していると、戦争だと言えなくもないですが、Keep calm and #UseThePlatform(落ち着いてそのプラットフォームを使ってみて)は、果たしてどのような意味があるのでしょうか?
(Framework = DOM, Platform = Browser)

#UseThePlatform – ブラウザ

Google I/O 2016で登場したモットー(Keep calm and #UseThePlatform)は、Progressive, Performant, Polymer:Pick Three – Google I/O 2016のセッションでよく説明されています。
要約すると、

  • フレームワークはさまざまな問題を解決する強力なツールであるが、一方で問題もある
  • 重いフレームワークがアプリを重くしている
  • リソースをユーザーに転嫁させている
  • フレームワーク固有のコードを生成する

そのため、

  • そのような問題をフレームワークではなく、ブラウザの機能を使用して解決する
  • フレームワークも軽くて良くなる
  • より少ないJavaScriptコードで使用できる
  • 結論として、標準コードで作成されたパフォーマンスのよいアプリになる

つまり、「フレームワークを育てず、そうした機能を標準に定め、標準に従ってコーディングしよう」と言えるでしょう。

Webコンポーネント

Webコンポーネントは、JavaScript、CSS、HTMLをコンポーネント化するために必要な4つの標準の総称です。
フレームワークを減らすこうした試みは、Webコンポーネントの最前線にあるPolymerを見るとわかります。Polymerは2.0にアップデートされ、1.0にあった独自の文法をWebコンポーネントの標準に合わせて変更し、フレームワークのサイズを最小10KBまで減らしました。jQueryも30KBになっていることを考えると、本当に驚くべきことです。

Living Standard

しかし、このような試みはブラウザメーカー間の標準合意が必要なだけでなく、フレームワークが更新されるように、ブラウザが素早く更新されてこそ意味があるものではないでしょうか。幸いなことに私たちはIEの引退を目前に控えています。IEを除外した際、現在の主要ブラウザメーカー(Google、Apple、Microsoft、Mozilla…)は、Living HTML Standardと呼ばれるWHATWGで標準を議論し、早い周期で更新プログラムを展開しています。またブラウザのStatusページを使ってブラウザが現在の標準をどのようにサポートしているのかリアルタイムで知ることができます。

#UseThePlatformモットーは、フレームワークを選択してその上で開発していたフローから、動的な標準ブラウザの上に開発するフローへと変化させているとも言えます。

Webコンポーネントはなぜ現れないのか?

では、なぜ私たちの周りでWebコンポーネントが話題にあがらないのでしょうか?理由はいくつかあるかもしれませんが、総合するとWebコンポーネントが実際のプロジェクトに導入するにはまだ準備が整っていないためのように思われます。

カスタム要素v1はブラウザが順次サポート対象にしており、Polyfillさえ最近まで活発にコミットされています。
Shadow DOMはv1へのアップデートからあまり経っておらず、Polyfillを使用してもパフォーマンスの問題を持っています。
さらにHTMLインポートの場合は、複数のブラウザ開発会社でその効用について意見の相違があり、いつサポートされるかわからない状況です。
一方でテンプレート要素はIEを除き、早くからすべての主要ブラウザでサポートされています。

#UseThePlatform – フレームワーク

これから別の視点で#UseThePlatformを見てみよう。たとえばGoogleはフレームワークの代わりに標準ブラウザを使用するように求めました。「大丈夫、これは別のフレームワークではないから、落ち着いて使っていたプラットフォーム(react、angular)を利用してください。」という意味にも解釈できます。

たとえ各標準が準備されていない状況であっても、4つの標準は団結して1つになる魔法の鍵のような存在ではなく、個別でも使用できます。実際にGoogleのAvocate Rob Dodsonは、昨年から他の標準を待たずにカスタム要素を適用し、私たちにも使用するのを勧めています。

また、Webコンポーネントの標準は、既存のフレームワークを代替するためではなく、補完するためのものであり、GoogleとFacebookを含むフレームワークの製作会社は、React vs Webコンポーネントではなく「WebComponents with React, Angular, Ember」と関連文書を載せています。

このように、#UseThePlatformをブラウザで解釈するとWebコンポーネントのゴールになり、React、Angularなどのフレームワークとして解釈すると、その効用を見つけることができます。Webコンポーネントのこの柔軟性は、これが既存のフレームワークに置き換わるもう1つのフレームワークではなく、Web標準に準拠する技術だからこそ持つ強みであると言えます。

NHN Cloud Meetup 編集部

NHN Cloudの技術ナレッジやお得なイベント情報を発信していきます
pagetop