現在の Web のフロントエンド開発には、4 〜 5 年前にはなかったような、さまざまなツールや技術、概念が溢れています。
この爆発的とも言える技術の発生と派生、広がりのきっかけを辿ると、HTML5 の登場に行きつくと考えています。
ちょうど、政府系業界誌を発刊されている一般社団法人 行政情報システム研究所さんより HTML5 に関する記事の執筆を依頼いただいたので、HTML5 登場によって生み出された、Web のフロント エンド開発の技術についてまとめてみました。
なお、この記事は、一般社団法人 行政情報システム研究所さんが発行する冊子「行政&情報システム」の 12 月号に寄稿したものを転載の許可を得て加筆したものです。
10月28日、ついに HTML5 が W3C の正式勧告となりました。
「HTML5」という名前が囁かれはじめた当時、それまでの HTML とは一線を画すその機能性の高さと革新性から、現実的な解というよりかはバズワード的な扱いをされていた HTML5 でしたが、現在ではすでにモバイル デバイス用を含め、多くのWebブラウザーがその仕様をサポートし、実際に動作する環境が整いつつあります。
HTML5 の登場は、あまりに自然で意識されることはないかもしれませんが、Web のフロントエンド開発の技術を大きく進歩させるとともに、さまざまな変化をもたらしました。その影響は Web ブラウザーを飛び出し、クロス プラットフォーム/クロス デバイスで動作するアプリの開発にまで及んでいます。
この記事では HTML5 の登場によってもたらされたフロントエンド開発の変化と、派生した技術、それらによって醸成されたWeb技術について紹介します。
HTML はオンライン上のドキュメントの構造を記述する目的に設計され発展してきましたが、HTML5 ではそれに加え、アプリケーションの開発プラットフォームとしての仕様が盛り込まれています。さらに、その仕様で定義される API の機能の範囲は、Webブラウザー内にはとどまらず、ストレージやネットワーク、センサーやデバイスなど、多岐にわたります。
たとえば、動画や音声といったマルチメディアの再生は、従来であれば Web ブラウザーにわざわざ別のプログラムをプラグインとして追加し、それを利用する必要がありましたが、HTML5 では video タグや audio タグを使用してそのまま再生することができます。さらには、Webブラウザー内のプログラムから、ファイルやネットワーク、Web カメラや各種センサー類など、ハードウェアの機能にアクセスすることができます。また、canvas の機能を使用して、フォト・レタッチツールのように画像を直接編集加工したり、WebGL を使用して、高品質の3Dのコンピューターグラフィクスを扱うこともできます。
今現在、HTML5 の仕様にあるすべての API を完全に実装した Web ブラウザーはまだ存在しませんが、前述したような機能は既に多くの Web ブラウザーで動作するようになっており、既にデスクトップアプリケーションと遜色のないものが開発できるようになっています。
(HTML 5 はアプリケーションの開発プラットフォームでもある)
HTML5 を採用するメリットは、前述したような、高機能なアプリケーションの開発プラットフォームとしてだけではありません。HTML5 を採用するもうひとつの大きなメリットは、かつてないほどのWebブラウザー間の互換性の高さです。
それまでのHTMLの仕様には、Webブラウザーに機能を実装するうえで明確でない部分があり、それが各ブラウザーベンダーの間での解釈の違いを生んでいました。また、HTMLに実装されていない機能へのユーザーのニーズを満たすべく、各ブラウザーベンダーがWeb標準にはない独自の機能を実装するといった状況があり、互換性の確保の面で問題を抱えていました。
HTML5の仕様書には「9.2 Parsing HTML documents 」という、それまでのHTMLの仕様書にはなかった、「HTML文書をどう処理するか」についての記述が含まれており、この仕様の存在により Web ブラウザーベンダー同士の HTML 文書処理に対する齟齬をなくすことができました。また、W3C 自身が、主要 Web ブラウザーの HTML5 の互換テスト結果を公開 したり(※1)、さらには Web ブラウザーのベンダー自身が、互換性の確保に向けたさまざまな取り組みを行いました。
たとえばマイクロソフトでは、Internet Explorer 9 と 10、11 を開発するにあたり、W3Cや Ecma International が運営するワーキンググループと協力して作成したテストケースを正式文書として公開 していました。(※2)
(※1) HTML5 Test Suite Conformance Results」として公開。現在は公開終了
(※2) Internet Explorer : Testing Center (US ページは公開終了) http://samples.msdn.microsoft.com/ietestcenter/default-JA.htm
W3C 取り組みと、各 Web ブラウザーベンダーの互換性確保に向けた歩み寄りの結果、HTML5 機能の実装度合いの違いはあれ、HTML5 登場以前のような Web ブラウザー毎に異なる専用の記述を行わなくてもよくなりました。また、HTML5 は前述したようにアプリケーションプラットフォームとしても充分な機能を備えているため、マルチメディアの再生やアニメーションのコンテンツを提供する際でも、特別なプラグインも Web ブラウザーの独自機能を必要としないため特定のベンダーの製品にロックインされこともありません。そのため、Web 標準に準拠した HTML5 で構築された Web サイトでは、ユーザーは使用する Web ブラウザーを自由に選択することができ、提供者側は、特定のベンダーの Web ブラウザーのバージョンアップの度に、毎回それに合わせた改修を行うという作業は必要なくなります。
かつては、一部の先進的な Web サイトのみが実験的に HTML5 を採用しているという状況でしたが、現在では、ブログやニュースサイトは、スマートフォンのユーザーに対応するため HTML5 (厳密には CSS3)の機能を使用したレスポンシブ Web デザインで作られていることが当たり前となっています。
また、海外ではこうしたニュースサイトのみならず、既に、政府系の Web サイトでも HTML5 の採用が進み、米国の連邦政府機関のポータルサイト(http://www.usa.gov/)や英国政府の Web サイト(https://www.gov.uk/) も HTML5 が採用されています。
Web ブラウザーの自動更新が当たり前となって HTML5 が動作する環境が出来上がり、HTML5 が W3C の正式勧告となった今が、まさに HTML5 の普及期と言えるでしょう。それまで採用を躊躇していた企業や公官庁も本格的に HTML5 の採用を検討する時期が来ています。
ここからは HTML5 が登場したことによって、さまざまに変化した Web のフロント エンド開発について、その背景を踏まえ紹介していきます。
HTML5 が登場してきて、さまざまな概念や技術が生まれました。とくにそのインパクトの大きさを表すものとして象徴的なのは Web ブラウザーの呼び方でしょう。HTML5 が動作する Web ブラウザーは「モダンブラウザ」と呼ばれ、それ以前の HTML5 が動作しない古い Web ブラウザーは「レガシーブラウザ」と呼ばれるようになりました。
そしてこの機能差のある新旧2つの Web ブラウザーにコンテンツを提供する際の考え方として「プログレッシブ エンハンスメント(Progressive Enhancement）」と「グレイスフル デグラデーション(Graceful Degradation）」と���うデザインコンセプトが生まれました。
プログレッシブ エンハンスメントは、レガシーブラウザの仕様や機能を基準としてページの設計をおこない、モダンブラウザにはよりリッチな表現と機能を提供する方法、グレイスフル デグラデーションは、逆にモダンブラウザの仕様を基準としてページの設計をおこない、レガシーブラウザには必要最低限の機能を提供するデザインコンセプトです。
(レガシーブラウザを意識したHTML5のデザインコンセプト)
さらには新旧 Web ブラウザーの、HTML5 サポートの有無を埋めるための実装技術として、ポリフィル (Polyfill) というものが生み出されました。ポリフィルは、レガシーブラウザのもつ独自実装や JavaScript を利用して、レガシーブラウザであっても HTML5 や CSS3 などの一部の機能が動作するようにする技術です。
ポリフィル用の JavaScript ライブラリとしては modernizr や html5shiv.js が有名です。現在では、新旧 Web ブラウザーの HTML5 サポート有無の差を埋めるという目的だけでなく、タッチイベント（画面に指で触れたときの動作）やレスポンシブ対応（デバイスごとに異なる画面に対応すること）などを疑似的に実装するための hand.js 、Respond.js といったポリフィル ライブラリも公開されています。
ただし、ポリフィルを導入する際には本当に実装すべきなのか充分に検討する必要があります。なぜならば、ポリフィルで賄えるのは HTML5 の機能の狭い一部の機能にすぎません。それは多くの場合、HTML5 から新しく導入されたタグが Web ブラウザーに認識されるようにしているだけの場合が多く、HTML5 の特徴であるリッチな機能がすべて実現できるわけではありません。また、HTML5 ポリフィルの対象となるのは主に Internet Explorer 7 や 8 ですが、このバージョンの Internet Explorer は JavaScript のパフォーマンスが高くないため、場合によってはそのバージョンの Internet Explorer を使用しているユーザーに対しページのパフォーマンスが落ちることも考えられます。
HTML5 関連技術の進歩には、スマートフォンに代表されるモバイルデバイスの普及も大きく関係しています。
スマートフォンのライフサイクルは PC よりも圧倒的に早く、PCに先駆けていちはやく HTML5 が動作する環境が整えられていきました。この環境の醸成に大きく影響を与えたのは、iPhone の提供元である Apple 社が、自社の提供する iOS デバイスに Adobe 社の Flash を搭載しないと決定したことでしょう。
当時、Flash は Web ブラウザー上で RIA(Rich Internet Application) を実現するためのプラグインのデファクトスタンダードでしたが、スマートフォン市場、タブレット市場でそれぞれ大きなシェアをもつ iOS 製品上で動作しないことの影響は大きく、ほどなく iOS 用だけでなく Android 用 Flash Playerの 開発も終了してしまいます。
モバイル Web ブラウザーの上から Flash が去ったあと、プラグインによる RIA に代わるものとして必然的に HTML5 が使用されるようになりました。
HTML5 を使用するとなると、古い Web ブラウザーで動作しないなど、互換性の問題が多分に予想されますが、スマートフォン、タブレットにおいてはそれほど問題にはなりませんでした。
それはなぜでしょうか? それは、モバイル Web ブラウザーで使用されているレンダリングエンジンに関係しています。
Apple 社が iOS 製品への Flash の搭載を取りやめることを決定した時点で、同社の Webブラウザー Safari 用に開発したレンダリングエンジン Webkit には既にHTML5 のサポートが実装されていました。この Webkit はオープンソースとして公開されており、Google Chrome(※3) や Android の Web ブラウザーにも採用されていました。そのため、スマートフォン、タブレットの Web ブラウザーでは、バージョンによる実装の度合いの差はあれ HTML5 がある程度動作する環境が既に整っていたのです。
スマートフォンの普及はさらに、HTML5に別の方向性の進化をもたらします。
(※3)現在の Chrome のレンダリングエンジンは Webkit をフォークした Blink を使用
スマートフォンは、ネットワーク環境が不安定な場所で使用されることが多く、安定性やパフォーマンスの問題から、Web よりも、ネットワークへの依存が少なくオフラインの使用も可能であるアプリのほうが好まれる傾向があります。また、iOS、Android などのモバイルデバイス プラットフォームには、アプリを公開/販売するためのストアが用意されており、SEO やマネタイズの仕組み的にも Web よりもアプリのほうがサービスの展開に向いていました。こうした状況もありスマートフォン向けアプリ開発のニーズは高まります。しかし、各プラットフォームにアプリを提供することは簡単ではありませんでした。それは、プラットフォームごとに開発言語が異なるためです。
たとえば、iOS 用のアプリは開発言語としてObjective-C を使用しますが、Android 用のアプリは C++ か Java で開発する必要があります。つまり、1つのサービスを 2 つのプラットフォームの展開しようとなると、プラットフォーム毎にまったく異なる言語で開発する必要があり、同然のことながら開発費やメンテナンス費もプラットフォーム毎にかかってしまうという問題がありました。
そういった問題を解決するために PhoneGap (Cordova) や Titanium Mobile のような HTML5 を使用して、クロスプラットフォームのアプリ開発を実現するフレームワークが生み出されました。
この、HTML5 を Web コンテンツの制作にではなく、純粋にアプリ開発の基盤とするというコンセプトは受け入れられ、現在では Windows 8 をはじめ FirefoxOS や ChromeOS 、TIZEN のようなオープンソースの OS も含めて、プラットフォームそのものが HTML5 で開発されたアプリをサポートしているものが出てきています。
(クロスプラットフォーム/クロスデバイスの開発基盤としてのHTML5)
HTML5 の登場以降、Apple 社が iOS 製品に Flash を搭載しないと決定した影響は大きく、それ以来プラグインによる RIA は衰退傾向にあります。それは前述したようなスマートフォン向けの Web に限ったことではなく、今や PC 向けの Web にもその波が押し寄せています。
プラグインの RIA に代わるものとして注目されているものが、HTML5 による SPA(Single-page Application) です。SPA は従来の Webコンテンツのようにページ全体の遷移は行わず、画面の遷移は DOM(Document Object Model) の切り替えで行い、サーバーサイドとのやりとりは Ajax やWebSocket、あるいは WebRTC(Web Real-Time Communication) と言った Web 向けの通信手順を用いて、基本的にはデータのみをやりとりします。そのためアプリケーションの動作はネットワーク速度の影響を大きく受けることはなく、また、やりとりされるデータも、動作に必要な分だけとなるので機敏に動作することができます。また、SPAはその構造からWebブラウザー以外のアプリケーションともサーバーサイドのサービスを共用させ易く、SOA(Service Oriented Architecture) のクライアントとしても使用することができます。
しかし、SPA はその処理のほとんどすべてをクライアント側のコードで担うことになるため、必然的に JavaScript の分量とクライアントサイドの開発の工数は増え、難易度は高くなります。
(SPAはスマートフォンアプリとサービスを共用することができる)
Web のクライアント サイドの開発工数が増えるのは、HTML5 の SPA に限った話ではありません。
デバイスやネットワークの速度、それらの上で動作する Web ブラウザーの性能が向上し、さらに HTML5 の登場によって JavaScript と CSS で出来ることが増えていくと、Web ページに実装できるサービスやそれを助けるためのインタラクション（やり取り）は増え、それを実装するための大量のコードとマークアップ、スタイルシート設定が必要となってきました。
この状況は、開発にかかる工数と難易度を下げるためのさまざまな仕組みを生み出すことになりました。
JavaScript には、古くからさまざまなライブラリが提供されてきました。Web 制作に関わる人間であれば、jQuery や Prototype.js 、Dojo や YUI といったライブラリを、使用したことはないにしても名前くらいは聞いたことがあるでしょう。これらは主にページ内の DOM の操作や、コード内で便利な機能を使う際に呼び出す「ライブラリ」でしたが、JavaScript の大規模開発が増えてくるに従い、アプリケーション全体の動作を管理する MVC、MVVM などの機能をもったBackbone.js や KnockoutJS、Angular.js といった「フレームワーク」が次々と生み出されました。
JavaScript と同様に、CSS にもフレームワークが登場してきました。CSS フレームワークは Web ページに対し、デザイン性の高い一貫したテーマを提供します。統一性のある全体のカラーやコンテンツのレイアウト、よく使用されるボタンやタブなどのインターフェース部品など、それらは Web ブラウザー間の表示の違いなども考慮されているため表示くずれなども起きにくくなっており、またレスポンシブ Web デザインで作られているためスマートフォンのようなモバイルデバイスにも対応します。
CSSフレームワークも、Pure、Gumby、Skelton など、さまざまなものが公開されていますが、現在、GitHubでもっともスターを集めている(人気が高い)のはBootstrapです。
JavaScript のコーディング作業の生産性を上げるため、フレームワークやライブラリとは違ったアプローチの方法も登場しました。それは、JavaScriptとは異なるメタ言語でソースコードを記述し、コンパイルして実行のための JavaScript を出力するといった方法です。これらは「Alternative JavaScript」=「altJS」と呼ばれ、使用されるメタ言語には、LL（Lightweight Language）を意識してコードを簡易に記述できるようにした CoffeeScript や、JavaScript にはない変数の型やクラスを持ち、複雑なコードを安全かつ効率よく記述することができるようにした TypeScript や、JavaScript 以外の他の言語も出力できる Haxe といった、さまざまな特性をもった言語があります。
(altJSはコンパイルされてJavaScriptを出力する)
また、CSSにも、JavaScriptと同様に、大量のスタイルシート設定を効率よく記述するためにLess や Sass、Stylus といったCSSプリプロセッサが生み出されました。これらも altJSと同じく、異なる記法で記述したスタイル設定をコンパイルして実際の CSSファイルを出力するものです。
JavaScript、CSS のさまざまなフレームワーク、altJS やプリプロセッサといった、コーディング作業の工数と難易度を下げるための技術の登場は、皮肉にも他の部分の工数を増やすことになりました。
そして、その問題を解決するために、また新しい仕組みが生まれてきました。
Web 制作者が、作業の結果を確認する場合、一昔前であれば更新したファイルを所定の場所に配置し、Web ブラウザーで目的のページにアクセスしさえすればその内容を即座に見ることができました。しかし、atlJS や CSS プリプロセッサの登場により、作業の結果を確認するためには、毎回それらをコンパイルし、jsファイルや css ファイルとして出力する必要が出てきました。また、リリースの前にはテストツールの実行や、ファイルサイズの縮小と難読化のための minify (圧縮)ツールの実行、サーバーへのリクエスト数を減らすためのファイル結合といったさまざまな作業が発生します。こういった一連の作業を自動化する目的で、Grunt や gulp といったタスクランナーと呼ばれる自動実行ツールが生み出されました。これらツールには JavaScript を使用して自動実行する処理(タスク)を記述することができ、プラグインを追加することによってタスクの種類を拡張できるようになっています。
Web 制作の現場では、JavaScript のライブラリをはじめ、CSS や画像など、なにがしかのサードパーティー製のファイルをリソースとして利用しています。それらを入手するには、それぞれのダウンロードサイトにアクセスし個別にダウンロードを行い、またバージョン管理も個別に行う必要がありました。こうした作業を軽減するためにパッケージマネージャーというものが登場しました。パッケージマネージャーを使用すると、制作に使用するリソースやアセット類をプロジェクトに簡単にインストールすることができ、依存関係も管理してくれます。JavaScript 用のパッケージマネージャーでは、後述する統合ツール Yeoman に含まれていることもあり Bower が有名ですが Component や RequireJS といったものもあります。
現在、前述のパッケージマネージャーの Bower とタスクランナー（各処理の自動化するツール）である Grunt に、プロジェクトのひな形を作成するYo を加えたYeoman という開発ワークフローツールが注目を浴びています。Yeoman を使用すると、パッケージの入手からプロジェクトの作成、ビルド（搭載）からminify（サイズ圧縮）や配置などの作業を一気通貫で自動化することができ、Web の制作に直接関係のない作業を軽減することができます。
(Yeoman は複数のツールをまとめたもの)
メーカー製の IDE (統合開発環境) も日々進歩する Web 開発のトレンドに惜しみなく投資を行い、前述したようなパッケージの管理やプロジェクトの作成、ビルドやさまざまなタスクを IDE 内で完結して行うことができるようになっています。これら統合開発環境には、コードやマークアップを記述する際の強力な入力補完機能を備えたエディタや、高度なデバッガー（プログラム動作確認ツール）、パフォーマンスをチューニングするためのツールやチーム開発のための機能など、豊富な機能を有しており大規模開発に向いています。とくにメーカーのサポートがあるということは、エンタープライズ関連の開発を手掛ける際には重要な点となるでしょう。
メーカー製の Web 制作用の統合開発環境としては Adobe 社の Dreamweaver や JetBrains 社の WebStorm があります。また、Web 制作専用のものではありませんが、マイクロソフトの開発製品スイートである Visual Studio には強力なフロントエンドの開発機能が搭載されており、とくにエンタープライズ領域では多くのWeb開発者が、サーバーサイドの開発も含め利用しています。
数年ほど前にスマートフォンの出荷台数は PC の出荷台数を凌駕し、その後もその伸び率は年々増え続け、現在ではPC を大きく引き離しています。この数は、そのままインターネットのクライアント数に置き換えることができます。なぜなら、スマートフォン上で動作するアプリのほとんどの動作は、インターネット接続が前提となっているからです。このことからもインターネットで展開するサービスの主な対象はスマートフォンやタブレットといったモバイルデバイスにシフトしたといっても過言ではないでしょう。実際のところ、既にコンシューマー向けのさまざまなWebサイトでは、モバイルデバイス向けのレスポンシブ対応は当然となっています。
さらにサービスを展開する側としては、スマートフォン上のアプリへデータを供給するために API を Web サービスとして公開しています。この、クライアントからのリクエストに対し、「ページ(画面)」ではなく「データ」を返すというスタイルは、この先、IOT (Internet of Things)が普及し、クライアントの多様化が進めばその重要性はさらに増すでしょう。Web ブラウザーも HTML も利用しないそこは、もはや「Web」ではなく「インターネット」の利用となります。
(IOT が普及することによりクライアントはさらに多様化していく)
Web ブラウザー上で動作するコンテンツは、サーバー上に用意された API を利用するように進化し、SPA のように複雑な UI ロジックを内部に持ち「ページ」というよりは「アプリ」に近いものも増え、Web とデスクトップの境界線は曖昧なものになっていくでしょう。さらには HTML5 をクロスプラットフォームの開発基盤とした開発は広まり、さまざまに異なるプラットフォームであっても同様の手段で開発が行え、インターネット上の情報、デバイスやセンサーの情報にシームレスにアクセスできる、そんな時代がやって来ようとしています。