"BOKU"のITな日常

還暦越えの文系システムエンジニアの”BOKU”は新しいことが大好きです。

Webフロントエンド「モダンJavaScript」の技術動向をざっくり整理する

属に言う「モダン」なJavaScriptの話題には、やたらと略語や専門用語がでてきます。

この辺も都度調べるのではなく、いちおう理解しとかないとな・・ということで、ちょっと調べて整理してみました。

f:id:arakan_no_boku:20190412202924j:plain

 

整理の前提など

 

今回は、こちらの記事の続きです。

arakan-pgm-ai.hatenablog.com

なので、上記記事で整理したものは「Node.js」とかのように唐突に名前を出してますが、ご容赦ください。

 

ES5とかES6とか

 

さてと・・まず。

ES5とかES6とかES2015とかESModulesとか、やたらとでてくるESxxの件です。

調べてみると、このESというのは「ECMAScript」の略でした。

ECMAScriptは、Ecma International(エクマ・インターナショナル)という団体のTC39という専門委員会が策定するJavaScriptの仕様のことです。

Ecma Internationalの会員企業は、AdobeAMD、eBay、Google、HP、日立、IBMIntelコニカミノルタMicrosoft東芝Yahoo!・・などなど。

そこで検討される仕様案が「0(ただのアイディア)」~「4(仕様の策定が完了している)」までのレベル分けされて、レベル4だけがが、その年のECMAScript仕様としてリリースされるみたいです。

リリースされた仕様は、その年をつけて「ES2015」としたり、「ES5」とか「ES6」みたいに、Editionをつけて識別します。

つまり、「ES2015」は「2015年にリリースされたECMAScript仕様」ですが、その仕様のEditonは「6」なので、「ES6」とも呼ばれます・・ということみたいです。

その年度とEditionを対応表にするとこんな感じですかね。

Edition 主な変更
1 1997  -
2 1998 ISO/IEC 16262 international standard対応
3 1999

正規表現

try/catch例外処理とか

4 - 破棄されました。
5 2009

strictモード、getterやsetter。

JSONライブラリのサポート他

6 2015 クラス、モジュール機能(import/export)、イテレータ、for/ofループ、Pythonスタイルのジェネレータ、アロー関数、2進数および8進数の整数リテラル、Map、Set、WeakMap、WeakSet、プロキシ、テンプレート文字列、let、const、型付き配列、デフォルト引数、Symbol、Promise、分割代入、可変長引数他
7 2016

べき乗演算子(**)。

Array.prototype.includes他

8 2017 非同期関数 (async/await)、SharedArrayBufferとAtomics、String.padStart/padEnd、Object.values/entries、Object.getOwnPropertyDescriptors他

これを見ると「ES Modules」ってのが仲間外れっぽくなります。

が・・、どうも、これは上記のES2015(ES6)の「モジュール機能(import/export)」のことが独立して、そのように呼ばれているようです。

 

ECMAScript仕様の実装状況に注意が必要

 

ECMAScriptがリリースされたからといって、すぐ使えるわけではありません。 

ECMAScriptは単なる仕様にすぎませんから。

実装は各ブラウザ・実行環境(Node.js等)にまかされてます。

自分らがJavaScriptとして使うのは実装の方なのですが、その実装対応のスピードや仕様への準拠度合いなどはブラウザ・実装環境によって違います。

なので、同じ様に処理を書いても、ブラウザの種類やバージョンによって動いたり、動かなかったりという事態は、普通に発生します。

その対応状況を確認できるページがあります。

kangax.github.io

これで見ていくと。

ES6(2015)やES2016以降についても、Google ChromeFireFox、MS Edge、Safariの4大ブラウザの対応状況は良好です。

4大ブラウザの最新バージョンを使っている限り、モダンなJavaScript構文・機能が実装されてなくて動かないというリスクは低いです。

なんですが・・。

マイクロソフトInternet Explorer(IE) は問題大ありです。

IE11でも、ES5(2015)レベルで対応度「11%」・・つまり、ほぼ未対応で、それ以前(IE10以前)については表に項目すらありません(笑)。

マイクロソフトInternet Explorer の使用をやめて、Edgeに移行するようにとのアナウンスを強めてますから、これからも対応されることはないでしょう。

japanese.engadget.com

 

BabelとPolyfill

 

新しい仕様がリリースされてから、各ブラウザ・実行環境がその仕様を実装するまでに間が空く場合は当然ありますし、IE11みたいにES6(2015)に対応する気もない実装系もあります。

だけど、開発時はモダンなES6(2015)の機能や構文を使いたい。

そんな場合の対応として用意されている逃げ道は以下の2つみたいです。

  • Babelを使う
  • Polyfillを使う

ここでは簡単に言葉の意味合いだけ確認しときます。

 

Babel

 

新しい機能や構文で書かれたJavaScriptを、古い機能や構文で書いた形に変換してくれるトランスコンパイラというやつで、Node.js製のツールです

liginc.co.jp

引用すると。

Babelは、ES6で追加された機能をES5に変換するNode.js製のトランスパイラです。

ES6を書いても、現行ブラウザではきちんとコード通り動かないのですが、それをコードどおり動くようにブラウザでサポートしているES5に変換してくれます。

もともとの名前は「6to5」だったらしいです。

まんまです。

ただ、これは「ES5でも書ける(相当複雑だったりしたとしても)ES6の機能」を「ES5の機能・構文だけを使った形に書き直す」ものでしかなく、ES5では書くことができないES6の機能には対応できないということになります。

 

Polyfill

 

Babelで処理できない「標準となったメソッドが存在しない場合に、別途ライブラリとかで供給してしまう方法」がPolyfillです。

例えば、ES5には存在しない「promise」をIE11で動かすために、以下のPolyfillでにげたとか。

<script src="https://www.promisejs.org/polyfills/promise-6.1.0.min.js"></script>

同様に、ES5に存在しない「fetch」とかだと、以下のpolyfillが使えるよとか。

github.com

そんな感じで、この言葉は登場します。

これは、ECMAScript関連に特化した用語ではなく、そういう用途で共通して使われる単語みたいなんですけどね。

 

ちなみにIE11対応

 

今のところ自分はIE11を使う理由がないので、当面必要はないですが、ES6(2015)に関しては、こんな記事があります。

上記の事情で、自分は試してないですけど、とても実践的なので、IE11で困っている方にはいいんじゃないかと思うので、記事のリンクだけ載せておきます。

qiita.com

 

webpack

 

ECMAScript周辺の話とか、Node.js・Vue.jsなどのフレームワークの話とかは、なんとか見通しがついた。

そう思って、個別の記事を見ると、それらと一緒に、やたらと「webpack」という名前がでてきて、頭を混乱させてきます。

調べてみると。

このwebpackというのは「複数のモジュール(JavaScriptcssや画像など)を、ひとつに束ねるツール」だそうです。

JavaScriptの場合だと、複数ファイルに分かれているScriptを一つのファイルに集約(束ねる)してくれるツールということになりますね。

f:id:arakan_no_boku:20190419010949j:plain

何故、ひとつにまとめるかというと。

そうすることで、保守時の見通しがよくなったり、JavaScriptなどのロード時間を短縮できるなどのメリットがあるからみたいです。

このwebpackはバンドルする対象ファイルなどを設定ファイルに書いて動かすみたいですが、そこに「loader」を指定できるようになってます。

そこで、上記のbabelを動かす「babel-loader」を指定しとくと、ファイルをまとめる前に自動実行してくれるみたいなんですね。

なるほど・・。

これでつながりました。。

Node.jsをサーバーサイドで動かして非同期通信で処理するわけです。

そうすると、実行時のパフォーマンスにスクリプトファイルのロード時間は大きく影響します。

通常、複数回のリクエストを順番に処理するより、一発のリクエストでまとめて処理した方がパフォーマンス的には有利です。

HTTP/2なんかが、まさしくそういう理屈ですからね。

www.kagoya.jp

だとすると、複数のファイルにわかれている(=放っとくとと複数回のリクエストが発生する)ものを、webpackを使って、ファイルが一本化すると、やりとりやロード時間を高速化できるわけです。

しかも。

babel-loaderなどを指定しておけば、開発時はES2015(ES6)の機能・構文を使って開発していても、バンドルする際にES5の構文に変換してくれるので、実装が間に合ってなくて動かないというリスクも軽減できる。

さらに、そのへんの一連の動きを設定ファイルで自動化できるってわけです。

うーーん、確かに使わない手はないですね。

Node.jsとかVue.jsとかの話の中に、当たり前のように「webpack」が登場している理由は納得です。

 

ふーーー

 

この程度知っていると、モダンなJavaScriptに関する記事を読んでも、理解しやすくはなりましたし、ちょっと技術的な会話にも口をはさみやすくはなります。

まあ・・、今のところはこんなもんでしょうかね。

 

ではでは。