◆ Babel 使うと面倒も増える
  ◆ devtools で楽できない
  ◆ 設定とか準備
  ◆ Babel の知識がいる
  ◆ 他
◆ モダンブラウザはそのままの JavaScript でいいんじゃないかな
◆ ES6 の判定はとりあえず Symbol が綺麗で polyfill 影響受けないはず

最近 Babel 使ってみようか考え始めました

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()
}

何に対応していたら ES6 対応してるかの判断って難しいですよね
部分対応もありますし 全部確認していたらそれだけで無駄な待ち時間になってしまいますし

↑の例だと Symbol があるにしてます
Map などの polyfill ができる追加機能程度ならともかく Symbol 型みたいなちょっと特殊で polyfill できないのならそれなりに対応してるでしょうという判断です

Symbol はユニークな文字列を作ればいいので polyfill 作れなくはないですが typeof 演算子で "symbol" を返すことは本当に対応してる環境じゃないとできないはずです


少し前では ES6 対応判断に
function es6_available(){
try{
Function("a => 1")
return true
}catch(e){
return false
}
}
こんなのを使ってました
アロー関数があれば ES6 使えるでしょ という感じ
構文なので Map みたいなのと違ってそれなりに対応してるはずということだったのですが eval (Function()) や try catch があるのがなんかイヤで 遅そうな印象もあったので Symbol のほうが好みです

近いうちに試してみようかなー