JavaScriptでフレームワークを書くのはもうやめましょう。

JavaScriptフレームワークというものは、あたかも避けられない死と税金のようなもの、絶対にぶちあたる避けられないものといわれています。こっそり聞いてみましょう、新しいウェブプロジェクトが始まるとき、一番初めに聞かれる質問は？十中八九は「どのJSフレームワーク使っているの？」でしょうね。昨今の業界においてJSフレームワークというものは本当に根深く浸透しているのです。でも、だから必須だというものではないのです。実際、もう使うべきではないのです。

どうしてこういった結論に至ったのか、振り返ってみましょう。

AngularにBackbone、Ember・・・

ここのところ長い間、 ウェブプラットフォーム とはHTML+CSS+JS、と簡潔に技術用語の羅列でまとめられてしまっていましたが、そこにはもっとぴったり表す用語“大混乱”が欠けていました。みなさん、かつてのInternet Explorerでのボックスモデルやレイヤータグの不具合、忘れてはいませんよね？ウェブ開発における古き苦しき時代の記憶がよみがえってきますよね。
長い間、ブラウザ間にはほんとうに多くの不一致がありました。こうした不一致をカバーするために、この世界ではフレームワークを書くことが必須でした。イベントの伝達方法やサポートされるタグの種類等、ブラウザ間における基礎的な要素に関してでさえ仕様が合致していなかったのです。そのためフレームワークとは、欠点をカバーするだけではなく、ブラウザの動作仕様を規定する独自モデルを構築するものでした。こうした独自モデル群(複数形)とは、イベントの伝達モデルや、DOMを使った相互作用モデル等、あらゆるモデルが考案されたことを意味します。多くの開発が進みました。そして、まるで雪のひとひらや数千もの花々の一つかのように、jQuery、Dojo Toolkit、MochiKit、Ext JSといったライブラリから、AngularJSにBackbone.jsという有名なフレームワーク、そしてEmber.jsやReactといった新しいフレームワークやライブラリが作られました。この10年でまさにJSフレームワークの一連のパレードが繰り広げられたのです。
こうした10年間が過ぎていく間、ブラウザは改良されました。標準へのサポート機能は改良され、まるで常緑樹のように安定してきました。ブラウザは自動的にアップデートされ、バージョンがあがるごとにより機能的になり、更なる標準化が進みます。 HTML Imports , Object.observe , Promises ,　そして HTML Templates といった新しいスタンダードを手にした今や、JSフレームワークモデルの存在意義を考え直す時期が来たと思うのです。HTML＋CSS＋JSを使う別のモデルを創出する必要は、もうまったくありません。
では、いったいなぜまだJSフレームワークが作られ続けているのでしょう？おそらくそれは、惰性や習慣に流されているだけのように思われます。そして皆さんは、フレームワークは別にそんなに悪いものではないし、有害という訳でもないよ、と思っていませんか？

では、ここで一度ウェブフレームワークの定義を明確にすることから検証をはじめてみましょう。フレームワークとは、Gistのような単体のソースコードの管理からはじまり、徐々にコードの集合がより大きくなってライブラリへと成長し、最終的にフレームワークとなるものです。

gist → ライブラリ → フレームワーク

とはいえ、フレームワークとは巨大なライブラリである、といえるわけではありません。フレームワークとは、イベント同士の相互作用のあり方を規定する独自モデルを有しており、DOMで規定されたりするものです。では、いったいなぜフレームワークを避けるべきなのでしょうか？

抽象化 フレームワークが有する問題点の一つは、たいてい各フレームワークのアピールポイントにもなっている点なのですが、ウェブプラットフォームを抽象化するということです。このことは、各自が独自のソフトウェア開発に注力できてしまう、ということを意味します。おかげで今や皆さんは、HTML＋CSS＋JSとフレームワークという二つのシステムを習得しなければならなくなりました。もちろん、フレームワークがウェブプラットフォームを完璧に抽象化したものであるならば、皆さんはフレームワーク以外何ら気にする必要はありません。でも実際のところ、 抽象モデルというものは穴だらけ なのです。結局皆さんは、プログラムが思ったようにうまく動かず原因を解明しなければならない時には、フレームワークの全てのレイヤーからHTML＋CSS＋JSに至るまですっかり掘り下げていかなければならないのです。

氷山の地図を描く

フレームワークというものは氷山のようなものです。水上に浮き出ている10%の部分を見ると、特に危ないようには見えませんが、残りの90%の隠れている部分が問題なのです。フレームワークは実際、氷山以上に危険を秘めているようです。フレームワークを学ぶということは、氷山の地図を描くような行為です。フレームワークを使いこなすためには全体像を把握し、完全に全てを地図に落とし込むよう努める必要があります。そのために長い時間を費やしたとしても、すべては水の泡です。結局その氷山は溶けてなくなってしまうのです。

ウィジェット フレームワークのもう一つのアピールポイントが、ウィジェットライブラリへのアクセスが可能になる、ということです。でも、ウィジェットにアクセスするためにフレームワークを用いる必要はまったくありません。ウィジェットは全て、独立した、自由にアクセスできる存在であるべきです。 CodeMirror が最近では良い例です。JavaScript製の、シンタックスのハイライト機能を有するコードエディタです。フレームワークなしでどこでも使えます。

フレームワークそのもののためにもウィジェットが作られてきましたが、すべて無駄な努力でした。MochiKitのウィジェットたち、すべて思い出せますか？EmberやAngularJSに移行した今、いったいどれだけをまだ使っていますか？

データの結合 私自身は正直、まったく必要性を見いだせない機能ではありますが、もし皆さんが必要とするならば、それはフレームワークではなく、ライブラリを使って実現するべきです。

長期的にみると、フレームワークによる問題は結局サイロのような貯蔵庫に並べられて終わりです。それらは景観を分断します。フレームワークAのためのウィジェットは、フレームワークBでは動きません。時間の無駄です。

では、ポスト・フレームワークの世界はいったいどうなっているのでしょう？

HTML＋CSS＋JSが私のフレームワーク

基本的な考え方は、フレームワークは不要、HTML＋CSS＋JSに最初から備わっている機能を使ってウィジェットを構築する、ということです。大きい塊を独立したコンポーネントに分解して、好きなように組み合わせられるようにするのです。この全てを可能にする最後のピースは Web Components を構成する技術群です。

HTML Imports、HTML Templates、Custom Elements、Shadow DOMは、再利用可能な要素と機能性の作成を可能にし、コードをフレームワークから切り離してくれる実現技術です。これらの技術の詳細については、以下の記事やライブラリを参照してください。

• HTML Imports
• Polymer
• X-Tag
• Bosonic

では、私たちは <x-flipbox> を作成すれば、勝利宣言をして帰宅できるのでしょうか？

いいえ、そうではありません。Web Componentsを使用するために最初に必要なものは、X-TagやPolymerといったポリフィルです。これらの必要性は、ブラウザがその仕様を実装していくにつれて今後徐々に減っていきます。

ここで強調しておきたいのは、これらのポリフィルはウェブでの開発に独自のモデルを導入するフレームワークではなく、HTML 5モデルを有効にするためのものであるという点です。しかし必要なのはこれだけではありません。このプラットフォームはあるブラウザが現在の標準から多少逸脱しているため、そのギャップを補完するポリフィルが必要です。必要なコードの多くは MDN から入手できそうです。ここのドキュメントには 短い関数ごとのポリフィル が書かれていることが多いですからね。

1つの巨大なHTML 5ポリフィルライブラリがあればいいのですが、もっといいのは、私が「html-5-polyfill-o-matic」と呼ぶ一連のツールです。これらを使うと、全く標準的なHTML＋JSを使ってWeb Componentsを記述することができ、その後、静的分析またはランタイムのObject.observe経由でコードを分析してから、完全なHTML 5 ポリフィルの正確なサブセットを私のプロジェクト用に作成してくれるのです。

私はまず、複数のソースのWeb Componentsやライブラリ(つまりX-Tagの <x-foo> とPolymerの <core-bar> )をミックスして組み合わせることから始めるため、この種の機能性は特に重要です。この場合、両方のポリフィルライブラリをインクルードする必要があるでしょうか？ 答えはノーです 。また、これらのカスタム要素をどれくらい厳密に取得する必要があるでしょうか。X-TagとBrickにはどちらもバンドルジェネレータがあります。

• Brickのダウンロード
• X-Tagのダウンロード

カスタム要素を作成する場合、独自のバンドラーも作成する必要があるでしょうか？ 私は拡張性の点から良い考えだとは思いません。もっとうまく扱うことができるイディオムやツールが必要だと思います。これにより、オープンソースの方法が変わることになるかもしれません。「ウィジェット」はプロジェクトではないので、これらの取り扱い方法を変える必要があるのです。もちろん、コードはGitで記録しますが、GitHubプロジェクトにまるまる費用を投入する必要はないのではないでしょうか。現在のプロジェクトよりもGistに近い、軽量なものがふさわしいように思います。ではすべてのコードを、プロジェクトで使用するための適切な形式に最小化／ 圧縮 するには？ Asset Graph あたりから始めるのがよさそうです。

さて、今私たちに必要なものは何でしょうか。

1. 再利用可能なコンポーネントを構築するためのイディオムとガイドライン。
2. これらのイディオム下ですべてのHTML、CSS、JSのコンパイル、クラッシュなどに使えるツール。
3. 実際の必要性に基づき、完全な、またはスケールダウンした、拡張可能なHTML 5 ポリフィル。

これからは、最新のフレームワークの最新モデルについて学習する必要がありません。特定のニーズに合わせてカスタム要素やライブラリを取り込みながらプラットフォームで直接作業を行い、氷山の地図を描く代わりにアプリケーションの構築に時間を投入することができるのです。

Q&A

Q： なぜフレームワークの作者を嫌うのですか。
A： 嫌ってはいません。実際、私の親友の何人かはフレームワークを作成しています。皮肉交じりの「 台無しのJavaScript 」から多少触発された面があることは認めます。しかし、繰り返しますがフレームワークの作者をバカにする意図はありません。

Q： ＿＿はHTML 5ではできません。つまりフレームワークが必要です。
A： 第一に、これは質問ではありません。第二に、ご指摘に感謝します。____をフレームワーク抜きでできるように、協力してHTML 5に機能を追加しましょう。

Q： でも、___はフレームワークではありません。ライブラリです。
A: 説明したように、gistとフレームワークはきっぱり分かれているわけではありません。そしてあなたの描く境界線は私とは少し違うようです。でも問題ありません。これはソフトウェアの特定の要素をどう分類するかという話ではなく、フレームワークからの離脱の話なのですから。

Q： 私は長年 ＿＿や＿＿や_＿＿を使ってこれをやってきました。
A： これも質問ではありません。しかしとにかく、それは結構なことじゃないですか。頑張ってほかのみんなを助けてやってください。

Q： ではドロップダウンメニュー、タブ、スライダ、トグルを書き直す必要があるのですか？
A： もちろん違います。私が言いたいのは、特定のフレームワークを使わなくてもこれらの要素を作成する方法があるということです。

Q： HTML Importsは私のサイトのパフォーマンスをすっかり低下させてしまいます。
A： 単純に実装したらそうなるでしょうね。だから、HTML、CSS、JSすべてをコンパイルしたり圧縮したりするための ツールを使う必要があると述べた のです。

Q： つまり、ライブラリは一切使わないということになるのですか？
A： そんなことは言っていませんよ。私はライブラリとフレームワークの境界線をとても慎重に説明しました。他のライブラリとともに使用できる独立した要素を提供するライブラリはいいのです。やめた方がいいと思うのは、100%取得することを要求するフレームワークです。

Q： でも私はデータの結合が気に入ってるんですよ。
A： そういう人はたくさんいます。私は自分の好みを述べているだけで、データバインディングを使ってはいけない、とは言っていません。私はただ、データ結合のためにフレームワーク全体を採用する必要はない、そのためのスタンドアロンのライブラリが存在する、と言っているのです。