座談会
前編 どうなる? 今年のライブラリやAPI

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

2016年01月07日発行

目次

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

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

なお、座談会は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」ついては、次の記事を参照してください。

杉浦 有右嗣:よもつさんって、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の場合は、僕が血反吐はきながらやることになると(笑)。

全員:(笑)

誰を幸せにする技術なのか?

中村:実案件を考えたときに、フロントエンドとサーバーサイドで同時進行で進めることが多いですよね。そのとき、なにかしら仕様書的な共通のものを見ながら両方が作って、つなげるというパターンになる。

そのときフロント側から、「仕様書見てやっているけどこれができない!」とか出てくると、この情報取るには仕様書はこうしたらいいじゃないかと、サーバー側とコミュニケーションを取る必要が出てくる。逆にサーバー側的からも、たとえばパフォーマンスが出せないからこうしたい、というのが出てくるし。

RESTの場合は、サーバー側にこういうAPI作ってくださいという要求をフロントが山程やんなきゃいけないってことですよね。これがFalcorではQueryでこれに対応してくださいということになるので、フロントとしては楽にはなる。

山田 順久:こういうQueryがあったらいいなというのが、フロントが自由に言える。RESTのときよりも。

杉浦:……でも、それって結局誰を幸せにしたいか、という話な気がしますね。

全員:(笑)

山田 順久:そうそう、サーバー側はFalcorQueryのハンドリングをめっちゃ書かなきゃいけない。で、RESTよりも自由度高いじゃんQueryって。

杉浦:今までフロントがつらくなっていたのを、若干サーバーサイドに……みたいな話に(笑)。

山田 順久:つらさの総量は変わらないから(笑)。

小山田:Falcor、流行ってほしいけど、サーバー側の人のやる気次第のような。

中村:フロント側的には流行ってほしいよね。でも、今年はまだ厳しいかな。

(後編に続く)

杉浦 有右嗣
杉浦 有右嗣
フロントエンド・エンジニア

業務系SIerにて主にWebサービス開発の上流工程を経験した後、大手インターネット企業に転職。ソーシャルゲームをはじめとする、モバイル向けWebサービスのフロントエンド開発を数多く経験する。2015年株式会社ピクセルグリッドへ入社。フロントエンドはもちろん、サーバーサイドやネットワークの知識も豊富である。2018年、退社。

中村 享介
中村 享介
フロントエンド・エンジニア

デザイン事務所のWebデザイナー、Web制作会社のWebディレクターを経て、フリーランスのFlash・JavaScriptエンジニアとして独立後、株式会社ピクセルグリッドを設立。 多数のリニューアル、新規立ち上げを取り仕切った経験をもち、情報設計、デザイン、フロントエンド、サーバーサイド、ネットワークといったひと通りのWebサイト制作技術に精通する。Web制作の他にも経営、講演、執筆など幅広く活動している。

著書に『WebクリエイティブのためのDOM Scripting』(単著:毎日コミュニケーションズ、2007年4月20日)、『jQuery逆引きマニュアル』(共著:インプレス、2010年12月17日)などがある。

小山田 晃浩
小山田 晃浩
フロントエンド・エンジニア

2006年よりWeb制作会社にてUI実装や運用業務を経験した後、2010年よりフロントエンド・エンジニアとして株式会社ピクセルグリッドに入社。これまでの経験の大半は大規模Webサイトの壊れにくいHTML/CSS設計、及び実装。また、SVG, Canvas, WebGLの扱いも得意としている。 外部に向けたアウトプットも積極的に行っており、カンファレンスでの講演などを多数こなしている。Tokyo WebGL Meetupの主催者。2011年から2015年まで5連続でMicrosoft MVP for IEを受賞。 著書に『Webデザイナー/コーダーのための HTML5コーディング入門』(共著:エクスナレッジ、2011年3月12日)や『CSS3デザイン プロフェッショナルガイド』(共著:毎日コミュニケーションズ、2011年5月28日)』などがある。

外村 奈津子
外村 奈津子
エディター

情報出版社に在籍中、Mac雑誌、中高年向けフリーペーパー、コラムサイト運営、健康食雑誌、グラフィック・Web技術書籍編集、IT系ニュースサイトの編集記者を経験。その後フリーランスのエディター/ライターとして独立。2011年4月より株式会社ピクセルグリッドへ入社。ピクセルグリッドが提供するフロントエンド技術情報を提供するサービス「CodeGrid」の編集を担当している。行政書士試験合格(未登録)。

山田 順久
山田 順久
フロントエンド・エンジニア

HTML・CSSのコーディング、後にJavaScriptの設計や実装を主業務として経験を積む。キャンペーンサイトやコーポレートサイトの、動きと操作性に工夫を凝らしたUI実装を多く手がけている。複雑なWebアプリケーション実装における、コンポーネント的な考え方を念頭においたJSの設計を得意とする。 著書に『JavaScriptエンジニア養成読本』(共著:技術評論社、2014年12月11日)がある。

山田 敬美
山田 敬美
フロントエンド・エンジニア

Web制作会社、自社サービス運営会社などでサービス企画、マークアップ・エンジニアの経験を積むも、退職して1年間専門学校に通う。プログラミングの基礎を学んだのち、2013年4月、ピクセルグリッドのフロントエンド・エンジニアとして入社。CSSの設計を得意とするが、JavaScriptも好き。 著書に『Sass入門 ~より効率的なCSSコーディング』(共著:技術評論社、2012年10月19日)や『CSS3デザインブック 仕事で絶対に使うプロのテクニック』(共著:MDN、2012年3月21日)などがある。2019年、退社。

丸山 陽子
丸山 陽子
エディター

Mac雑誌の編集者を経験後、フリーランスのエディター/ライターとして独立。パソコン系雑誌やデジタルカメラ雑誌、iPhone/iPadの初心者向け書籍などの編集や執筆に携わる。2015年にピクセルグリッドへ入社し、「CodeGrid」の編集を担当する。