2016年、注目したいのはこの技術 | 前編どうなる？　今年のライブラリやAPI

2016年、注目したいのはこの技術前編どうなる？　今年のライブラリやAPI

2016年に注目していきたい技術について、ピクセルグリッドのフロントエンド・エンジニアが座談会形式で話しました。2015年を振り返りつつ、これからの技術を考えてみます。

カテゴリー: 座談会 >; 年末年始座談会

2016年1月7日発行

2016年、注目したいのはこの技術シリーズの記事一覧

はじめに

2016年のJS／CSS関連の技術は、どうなっていくのでしょうか。2015年を振り返りつつ、これからの技術を考えてみます。前編となる今回は、昨年流行ったライブラリや今年も残りそうなライブラリについてと、これからのWebAPIについてです。

参加者は次の通り、ピクセルグリッドのエンジニア5名です。

中村享介（@kyosuke）
小山田晃浩（@yomotsu）
山田順久（@ykhs）
山田敬美（@tacamy）
杉浦有右嗣（@leader22）

なお、座談会は2015年末に行われましたが、記事が公開される2016年に合わせ、本文中の「今年」は「2016年」を、「昨年／去年」は「2015年」を示します。

Webサイトのライブラリ

今年もjQuery健在か

中村享介：まず、JSのライブラリのことからみんなで話してみたいと思います。WebサイトとWebアプリ*で採用するライブラリって違うと思うので、分けて話しましょう。よもつさん（小山田）は、大きなWebサイトも、ちょっとした小さなWebアプリも作っているけど、ライブラリに関してはどうかな？

*注：WebサイトとWebアプリ

Webサイトは静的ファイルとリンクを介した画面遷移が中心のサイト、WebアプリはSPAのような、サーバーと動的にデータのやり取りをしながら、アプリケーションのようにユーザーの入力に応じて処理を行うサイトを指します。

小山田晃浩：Webサイトについては、今年もjQueryでいいと思います。もう、インフラみたいなもんでしょう。バージョンを、2とか3とかで使っていけばいいんじゃないですかね。

今年は、IEの下限は9が主流になるから*、jQueryのバージョン1は捨ててもいいと思います。バージョン1はIE8までしか対応していないけど、バージョン2以降の対応はIE9以降。ブラウザの下限が上がるから、それに合わせてjQueryのバージョンも上げていくということじゃないでしょうか。

*注：IEの下限

2016年1月13日にWindows VistaのIE7／8のサポートが終了します。IEの開発状況と、次期ブラウザとなる「Edge」ついては、次の記事を参照してください。

Webブラウザ最新事情　IEとEdge

杉浦有右嗣：よもつさんって、jQueryを使っているのは単純に楽したいという要素で入れているのか、jQuery UIとかプラグイン系を使いたいから入れているのか、どっちですか？

小山田：自分の場合は、楽したいから……かな。

杉浦：それなら、もうそろそろネイティブのDOM APIや素のJavaScriptでもよくないですか？

小山田：確かにそうなんだけど、アニメーションを使うときや、hide／showとかもjQueryの機能のほうが見通しがいいし。ほかにも、イベント、デリゲート……あとは、デファードとか。

中村：標準のXMLHttpRequestもだいぶ簡単に書けるようになったけど、$.ajaxのほうがより簡単だよね。

小山田：ああ、XMLHttpRequestもありますね。それにjQueryは、「誰でも知っている共通言語」という意味もあると思うんですよ。自分でJavaScriptを書いて、DOMのネイティブを使ってもいいけど、そうするとどのみち「オレオレjQuery」ができちゃうと思う。多くの人の手が加わる寿命の長いサイトであれば、そこで混乱するよりは、できるだけ共通の部分にしたほうがいいと思うな。

jQueryはパフォーマンスにすごい優れているわけではないですけど、そういう意味では、使っていく価値はあるかな。それは今年も変わらないと思う。

jQueryのバージョンが混在

中村：でも巨大サイトになると、バラバラに開発しているからページによってjQueryのバージョンが違うみたいのがあったりするじゃないですか。そういう場合、jQueryを使っていくのってどうなんだろう？

小山田：自分が開発に加わった時点で古いjQueryが入っているとしても、将来的に新しいjQueryに切り替えたりするかもしれないですよね。そうなると、古いバージョンにあって、新しいバージョンでは、なくなった機能は使わないとか。たとえば、jQuery.browserとかあるじゃないですか。

中村：逆にそういうのが使われていたりすると、もうバージョン上げられないということがあるよね。そういう場合は、ページによってjQueryのバージョンを3つとか4つとか読んでいるサイトとかあったりするのかな。

山田敬美：あ、いっぱいあります（笑）。私が担当している案件って、たぶん10年位前に作られていて、そこに機能をつぎはぎで追加していっているようなサイトだから。でも、1つのページでjQueryのバージョンが複数混在してしまっている現状を考えると、息が長いサイトだったらjQueryを使わないほうがいいのかな。

中村：息が長いサイトでも、たとえばよもつがやっているサイトのような、大元のテンプレートで管理されているなら、それはどんどん新しいのを使ったほうがいいのかな、と思う。でも、たかみー（山田敬美）がやっているような、いろんな人が手を入れているサイトだと難しいかな。

山田敬美：同じページでも、機能単位ごとに担当者の人が違うんですよね。ほかの機能に影響を出すわけにいかないから、簡単にjQueryのバージョンも上げられない。でもなしで書くのもつらい……。

中村：難しいところだよね。運用のしかたはちょっと変えていったほうがいい、というのはあるんだろうけど。

WebサイトにおけるWeb Components

中村：Web Componentsは、どうでしょう。Webサイトでコンポーネントって、Widgetみたいな使い方はありだと思うけど、そもそもまだ使えない説もありますよね。今年、使えるようになると思いますか？ Polymer*とかはWebアプリというよりはWebサイトで使えるような感じだよね。

*注：Polymer

JavaScript UIフレームワークのひとつ。Web Componentsをさまざなブラウザで使用可能にするポリフィル的な機能を持ちます。

小山田：そう、Webサイトで輝く技術だと思うけど、今使うにはちょとまだ早いかな。いかんせんまだ不安定なので。

杉浦：使ってみての感想ですけど、Polymerってまだぜんぜん手軽じゃないですよ。「ただ<tab></tab>ってだけ書けばtabのUIができる」っていうぐらいのレベルにならないと、本当の意味で手軽に使えるとは言えないと思うんです。今はまだ、「<tab></tab>と書けばtabのUIを表示する」という仕組みを別のところで自分で作って、それをページ内に読み込んで、ビルドして……と、なんやかんやしないと使えない。

それって、今までの「tabのUIのライブラリを読み込めばtabができる」というのと、ほぼ一緒ですよね？プログラミング体験的には何も変わっていない。事前にブラウザに要素として実装してあって、あらかじめこういうのが自動的に使えるよ、というようになったら、それはそれで変わるかもしれないですけど。

山田敬美：たとえば、サイト内にGoogle マップを埋め込むために、GoogleWebComponentsのgoogle-map要素を使う場合、bowerでgoogle-mapを入れるとPolymerも一緒に入って裏で使われる形になるから、意図してPolymerを使うつもりはなくても、知らない間に使ってた、というようなことはありえるかも。

ほかにも、もしTwitterのウィジェットみたいなものがWeb Componentsで配布されるようになったら、それを使うということはあるかもしれないけど。でも現状のように<iframe>で埋め込むほうが使うほうも楽だし、わざわざWeb Componentsにするかなと考えるとちょっと疑問です。

あと、単純にブラウザ対応の問題だけであれば、webcomponents.jsというpolyfillがあるから、今すぐにでも使えなくもないけど、自分でWeb Componentsを実装するのってかなり面倒。わざわざ自分のサイト内だけで使われるコンポーネントをWeb Componentsにする意味はあまりないのかなという気もします。

小山田：今年Web Componentsが流行るかと言われたら、まだ流行らないかな。引き続き、jQueryプラグインがコンポーネント的な役割として使われると思います。

Webアプリのライブラリ

AngularJS？ React？ Vue.js？

中村：Webアプリの方のライブラリはどうですか？去年の時点で、WebアプリではjQueryは使わなくなっているかな、って気もしてきているんですけど。

山田順久：jQueryはないですね、まず。

中村：Webアプリで去年流行ったライブラリってなんでしょうね？ AngularJSは実案件でもけっこう使われているよね。あとは……React？

山田順久：Reactは、今年はもっと採用が増えるんじゃないでしょうか。僕も、あれはいいものだと思うし。でも、今年はReactを足がかりにして、周辺のライブラリとか考え方がもっといろいろ出るのかな？ React自体はビューだけだからね。

杉浦：でもReact、使える人しか使えないじゃないですか。

山田順久：うん。Reactをさらりと使いこなせる人には便利だけど、世間的はどうかな。Flux*のところをどうするのかというのがあるんですよね。別にFluxにしなくてもいいけれど、自分たちで作っていくのか、既存のやつならどれ使うのかとか。

*注：Flux

クライアントサイドプログラムの設計思想（パターン）のひとつ。Reactと相性が良いため、この2つが一緒に話題になることが多くあります。

中村：一昨年あたりから話題になっているVue.js*とか、今年はどうだろう？去年はけっこう採用されたりしていたような。

*注：Vue.js

Vue.jsに関しては「Vue.jsを使いこなす」シリーズなどを参照してください。

山田順久：うちの社内でもりぃさん（杉浦）使っているし、じまぐさん（中島）使っているし。サイトとしては、「イカリング」とか「ウデマエアーカイブ」も使われているから、けっこう事例が多いですよね*。

*注：採用事例

イカリングは、任天堂のWiiU用対戦アクションゲーム「Splatoon」専用のプレイヤー間交流サイト。ウデマエアーカイブも、Splatoonのバトルを登録してウデマエの上下を可視化できるサイトです（座談会に参加している杉浦が制作）。

杉浦：Vue.jsは、去年10月に1.0のバージョンメジャーになりましたしね。

ただ、大きなサイトの作るとなるとVue.jsはどうかなと。それはVue.jsが悪いわけじゃなくて、ほかの方がノウハウが多いから、という意味で。まだVue.jsはノウハウが溜まっていないですよね。

Polymerは？

中村：あと話題になったと言えば、さっきも出たPolymerのバージョン1.0が出たのって去年だったんじゃないっけ？ ……去年の5月末だったね。0.5から全部変えやがったみたいな苦情がいっぱい上がっていたけど、去年触ってた方々、Polymerに関する苦情は大丈夫ですか（笑）。

山田敬美：そもそも、どういうときに使ったらいいかよくわからない（笑）。採用しているサイト、けっこうあるのかな？

中村：使われているサイトでぱっと思いつくのは、Google ioのサイトとか、Polymerの公式サイトとか。まあ、公式サイトは当然ですね（笑）。あ、あと東京Node学園祭2015。これはピクセルグリッドが作ったやつだね。

山田敬美：東京Node学園祭のサイトはもともとPolymerを使いたいっていうのがあって、それを見越して使いやすいデザインにしてくれたからまだいいんですけど。普通のサイトでそのまま用意されているデザインを使うことはできないんじゃないかな。

中村：デザインにこだわる必要がない管理画面系とかなら使えるかな、と思ったけど。jQuery UIみたいな位置付けとして。デザインが用意されているほうがラクっている場合もあるじゃないですか。

杉浦：Polymerの本質的な存在意義って、「今Web Componentsをやるためにはまだこのpolyfillが必要で、あの機能この機能も足りてないというところを、まとめて埋めてくれる」というところな気がしていて。

ただそれだけだと味気ないからGoogleお手製のデザインも付けときましたよ、と。

そしてそこが目立ちすぎてしまって、みんなああいうデザインのものを使いたいときに使うのがPolymer、って捉えてしまっている気がします。

だから、その本質的な考え方を知ってしまうと「やってること大げさすぎね……？」となって、人が遠ざかっている感じがするかな。

中村：確かに。Bootstrapでいいじゃんか、という。

小山田：サードパーティの要素がもっと出てきてくれたら。もっと流行るかもしれないけど。

杉浦：それは、jQueryプラグイン地獄と同じ道をたどる前提で（笑）。

小山田：polymer.cookie*とかできるかもしれないよ（笑）。

*注：polymer.cookie

jquery.cookieというjQueryプラグインを名乗りたいだけでjQueryの機能をまったく使っていないライブラリがあり、社内でたまに笑いの種になっています。polymer.cookieは、その話題にちなんだジョークです。

ライブラリの2大派閥

小山田：今年も残るとしたら、AngularJS、React、Backbone、Vue.js……。

杉浦：去年はビューだけのReactや、クライアントサイドのMVCフレームワークのMithrilが出たんですよね。……Meteorとか、どこ行っちゃったかな。

中村：Meteorは今でもごく一部の人が使ったりしているっぽいよ。多分特定の場面ではすごくいいんだけど。でも、なんだか設計とかが難しくてあんまり日本語情報もないんだよね。今年も日本では流行らないと思う。

大きく分けると、AngularJSやMeteorみたいな巨大なライブラリのフルスタック系のアプローチか、それともReactみたいなバラバラ組み合わせることが必要で、全部面倒みないよという細かいモジュール系のアプローチか。

山田順久：うーん。たとえばAngularJSとかフルスタック系では、入れちゃってここが気に入らないってときに不満が残る。細かいモジュール系のUNIX思想では、気に入らないところがあれば別のモジュール入れるからいいやで済むけど、そっちはそっちでレールがないかんじがちょっとね。両方で不満はあるかな。……でも、個人的には細かいモジュール系が好きかも。

杉浦：うん。今年も使われていくライブラリは基本的にはあんまり変わらないかな。2大派閥感もあんまり変わらない気がする。

山田順久：でも、Reactでちょっとがらっと変わった感はある。階層が一段上がったような。

杉浦：そう。Reactの登場で、細かいモジュールを組み合わせる派にも未来が出てきたような（笑）。

WebAPIの形式

中村：APIはずっとRESTでって感じで作ってきているけど、去年はいろんな案件でちょっとつらくなってきていた気がしています。REST以外だと、去年はWebSocketなどリアルタイムでやり取りするのも出てきてはいたかな。

ほかにも、去年はFalcorとかGraphQLのようなQuery型が出てきたよね。APIで決められた手続きでQueryを投げて必要なデータを取り出すという、データベースのSQL的なものみたいな形式かな。まだ出てきたばっかりなので、実際に使われている感はないですけど。

山田順久：GraphQLはFacebookが公開したやつですね。

中村：そうそう。FalcorはNetflixが公開している。Falcorって、何ができるのかというと、一個の巨大なJSONからフィルタした状態でデータを取ってくることができる。たとえば、映画のデータベースがあったとして、映画に対しては名前だIDだレーティングだなんだといっぱい情報があるよね。でも、必要なのは名前の一覧だったとしたら、映画の名前の一覧でこういう条件で返して、ということができる。JSON-RPCも似ているんだけど、一個の映画という概念で取ってしまうと、それに入っているデータが全部入ってきちゃう。でも、FalcorならQueryになっている。

というのをFalcorのチュートリアルで見て、通信量を減らすという意味でなるほどと思ったんですよね。今作っているWebアプリとか、RESTのAPIが180とか200とかになってくると、このデータだけがほしいけど、そのためにはここのAPIとここのAPIと……と書かなきゃいけなくて、ページ表示するのに30以上のリクエストしなくちゃいけなくなってくる。その辺を解決してくれるのが、FalcorみたいなQuery型のものだったりするのかもしれない。

山田順久：FalcorはCodeGridには一回入れてみてもいいかなと思いますね。でも、案件で使うんだったら、サーバー側の人に「Falcorでよろしく！」って言って、「オッケー」って言ってもらえないと。……「Falcor使っていいよ」と簡単に言ってくれるサーバーの人、いないと思うけど。CodeGridの場合は、僕が血反吐はきながらやることになると（笑）。

全員：（笑）