EcmaScriptの近い未来とそれから……

EcmaScript処理系のVMは近い未来にwasmをホスト言語としwasmにAOTコンパイルされた任意の言語をweb上で実行するための基盤となっていきます。

実装上はそのほうが都合がいいので今まで独自の内部表現と仮想マシン語(バイトコード)を利用していた部分をwasmに置き換える作業が実際に進行中です。これによりwebにおいてesは唯一の存在から選択肢の一つに降格されますが、そのような未来では既にコンパイル前の言語に問わずwasmモジュールをロードして利用することができるので実行中にコンパイル前の言語がなんであったかは気にする必要はありません。

これはffiではなくwasmという共通の内部表現を利用することにより実現されますが、wasmの将来の機能としてDOM統合が予定されているのでwasmから環境側にすでにあるAPIを利用することも可能になるかもしれません。

今はまだwasmの仕様の策定とasm.js相当のサポートとC/C++のコンパイル可能性についての作業が中心で、まだそのすべてを利用できるわけではありません。しかし、すでにコールドロードの恩恵を受けasm.jsよりパフォーマンスが良いという結果が出ているので、それはC++の1.3倍程度のパフォーマンスで収まっているasm.jsより良いパフォーマンスということです。

なにかとbenchmarkで引き合いに出されるC++との差がasm.js以上に縮まればもうパフォーマンス上の懸念は必要ないのではないでしょうか?

標準化のプロセスもwebにしては非常に珍しく一致団結し進んでおり、一部出遅れているベンダがいるものの順調のようです。wasmが利用できるのもそう遠くはないはずです。

ではwasmが利用可能になるとesは要らなくなるのか?

そうではありません。確かに選択肢の一つに成り下がれば、今までとは打って変わって相対的に必要性が下がるのは事実ですが、以下の2つの理由によりesはこれからも使われ続けます。

  • 依存関係にまみれてapiを呼び出すだけのコードしか書けない人々が山ほどいる
  • ブラウザベンダがプラグインを置き換えようとして、プラグインだけでなく拡張機能もweb標準のみで書かれるようになっていく

たとえwebアプリがnativeに敗れ、妥協案としてhybridと言われようが、webがnativeになるFirefoxOSがmozillaの方針で開発停止されようがこの二点がある限りesの注目がいきなりゼロになるわけではありません。

ブラウザに至ってはプラグインが本体を巻き込んでクラッシュするのをベンダが非常に嫌っており、ブラウザの拡張はプラグインではなくブラウザ nativeサポートかサンドボックス化された安全な拡張機能を利用する方向へと舵を切っていて、その中心はesから利用されるweb api達です。

このような流れは、firefoxを巻き込んでクラッシュする、ブラウザのサーフェイスに描画するとある3d関連のプラグインに怒ってブラウザ nativeで描画を拡張するためのMozzila labの一プロジェクト──のちのWebGL──が始まった頃から避けられない流れです。その後、のちのWebGLの誕生とプラグインを隔離してブラウザを保護するという流れになるのでflushの脆弱性とクラッシュが問題視される前から運命付けられていたことなのです。

ただし、開発環境とDevOpsやtoolingは、依存関係に依存するためのパッケージマネージャと裏でなにをやっているか把握しづらいタスクランナーといったビルドツールとは似て非なるものが中心のesとは比べ物にならないほど良いのと、00年代から流行りだしたesと違って各々の言語界の経験の蓄積があるのでそちらに分があるでしょう。

つまり、他言語が同じ土俵に上がってきたならば、言語機能の強化も然ることながら環境面の改善・拡充と開発者自身の向上が必要になるでしょう。

wasmによって支配的な立場が崩れ、今まで異質だった文化は通用しなくなり他言語界の良い所を吸収する機会がやって来たのです。これはwebの世界をさらに加速させるものかもしれません。

JavaScriptとECMAScriptの歴史

  • LineMode (browser)
  • 現代のbrowserの始祖にして初期のgraphical browserであるVioraWWW現る
  • NCSA Mosaic現る
    1. NCSAのライセンス販売でMosaicファミリ増大
      1. 元祖組み込みのspyglass MosaicやMS IE
  • 髪の毛生えてた頃の某犬の某お禿がティム・バーナーズ=リーに会う
    1. 彼の自前の回線を持つ野望はここから始まる
  • マーク・アンドリーセンらがNCSAの方針に反発してコードネームMozilla現る
    1. ちなみにMosaicキラーのgodzillaという意味。
  • サーバー側でページを動的に変更するとサーバーの負荷が高いのでクライアント側でやるという発想が生まれる
  • ブレンダン・アイクによってLiveScriptが突貫工事で作られる
  • NN2(たしか2だよな?)に実装さる
  • スクリプトを利用しクライアント側でページを変化させる構想をDynamicWebと呼ぶ
  • sunと提携してJavaの商標を使いJavaScriptとなる
  • MSのVBScriptが事実上失敗しjsをパクったJScriptが現れる
    1. さらにDynamicWebもパクり、今で言うDOM level 0部分を互換性のない形でパクリDHTMLと呼ぶ
      1. js(DOM)・JSS・layer要素の三本柱で構成されるDynamicWebと非互換なパクリのDHTMLの構図となる
        1. DOM標準化の発端
  • 開戦
  • W3Cに標準化を頼むが「てめぇら戦争止めてから出直してこい!」と門前払いにされる
  • ECMAに標準化を頼む
    1. 一方jsではその間に1.1~1.3までにあった古い仕様とlispやsmalltalkっぽい深い部分の黒魔術な仕様がほぼ廃止される
  • ECMAの標準化終わる
  • 大型アップデートjs 1.4現る
    1. ECMA-262に準拠した
    2. 標準準拠になった関係でjsとDOMの仕様が初めて分離される
      1. ただしspidermonkeyのString プロトタイプオブジェクトにあるHTML関連の関数は互換性のために長いこと残り続ける事になる。
    3. 1.3に残っていた黒魔術な仕様が全廃される(非推奨になっただけで一部使えたけど)
    4. WithオブジェクトにClosureオブジェクト
    5. 署名付きjavascript関係(セキュリティとimport/exportまわり)
      1. LiveConnectは当時、署名付きjsでのみ使えたが1.4の仕様が変更されたことにより署名付きjsが廃止され無条件でLiveConnectが使えるようになる
    6. server-side javascriptの強化
    7. 1.4時の拡張は後に全て廃止されることになる
  • javagatorプロジェクトで存在を忘れられていたrhinoが奇跡的に凍結をまのがれ存続する
  • 飛んでES ed 3
    1. 一方、jsは……
    2. 例外処理がspidermonkeyでstrict modeがrhino(逆?)
    3. getter/setterの仕様でspidermonkey大荒れ。rhinoは追従見送り
  • MSがJavascript 2.0に首を縦に振らない重大事案発生(運命の分岐点その1)
    1. その後もイチャモンをつけ続け頑なに拒み続けるが単に実装したくないだけ
  • netscape草案公開される
    1. adbeが20年くらい先走ってnetscape草案に触発されたAS3を作る
      1. netscape草案には多少似ているがES4とは全くの別物
    2. 有象無象がMSを盾に実装を拒んだためnetscapeとMSの代理戦争に発展。
    3. MSがJ/Directの件でゴスリンに怒られてC#を作り3E戦略から自分の作った仕様をよそのに標準化してもらう戦略へ変更
  • 日本でもようやくgoogleが正式サービス開始
  • 現在の基礎であるjs 1.5の登場でjs 1.4までの黒魔術な仕様がなかったことにされる
    1. とはいっても非推奨止まりで実装レベルでは残っている
    2. ついにgetter/setterの仕様固まる!
    3. const
    4. 例外処理
    5. ブラウザ環境にはないがstrict mode
    6. ここまではes3準拠とjsの独自仕様
  • js1.6以降はjs1.xで実現可能な部分のみのjs2.0/ES4の先行実装となる
    1. 実装された一部についてもconstなど仕様が違う
    2. multi catch guard(遠い未来のjavaにもあるアレ)のようにjs2.0/ES4の仕様に入らなかったものも
  • js2.0草案まだ纏まらず
    1. MSが件の戦略変更でjs2.0に飽きてきて落ち着き始める
  • 後のV8の存在を知ったブレンダン・アイク、「一緒に開発して標準準拠目指そうぜ!」的なラブコールを送るがV8側はES3にlanguage specificに最適化したかったため玉砕ス(運命の分岐点その2)
  • MS不在になったjs2.0/ES4実装するしない論争にV8を引っさげたgoogleがちゃっかり代理人の座につき、有象無象が更に増え代理戦争再開
    1. 実は停滞したjs2.0/ES4とは別に「せめて標準ライブラリの強化とモジュールだけでもなんとかしようぜ」とブレンダン・アイクが言い続けていたが反対派がモジュールの重要性を理解せず(「そういうことは外部ライブラリでやるべし」との意見が反対派の理由)その後10年程度進展なし。
  • この間にnetscapeがなくなり、(組織としての)mozillaがes4草案の策定を引き継ぐも反対派の意見を取り入れ二度ほど大幅に仕様変更される。
  • appleが表舞台に姿を現すが、独自拡張ばかりで3E戦略時代のMSの後を追う。
  • mozillaが仕様を作り、adobeが実装を作ることになる(運命の分岐点その3)
    1. 実装のVM部分はtamarin(デビルサマナーでお馴染みの斉天大聖のモデルのgolden tamarin由来)と呼ばれmozillaがes4用VM(おもにJIT部分のため)にadobeもes4ベースになる予定だった次期asの基盤に使う予定だった
  • 破滅の始まりES4 RI、満を持して登場!
  • ES4 RI芳しく無く
  • ES4 RIのあまりに質が悪くmozillaがVMとして利用する計画を白紙に、急遽TrackMonkey開発計画す
    1. 元々は標準ライブラリがself hostingされていてTracing JITされてウマーな予定だった
    2. ただES4 RIの実装がひどかったのでES4 RIの標準ライブラリはバグを回避するために型注釈は殆ど使われてなかった
    3. tracking JITの性能の証明は後にPyPyが行うことになる
      1. 今の流れのesはgradual typing出来ないのでtracking JITしても恐らくes4より速くならない。最近一部でgradual typingが再熱しているのはes4でやろうとしていた「(必要な部分だけ)一部をearly強い型付けして型推論簡単にしてJIT上手くやろうぜ」っていうのと同じ流れ。元々es4界隈の人らはgradual typing推していたので。結局今に至るのでこういう最適化は実現されたことがない。第一号はscalaかpythonかも知れない。
  • ES3.1現る
  • 現TC39クーデターを起こす
  • 標準化団体と標準化言語が分裂の可能性という未曾有の危機が訪れるがブレンダン・アイクが分裂の回避と標準化を優先しTC39に合流す
  • TC39、「巨大な変更はしない・minimum classesにする」と宣言する
  • ES3.1改めES5現る
    1. strict modeなど一部の標準化と小さな変更
      1. ただの付け焼き刃で本命はes6まで持ち越し
  • googleがconstの仕様に最適化を妨げると文句をつけ後に影響するが、最終的に一部元に戻るが、いわゆるlet bindingになってしまう。
    1. 実際の所、constが最適化出来ないのはV8をES3にガチガチに最適化しすぎたせいでそれ以外の仕様を上手く最適化出来ないだけでV8が最適化出来ないのはconstに限った話じゃない
      1. 当時、一番新しい実装にもかかわらずサポートする言語仕様が古いのはこのような経緯がある。V8も色々やっているので別に標準準拠の都合ではなく技術的なもの。
      2. 一部でgoogleが独善的と言われるのはgoogleは裏で広告がガリガリ重い処理してるのをユーザーに意識されずにやりたい的な話をイベントなどでしているにもかかわらずこういった自分の都合で仕様に難癖つける所のせい。
      3. それと、商売が下手でジリ貧だった頃の広告主義に変わる前の古き好きgoogleを知っている開発者や検索キーワード/演算子ガン無視して広告に都合のいい結果返すのを嫌煙する人に嫌われているのも。
  • ES6始動
  • 新たな仕様が入っては消え入っては消える
  • 議論が纏まらない部分は全部後回しにされる
  • 気付いたらes5までの仕様にも大幅に変更が入っているのでes5の存在意義が薄くなる
  • 後は細かい修正だけになる
  • 土壇場で性もない配列内包要らない論発生ののち後回しにされる
    1. ブレンダン・アイクまさかの賛成
      1. いや、netscape草案の頃から見てきたから高い下位互換を維持しつつ求められてる機能を導入することにとても注力し続けた人なのは本当によく知ってるけどさ、あのタイミングで作った本人が賛成しちゃダメだよね、あれ。だれがブレンダン・アイクを説得できるのさ?
  • ES6改め2015リリース!
  • 今後の仕様策定のプロセスが変更される
    1. championとstageという手法が取り得られchampionが提案し、仕様の煮詰まり具合でstageが進行し0から4まで上がるとTC39が吸い上げて議論される。
    2. これにより、githubにPRsすれば提案できるようになる

rhinoからnashornへ移行するためのjavascriptとecmascriptの仕様の差異と対処するために必要な情報と問題点を

最も大きな点はSourceElementが存在せず関数がExpressionStatementに直接現れることが出来、FunctionDeclarationであってもBindingIdentifieroptであることです。

また、この違いはesに準拠していなかった頃のie10以前やjavascriptの実装であるrhinoで確認できます。spidermonkeyはes準拠に舵を取りjavascriptの実装ではなくなったので元祖js実装では既に見ることが出来ません。以前のieがjsと同じ振る舞いをするのは単に標準には準拠していないがjsのパクリ言語であるJScriptだからです。

なぜSourceElementがあるのかはECMAが標準化する際に将来の拡張のため、Bkock直下の関数定義に特別な意味を持たせる余地を与えるためにあえて互換性のない仕様を採用した事に由来します。この関連でfunction definitionはFunctionDeclarationFunctionExpressionに分けられ、文である関数定義はFunctionStatementと定義されることになりました。

ここら辺の違いが理由でanba/es6の式クロージャの実装にはバグがあったりもするesのややこしい仕様の一つです。

またrhinoは少しずつes6の実装を進めているのでjsの仕様とは違う部分も出てくるかもしれません。さらにrhinoはes5が出た時にgetter/setterをes5準拠に、プロパティ記述子やその他の小さな変更に追従しておりjs1.8.5でありながらes5も利用できる状態にありました。なのでes5完全準拠でないにしても以前からes5のコードに問題がなく、その後始まったes6対応により、もしかしたらnashornよりrhinoの方が先にes6に対応している部分があるかもしれません。

なぜなら、es6のほとんどがes4から刷新された型システムの影響を受けない新たな言語機能の追加部分をサポートしており、元々es4の先行実装だったjs1.6以降をサポートしているrhinoと同じか、rhinoの方が進んでいる機能を利用可能だからです。

このためjsとes6で互換性のある構造化束縛やlet宣言はそのままでrhinoのために書かれたコードを変更することなくes6として動くという状況が生まれます。

しかし、es6で行われた互換性のない変更やes4の仕様のうちjsで先行実装されなかったがes6に含まれたspreadやrestやes5に含められなかったArray extraなどは元々rhinoで使えないものも含めて、es5実装であるnashornですら利用できません。

まとめるとjs1.8のフルスペックを駆使してrhinoのためのコードを書いているとes6相当かそれすらも超えるために、それらすべてをes5まで落とし込む必要があります。これは言語機能がes3に毛が生えた程度のes5水準まで落ちることを意味しているので、今後のメンテナンスや変更やscriptingそのものをrhinoの頃より大変にする弊害が出る可能性も念頭に置くことが必要になってきます。

さらにLiveConnectもサポートしていないためjavaとの通信はnashorn流に書き換えLiveConnectとの仕様の差異にも注意を払わなくてはいけません。これらに注意しながらoracleの用意した移行ガイドなどのドキュメントを読んで移行を進めていくことになります。

簡単に言うとrhinoからnashornへ移行するメリットは強力な言語機能か、今はまだない次期java9で実現されるパフォーマンスのトレードオフで決まります。

さいきんのbloggerが

Tracking cooike拒否すると投稿して編集画面の読込中から*また*先進まなくなった。