JavaScriptの2016年:フロントエンド開発者が押さえるべき重大トピック

2017/01/20

Craig Buckler

0

Articles in this issue reproduced from SitePoint
Copyright © 2017, All rights reserved. SitePoint Pty Ltd. www.sitepoint.com. Translation copyright © 2017, KADOKAWA CorporationJapanese syndication rights arranged with SitePoint Pty Ltd, Collingwood, Victoria,Australia through Tuttle-Mori Agency, Inc., Tokyo

相次ぐモダンなフレームワークの登場、脱jQueryの動き、ECMAScriptの進化など、SitePointの常連ライターが2016年のJavaScript事情を振り返ります。

2016年は、見方によっては歴史的であり、奇妙でもあり、楽しくもあり、恐怖でもあった年でした。JavaScriptだけに絞ると、ほかの大きな出来事に比べれば取るに足りない変化に見えますが、開発者にとっては重大な出来事でしょう。

JavaScriptの人気はとどまるところを知りません。すべての人に好かれる言語仕様ではありませんが、10年前のように馬鹿にされることはほとんど無くなりました。個人的にはJavaScriptが大好きです。そう、あのもどかしかった初期の頃からです。C++やJava、あるいはPHPから移ってきた人は最初は戸惑うでしょう。JavaScriptは取っ付きやすく見えますが、実はそうではありません。でも先入観を捨てれば、きっとそのシンプルな優美さ、実用性の高さ、柔軟さが分かってくるはずです(とはいえ、日付の取り扱いは今も悪夢ですが!)。

2016年の5月にJavaScriptは21回目の誕生日を迎えました。大人になったJavaScriptのこの1年を振り返ります。

ECMAScriptの進化

ES6/2015はJavaScriptの誕生以来、もっとも重大なアップデートでした。仕様策定まで7年もかかりましたが、ブラウザーとランタイムはついに、アロー関数、 let変数、const(定数)、プロキシーなど待望されていた機能に対応し始めたのです。ES6の互換性チャートは輝かしい緑色に変わりつつあります。

もし古いブラウザーもサポートするつもりなら、完全にES6に切り替えるのはおそらくまだ早いでしょう。「古い」とは、1年以上前にリリースされたブラウザーすべてが該当します。BabelのようなES6からES5への変換コンパイラーもありますが、ただでさえ複雑な開発手順にさらに追加の手順を加えることになります。

ES7/2016は、革命というよりは進化です。うれしい新機能の1つはasyncで、非同期通信のコードを同期通信のような方法で記述できます。コールバックやPromiseの構文の煩雑さ(相変わらず頭を悩ませています)から解放されます。

プログレッシブWebアプリ

2016年のJavaScriptベースの技術のうち一番のお気に入りはプログレッシブWebアプリ(PWA)です。PWAはグーグルのChromeデベロッパーサミット2015で発表されましたが、安定版とツールが提供されたのは2016年7月のChrome 52からでした。PWAはオフラインを重視した機能があり、いまひとつだったAppChacheを使う方法に取って代わるものです。ついにネイティブアプリと戦えるようになったWebアプリには、次のようなメリットがあります。

  • ホームスクリーンにアイコン設置可能
  • 高速起動とカスタムスプラッシュ画面
  • 実行速度の速さ
  • インターネット接続がない環境でも使用可能
  • URL、リンク、ブックマークが使える
  • フルスクリーンやUIのテーマ設定ができる
  • サンドボックス化された実行環境
  • ローカルまたはクラウドのストレージ同期
  • ファイル容量や使用リソースが少ない
  • より優れたセキュリティ(HTTPSの使用が前提)
  • どの検索エンジンからも見つけやすい
  • インストールする前に試せる
  • より単純なデプロイ(あくまでもWebアプリですので)
  • AppStoreなんてばかげたものがない:ヌードでも汚い言葉でも好きなように含められ、収益の30%を横取りされることもない!

とりわけ良いことは、どのWebサイトやWebアプリでも数時間あればPWAに変換できることです。手順は次のようになります。

  1. サーバーでHTTPSを有効化する
  2. アプリのマニフェストファイルを作る:アプリのルートに、アプリの名前、色、アイコン、表示オプションなどを定義したJSON形式ファイルを置く
  3. サービスワーカーを作る:ネットワークコールをインターセプトして、必要に応じキャッシュされたデータないし生のデータを返してくれるJavaScriptファイルをアプリのルートに置く

まだ初期段階で実例は少ないですが、PWAのおかげでWebアプリが「持ち歩ける」ようになるのはすばらしいことです。たしかに、アップルがPWAを採用する保証はありませんが、問題ではありません。オフラインで使えないだけで、SafariでもPWAのWebアプリは動くからです。また、AndroidでのWebアプリのユーザーエクスペリエンスがアップルをはるかに上回る状況になれば、アップルも採用を迫られることでしょう。

さらに知りたいならDev.Operaの『Progressive Web Apps: The definitive collection of resources』、グーグルのPWAガイドを参考にしてください。

フレームワークへの固執

偏りのない意見を述べるのは難しいですが、2016年もっとも注目を集めたフレームワークはReactでしょう。同意しない人もいるかもしれませんが、どのツールを使い、どのサイトを読んで、誰に話を聞いたかによって、意見は分かれますね!

Vue.jsは人気を高め、2016年9月にはバージョン2.0がリリースされました。

AngularJSは2015年のような勢いを失ったように思いますが、2016年9月のAngular 2のリリースで状況は変わるかもしれません。新バージョンは完全に作り直されたもので、バージョン1.0との後方互換性はありません。

新しいフレームワークやライブラリーにワクワクする一方で、10年以上経過したjQueryは依然として力を持っています。バージョン3.0が2016年6月9日にリリースされ、7月7日にはバージョン3.1がリリースされました。ライブラリーは新たにstrictモード、Promiseをサポートしており、修正も含まれています(全変更点のリストはアップグレードガイドを参照してください)。

JavaScriptを使ったWebサイトの96.4%にはjQueryが採用されています。これに対し「モダンな」フレームワークでは現在もっともよく使われているAngularでさえシェアは0.5%です。jQueryのバージョンは1.xがもっとも一般的で、採用事例のうち93.5%を占めています。バージョン2.xが6.0%、これに続きバージョン3.xは0.5%です。

私は開発者がよく考えずに全案件にjQueryを使うことには批判的です。もっと良い選択肢があったり、わずかな素のJavaScriptを書くだけで事足りるときでも、jQueryを使いすぎているように考えています。とはいえjQueryはほかのフレームワークよりも学びやすく、柔軟性もあります。ほかのフレームワークやライブラリーがjQueryをその座から引きずり下ろすのには何年もかかるでしょう。

APIの濫用

あぁ、Battery Status API。私が2013年に記事を書いた時点ではとても便利に感じました。アプリがデバイスのバッテリ低下を検知し、それに応じて通信と処理を最小化できたら、それに勝るものはないでしょう。

残念なことに、Mozillaの調べではこのAPIを使用しているサイトは約6%で、その多くは広告主です。彼らは、ある程度、個々のバッテリの状態を検出して追跡し、別のドメインに誘導します。ある種のサービスでは、ユーザーが窮地に陥っていることを察知して、値段を吊り上げることもあるでしょう。

JavaScriptやAPI自体の問題ではありませんが、Mozillaはプライバシーの観点からFireFox53からBattery Status APIを削除するという、前例のない手段に出ました。iOSデバイスでは表示されないでしょう。そして近接センサーBluetoothといったほかのAPIも、同じような理由でリスクを抱えています。これらAPIは実際に役に立つものだけに、とても残念です。将来のバージョンでこうしたプライバシーの問題が解決されるよう願っています。

新しいNode

年2回のNode.jsのバージョンアップ計画により、バージョン6.0が2016年4月、7.0が10月に登場しました。

W3Techsによれば、サーバー側での使用率はPHPの82.3%に対してNode.jsはたったの0.2%しかありませんが、このプラットホームは増え続けています。0.2%というのはちょっと誤解を招きそうです。なぜなら、Node.jsがインストールされていたとしても必ずしも検知されないからです。

どのサーバー側ランタイムもPHPに追いつく気配はありません。スタート時点で大きく先行したPHPは、ホストが持つべき実用的な機能をいまなお一番多く持っています。しかし、Node.jsは独自の道を歩んでおり、信奉している言語がさまざまな開発者からも広く受け入れられています。

Yarnのお話

私はnpmが好きで(『全部知ってる? npmを使いこなすために絶対知っておきたい10のこと』参照)、これこそがNode.jsのツールが普及した理由だと考えています。私はFacebookのような巨大プロジェクトで働いているわけではありませんが、手に負えないほどの問題に遭遇したことはありません。

Facebookのエンジニア達は2016年10月にYarnをリリースしました。npmよりも速くて、かつ安定するよう設計された、新しいNode.jsのパッケージマネージャーです。npmのレジストリに依存しているので、完全な互換性があるはずです。

Tim Severienの記事『Yarn:Facebook発のパッケージマネジャーはnpmに代わるスタンダードになるか』で、Yarnのなにが良いのかが説明されています。彼の結論には納得できます。

Yarnはnpmのフォークではないものの、npmが持っていたいくつかの欠点を改善しています。もしnpmがここから学んで、FacebookやグーグルやほかのYarnコントリビューターに対してnpm自体の改良を呼びかけ始めたら、すばらしいではありませんか。

フレームワーク疲れ

「もううんざりだ」という主旨の記事で、2016年のトップはJose Aguinagaの『How it feels to learn JavaScript in 2016』です。次点はdayssincelastjavascriptframework.comです。

この2つはJavaScriptの現状をユーモラスにとらえています。たしかに最新のトレンド、フレームワーク、推奨などに遅れずについていくのはますます困難になっています。開発者は検討すべき選択肢が多すぎて苦しんでいるのです。

私からのアドバイスはこうです。「ついていこうとするな」。そのようなことは不可能だからです。今日どのシステムに賭けたとしても、明日にはなにかもっと良いなにかに取って代わられます。いまのプロジェクトに役立つものを選び、可能な限り使い続けます。

確実なのものはたった1つ、JavaScriptそのものです。とにかく言語を学び、知識を増やしていくしかありません。経験によって各フレームワークの動きが分かるようになり、納得のいく選択ができるはずです。その選択とは、もしかしたらフレームワーク自体を使わないことかもしれません。

※本記事はJoan YinScott MolinariJulian Motzが査読を担当しています。最高のコンテンツに仕上げるために尽力してくれたSitePointの査読担当者のみなさんに感謝します。

(原文:JavaScript: 2016 in Review

[翻訳:西尾健史/編集:Livit

Copyright © 2017, Craig Buckler All Rights Reserved.

Craig Buckler

Craig Buckler

1995年に処女作としてIE2.0でページを作ったイギリス人のフリーランスWebコンサルタントです。以来、スタンダード、アクセシビリティとHTML5のテクニックの伝道者として活躍し、SitePointでは1000以上の記事を書いています。ツイッターのアカウントは@craigbuckler。

Loading...