はじめに
先週フロントエンドエンジニア向けの勉強会に行った際、最近フロントエンドエンジニア（コーダー寄り）になったという方に、
「なんでjQuery以外のライブラリやら、フレームワークやらを覚えないといけないんですかね。業務ならjQueryだけで十分なのに」
と訊かれ、その場の思い付きでつらつらと説明しましたが、改めてその理由を考えてみました。
状況整理
確かに、今からフロントエンドの仕事をしようとしている人や、新しい情報をキャッチアップしていなかった人にとって、今のフロントエンド界隈の新旧入り混じった状況はカオスに映るはずです。
現場ではjQueryが重宝され、それで十分業務は回っているのに、ネットを覗いてみると、やれSPAだ、リアクティブプログラミングだと騒いでおり、Angular、React、Vue.js、PostCSS、Sass、Babel、webpackなどの横文字が乱立していて、どれが自分にとって必要な情報なのか悩む、というのはわかる気がします。
「jQuery以外のライブラリや、フレームワークを覚える必要があるのか」を判断するためには、まず今の状況がどうなっているのかを整理する必要があると思いますので、そこから始めてみようと思います。
※状況整理が思ったより長くなったので、本題に行きたい方は「本題：なぜjQuery以外のライブラリを覚える必要があるのか」に飛んでください。
クライアントサイドにMVCを
jQuery一辺倒だった2000年代の制作現場に新しい風を吹き込んだのは、クライアントサイドでMVC1を行うBackbone.jsのようなJavaScriptフレームワークの登場でした。
それまでMVCはサーバーサイドで行い、クライアントサイドはサーバーサイドで生成した静的なドキュメントを表示させるだけ、という役割分担になっていましたが、2000年代後半くらいからMVCをクライアントサイドで行おうという動きが出てきました。その背景について考えてみると、
- それまでリッチな動作を担っていたFlashが使えなくなった。
- スマートフォンの普及が進み、サーバーサイドの負担が重くなった。
- クライアント側ハード（PC、スマートフォンの）の性能が向上した。
- スマートフォンのアプリが普及し、ユーザーがクライアントサイドのリッチな操作に慣れてきた。
辺りが挙げられるのかなと思います2。
要はユーザーにリッチな体験を提供するために、クライアンサイドでMVCをやる必要がでてきた、ということになります。
jQueryの限界
さて、クライアントサイドでMVCをやるということになったとき、jQueryだけで構築するということは不可能なのでしょうか？
結論から言うとそんなことはないのですが、とにかく大変です。
これまでと大きく変わってくるのは、動的に変化するデータを扱うということ。jQueryはあくまでサーバーサイドから送られてきたデータをクライアントサイドのビューに表示させることを目的に作られているので、そのデータを動的に変化させ、かつそれに状態を持たせて再表示するといった機能を持っていません。
かつ、そのデータが正なのかどうかを検証するためにはテストが必要なのですが、ただビューの操作しかしないjQueryだけでは、テストを行うこともできません。
jQueryができることは、今表示されている画面をリッチに動かすことです。他の画面に遷移したり、フォームからデータを操作して再表示させようとしたときは、その機能を新たに実装する必要があります。
そこでそれに対応しようと登場してきたのが、JavaScriptの新しいライブラリ、フレームワーク群です。
雨後の筍となったJavaScriptのフレームワーク
IT業界の歴史を紐解くと珍しくないのでしょうが、新しい技術が出てくるときは複数のプロダクトがシェアを獲得しようと切磋琢磨を始めます3。とはいえ、今のフロントエンドを巡る新技術の台頭は、目を見張るものがあります。
クライアントサイドMVCを扱えるフレームワークとして登場したBackbone.jsや、AngularJS（Angular）、Ember.js、ライブラリとしてビューのみの扱いに特化したReact、Riot、最近人気急上昇中のVue.jsなど、毎年次々と新しいライブラリ、フレームワークが登場しています4。
そろそろ落ち着くかななんて思っていましたが、2017年もまだまだ新しいライブラリが登場してきそうな予感を振りまいています5。もうしばらく、筑前煮には困らなそうです。
JavaScriptフレームワークの新しい可能性
JavaScriptフレームワークを採用する理由として、「ユーザーにリッチな体験を提供するため」と前述しましたが、ここ数年でJavaScriptフレームワークの新しい可能性が出てきました。
それは「JavaScriptだけでWebアプリとスマホアプリを構築する」ということです。
スマホアプリはiOSならObjective-C、Swift、AndroidならJavaとそれぞれ別の言語で書かれており、かつWebアプリも作るならWeb開発系の言語（RubyやPHPなど）も必要となります。
これによりコンテンツ提供側は同じコンテンツにも関わらず、それぞれの言語を扱う開発者、ベンダーに制作を依頼し、それぞれのコストを支払っていました。コンテンツ提供側からすると、どれも同じようなものなのに3倍のコストを支払うことになるので納得がいきません。
そこで、ここ数年は張りぼてのiOS、Androidアプリの中に、Webアプリを表示させるという手法が増えていました。
この手法であれば、３つの言語を使うといっても開発するのはほとんどWebアプリだけで済み、コストもぐっと抑えられるようになります。
ただ、この方法だと作り方によってはパフォーマンスに問題があったり、iOSの審査でリジェクトされたりする6可能性があったりと、多くのリスクを抱えることになっていました。
そこで登場したのが、React NativeやNativeScriptに代表されるハイブリッドアプリです。これらはJavaScriptフレームワークをベースとして、WebアプリのコードをiOS、Androidアプリのコードに書き換えることができます。
これであれば前述のリスクも軽減されるので、今後この技術に注目が集まっていくことが予想されています。
本題：なぜjQuery以外のライブラリを覚える必要があるのか
さて、長々と2017年2月現在のフロントエンド界隈の状況を綴ってきましたが、そろそろ本題に移ります。
jQuery以外のライブラリを覚えるべきかどうかを結論から言ってしまえば、あなたの今の、そしてこれからのキャリアパス次第です。
静的なサイトしか作らないのなら
あなたの勤めている会社が、サーバーサイドの開発やスマホアプリの開発を行っておらず、ビューだけの静的なWebサイトしか作っていない、かつ自分も今後それ以外のことをするつもりはない、ということであれば、無理にjQuery以外のライブラリを覚える必要はありません。
jQueryそのものも2016年に3.0がリリースされ、機能が強化されています。jQueryを使った仕事がなくなることはそうそうないと思います。
まだWebの業界に入ったばかり、フロントエンドエンジニアの仕事を始めたばかりということであれば、まずjQueryから始めるのは正攻法の一つです。
ただ、ここ数年は簡単にLPを作れるサービスや、Webサイトのテンプレートが充実してきていて、ただの静的Webサイトを一から構築する需要は減ってきています。また、静的Webサイトであっても全体としてリッチな操作感を求められた場合は、JavaScriptフレームワークの検討をする必要があるので、そういった状況は想定しておく必要があります。
今をチャンスと思えるなら
状況整理で伝えた通り、今のフロントエンドエンジニアの状況はどんどん変化しています。サーバーサイドで行ってきたことをクライアントサイドでやろうとしているので、それは当然と言えます。
ただここで、「余計な仕事が増えた」と悲嘆するのか、「やれることが増えた」と狂喜乱舞するのかはあなた次第です。
フロントエンドエンジニアとして培ってきたJavaScriptの知識を活かして、Webアプリやスマホアプリの構築にも舵をきろうということであれば、ぜひ新しいJavaScriptのライブラリ、フレームワークを覚えてみてください。
JavaScriptフレームワークを使う場合、個人でちょっと実装、というよりは、チームで大規模に開発ということが増えると思います。
そのための仕組みや、業務の回し方を覚える必要があるので、最初は大変かもしれませんが、慣れてくるとそれほど苦にはならない…いや、なるか？えーと、わかりません。
ようやく覚えたと思ったら、バージョンアップで互換性がないのでまた覚えなおしてくださいとかいって、振り出しにもどされる7ようなこともあるかもしれませんが、それはそれ。それまでに覚えた知識は蓄積され、次のフレームワークへ活かすことができるでしょう（たぶん）。
まとめ
一通り書いた後に見直してみると、本題に比べて状況整理が長すぎですね。まあ、最終的に新しいことを覚えられるかどうかは、本人の気持ち次第なんで、状況をみて自己判断するしかない、ということになります。本稿が新しい技術習得の一助になれば幸いです。
私の拙い知識を元に書いていますので、もし事実と異なる記述がありましたらご指摘ください。