ES6 が使えるかの JavaScript での確認方法
- カテゴリ:
- JavaScript
- コメント数:
- Comments: 0
◆ Babel 使うと面倒も増える
◆ devtools で楽できない
◆ 設定とか準備
◆ Babel の知識がいる
◆ 他
◆ モダンブラウザはそのままの JavaScript でいいんじゃないかな
◆ ES6 の判定はとりあえず Symbol が綺麗で polyfill 影響受けないはず
◆ devtools で楽できない
◆ 設定とか準備
◆ Babel の知識がいる
◆ 他
◆ モダンブラウザはそのままの JavaScript でいいんじゃないかな
◆ ES6 の判定はとりあえず Symbol が綺麗で polyfill 影響受けないはず
最近 Babel 使ってみようか考え始めました
Babel は altJS ですが JavaScript を書きます
ブラウザで対応していない機能でも実行できるように ES5 に変換してくれます
なので JavaScript が好きでわざわざ altJS なんて使う気がしない人でも使える良い altJS です
ただ Chrome や Firefox では ES6 はほぼ使えるようになったので ES7 以降の proposal も使いたいとか IE 対応しないといけないってときくらいしか使わなくてもいいと思います
そんなに気にしない人も多いですが デメリットもあります
なので 最新ブラウザからすると わざわざ古い形式に変換されているので無駄な処理が増えます
ES6 にあわせてネイティブなレイヤで最適化されているのに その処理を ES5 相当に置き換えて JavaScript レイヤで処理するようにしてしまえば JavaScript としての処理が増えて遅くなります
特に速度を優先したコンパイルをするわけではないみたいので少なくとも早くなることはなさそう
もしかしたらプラグインやオプションであるのかもしれないですけど
また ツールをひとつ通す分 そこでの問題や準備に時間がかかります
ちょっとコード書き換えるだけでも実行するためには再コンパイルするわけですから 一つ手間がいります
自動化するにしても最初はその設定をしないとですし 初めての人にはハードルが上がります
ブラウザだけですごくお手軽に動かせるのがウリな JavaScript 的には一気に難易度が上がるように思います
設定したのにうまく動かないとかなると かなり時間が取られてしまいます
また JavaScript 的には正しくても Babel の問題で動かない可能性もあります
どっちが原因かの切り分けも面倒ですし バグだとしたら Babel にあわせた特殊な書き方をしないといけない可能性があります
ネットに解決策がないような対処が不明な状態ですぐに動かせないと困る なんて状態になったら大変ですよね
通常の JavaScript ではそうそうないはずですけど Babel 程度のものだと やっぱりブラウザの致命的なバグよりは起きる可能性が高いでしょうし
そういう Babel ならではの知識が必要になってきます
それと devtools (開発者ツール) を使う場合の相性です
最近では devtools だけでコードも書けて ファイルやテキストの検索もできてデバッグもできて補完もされる と Chrome だけあれば IDE もエディタもいらないといってもいいくらいに高機能です
ですが 実際に動いているのは 変換済みのものですし 簡単に ES5 化できないジェネレータなどは読みづらいですし ステップ実行で問題を見つけても 元の JavaScript での修正に手間がかかります
map ファイルがあっても さすがに変換前のファイルを見て今の devtools のワークスペースのマッピングと同じようなことはムリでしょうし 直接ブラウザが altJS を実行しないかぎり devtools をメインに使う人には扱いづらいものです
ですが モダンブラウザでほとんどの ES6 が使えるようになったので モダンブラウザで動く ES6 までを使って
モダンブラウザ → そのまま
ES6 未対応ブラウザ → Babel 変換済み
にすれば楽じゃないかなと気づきました
Chrome などでは普通に JavaScript をそのまま実行できるので devtools 問題やパフォーマンスにもデメリットないですし普通に使えます
言い換えると Babel 使ってる感がないですけど
デバッグも済ませて OK になったら初めて Babel で未対応ブラウザ向けにコンパイルして未対応ブラウザで実行と別々にできます
Chrome で動いていてここでエラーだと Babel の問題とわかりますし ↑の問題がほとんど解決できてそうです
とはいっても ES6 未対応って IE くらいしかないような気もします
この使い方だと ES7 の proposal は使えないので IE 用ツールという扱いになりそうです
でも もしかするとモバイル系では ES6 未対応の主なブラウザが何かあるかもしれません
ところで Android の Chrome って PC の Chrome と同じ ES 対応状況なんだっけ?
何に対応していたら ES6 対応してるかの判断って難しいですよね
部分対応もありますし 全部確認していたらそれだけで無駄な待ち時間になってしまいますし
↑の例だと Symbol があるにしてます
Map などの polyfill ができる追加機能程度ならともかく Symbol 型みたいなちょっと特殊で polyfill できないのならそれなりに対応してるでしょうという判断です
Symbol はユニークな文字列を作ればいいので polyfill 作れなくはないですが typeof 演算子で "symbol" を返すことは本当に対応してる環境じゃないとできないはずです
少し前では ES6 対応判断に
アロー関数があれば ES6 使えるでしょ という感じ
構文なので Map みたいなのと違ってそれなりに対応してるはずということだったのですが eval (Function()) や try catch があるのがなんかイヤで 遅そうな印象もあったので Symbol のほうが好みです
近いうちに試してみようかなー
Babel は altJS ですが JavaScript を書きます
ブラウザで対応していない機能でも実行できるように ES5 に変換してくれます
なので JavaScript が好きでわざわざ altJS なんて使う気がしない人でも使える良い altJS です
ただ Chrome や Firefox では ES6 はほぼ使えるようになったので ES7 以降の proposal も使いたいとか IE 対応しないといけないってときくらいしか使わなくてもいいと思います
そんなに気にしない人も多いですが デメリットもあります
Babel のデメリットって
Babel というものを通して変換された JavaScript をブラウザが処理しますなので 最新ブラウザからすると わざわざ古い形式に変換されているので無駄な処理が増えます
ES6 にあわせてネイティブなレイヤで最適化されているのに その処理を ES5 相当に置き換えて JavaScript レイヤで処理するようにしてしまえば JavaScript としての処理が増えて遅くなります
特に速度を優先したコンパイルをするわけではないみたいので少なくとも早くなることはなさそう
もしかしたらプラグインやオプションであるのかもしれないですけど
また ツールをひとつ通す分 そこでの問題や準備に時間がかかります
ちょっとコード書き換えるだけでも実行するためには再コンパイルするわけですから 一つ手間がいります
自動化するにしても最初はその設定をしないとですし 初めての人にはハードルが上がります
ブラウザだけですごくお手軽に動かせるのがウリな JavaScript 的には一気に難易度が上がるように思います
設定したのにうまく動かないとかなると かなり時間が取られてしまいます
また JavaScript 的には正しくても Babel の問題で動かない可能性もあります
どっちが原因かの切り分けも面倒ですし バグだとしたら Babel にあわせた特殊な書き方をしないといけない可能性があります
ネットに解決策がないような対処が不明な状態ですぐに動かせないと困る なんて状態になったら大変ですよね
通常の JavaScript ではそうそうないはずですけど Babel 程度のものだと やっぱりブラウザの致命的なバグよりは起きる可能性が高いでしょうし
そういう Babel ならではの知識が必要になってきます
それと devtools (開発者ツール) を使う場合の相性です
最近では devtools だけでコードも書けて ファイルやテキストの検索もできてデバッグもできて補完もされる と Chrome だけあれば IDE もエディタもいらないといってもいいくらいに高機能です
ですが 実際に動いているのは 変換済みのものですし 簡単に ES5 化できないジェネレータなどは読みづらいですし ステップ実行で問題を見つけても 元の JavaScript での修正に手間がかかります
map ファイルがあっても さすがに変換前のファイルを見て今の devtools のワークスペースのマッピングと同じようなことはムリでしょうし 直接ブラウザが altJS を実行しないかぎり devtools をメインに使う人には扱いづらいものです
両方つかえばいいのか
そんなこともあって 気軽に Babel にしようとはいかないですですが モダンブラウザでほとんどの ES6 が使えるようになったので モダンブラウザで動く ES6 までを使って
モダンブラウザ → そのまま
ES6 未対応ブラウザ → Babel 変換済み
にすれば楽じゃないかなと気づきました
Chrome などでは普通に JavaScript をそのまま実行できるので devtools 問題やパフォーマンスにもデメリットないですし普通に使えます
言い換えると Babel 使ってる感がないですけど
デバッグも済ませて OK になったら初めて Babel で未対応ブラウザ向けにコンパイルして未対応ブラウザで実行と別々にできます
Chrome で動いていてここでエラーだと Babel の問題とわかりますし ↑の問題がほとんど解決できてそうです
とはいっても ES6 未対応って IE くらいしかないような気もします
この使い方だと ES7 の proposal は使えないので IE 用ツールという扱いになりそうです
でも もしかするとモバイル系では ES6 未対応の主なブラウザが何かあるかもしれません
ところで Android の Chrome って PC の Chrome と同じ ES 対応状況なんだっけ?
ES6 対応かの分岐
[loader.js]if(typeof Symbol === "function" && typeof Symbol() === "symbol"){
loadDirect()
}else{
loadCompiled()
}
loadDirect()
}else{
loadCompiled()
}
何に対応していたら ES6 対応してるかの判断って難しいですよね
部分対応もありますし 全部確認していたらそれだけで無駄な待ち時間になってしまいますし
↑の例だと Symbol があるにしてます
Map などの polyfill ができる追加機能程度ならともかく Symbol 型みたいなちょっと特殊で polyfill できないのならそれなりに対応してるでしょうという判断です
Symbol はユニークな文字列を作ればいいので polyfill 作れなくはないですが typeof 演算子で "symbol" を返すことは本当に対応してる環境じゃないとできないはずです
少し前では ES6 対応判断に
function es6_available(){
try{
Function("a => 1")
return true
}catch(e){
return false
}
}
こんなのを使ってましたtry{
Function("a => 1")
return true
}catch(e){
return false
}
}
アロー関数があれば ES6 使えるでしょ という感じ
構文なので Map みたいなのと違ってそれなりに対応してるはずということだったのですが eval (Function()) や try catch があるのがなんかイヤで 遅そうな印象もあったので Symbol のほうが好みです
近いうちに試してみようかなー