ES6仕様のJavaScriptNodeJSを扱う際のメモリとActionScript3.0と連続性をもっているのは実はApple開発者ではないかと云う話。
1) ES6に取り組む
GatbyJS ベースでブログを構築する際タイミングでjavaScript記述方法をES6仕様に直しながら作業に取り組んだ(ES6仕様のサンプルがWeb検索で見つかりやすくなっているため)。
従来のJavaSript(ES5か?) と比べると以下の違いがあり、GatsbyJSのコードのコードを記述する際に参照したES6の記述方法は以下となる
- アロー関数による記述の簡潔さ、thisのルール整理
- let,const によるimmutable,mutable の明示&スコープの整理
- 文末セミコロンのオプション化
- モジュール周りの整理(require, import/export,export default)
- 分割代入
- テンプレートリテラル
- class
分割代入記法は慣れるのと当然のように使っているが名称を調べようとすると検索に引っかかららず難儀した。
Swiftとの類似性(SwiftがES6に寄せた)で分類すると以下となる。
| Swiftとの親和性 | メモ | |
|---|---|---|
| アロー関数 | あり | ブロック記述の省略化可能(Swift5.1) |
| let,const | あり | ビルド時の強力な型チェック(Swift) |
| モジュール周り | importはあるがES6と同意とはいえない | |
| 分割代入 | Swiftでは見ない記述方法 | |
| テンプレートリテラル | あり | Swiftだと"(変数)"で記述 |
| class | あり | Swift自体はStructが第一級定義 |
Swift自体がWeb開発者を呼び込むための方針がみてとれるので(10年来のiOSアプリ開発者の総数は増えない)、ES6との違いがあまりない点はむしろ驚かない。Swiftがclass を第一級の定義とはせずstructとするのはCocoa/Cocoa touch frameworkの頃のclass の概念から距離置いている体と思う。SwiftUIのような宣言的UIでもstructの仕様を強制することでOSⅩ以来のカオスな状況からの脱却を測っている。
2) classに挑みしES4
class が組み込まれたJavaScriptというのはES4というのが企画、提案(プロポーザル)された歴史がある。2006年のスマートフォン普及の前夜にclass が組み込まれたJavaScriptの魁というべきActionScript3.0が登場している、
2000年代前半の状況を2020年代から見ると奇妙な状況ではあるが、インターネットブラウザ上で動作するインタラクティブプラットフォームの覇権が争われていた。JavaScriptのポジションを当時の業界プレイヤーが奪い合っていたと言えば正しいだろうか。
2000年代前半の業界プレイヤーとしては2010年移行とは別の顔を持つMicrosoft(クライアントOSシェアで寡占状態)がWeb業界標準化をWindowsとすべく(この時点でよくわからない)Windowsネイティブコードをブラウザ上で走らせることでウェブそのものを骨抜きにしようと躍起になっていた。
1996年ごろに妥協点として生まれていたのがブラウザのプラグインとして実装されたFlashPlayerだった。バイナリーデータで提供されたアニメーションコードにインタラクティブなスクリプトを埋め込める機能が付加されてからクリエイターを中心に(マイクロソフトが期待していたプログラマ主体ではないのが重要)普及が始り2000年代はFlashPlayerの時代だった。
2006年にFlashPlayer利用拡大の野心を託されたActionScript3.0は発表された。当時企画、提案されたECMAScript4.0 を先取りしたものだった。
3) ActionScript3.0登場の背景
ActionScript3.0発表前、FlashPlayerは2つの問題を抱えていた。1つ目はa.クリエイターの指示はあるがプログラマには不評だった点、2つ目はScriptの処理速度の遅さだった。3つ目として深刻なセキュリティホールの数々があるが穴の開いたバケツをふなんとか塞いで由としたいたのかもしれない(2020年代におけるセキュリティーホール意識よりも2000年代は世間的な厳しさが低かった)。
これに対してFlashPlayerはActionScript3.0発表で解決策を示している。
- プログラマ向けに標準化(予定の)JavaScriptへの準拠
- JavaScriptからの中間コード生成
1は作り手をクリエイターからプログラマに重きを置くため非標準のScriptを破棄している。2はScriptを中間コードに変換しクライアント側での動作を高速化しようという取組だった。
中間コードについては少し話す事がある。ActionScript3.0は中間コードに生成にLLVMを採用していた。中間コード生成で得られるメリットは多々あるがメモリアクセス高速化の特殊命令を呼び出すと、C, C++のコードを組み込むは実現できている。
C/C++ のコードを ActionScript に変換する Adobe Alchemy を試す
スクリプト自体は遅いままだがスクリプトがアクセスするモジュールやバイナリアクセス用特殊命令と通してクライアントマシンにアクセス、高速化を図るという意図だった。
ActionScript3.0とiOSアプリには共通項がある。ActionScript3.0同様、Appleの開発ではLLVMベースのビルド環境が基本となっている(2020年)。
4) ActionScript3.0の意図
ActionScript3.0が動作するFlashPlayerはWebアプリケーションのフロントエンドやフィーチャーフォンのコンテンツ作成に期待されていた、Adobe Flexはその構想の一端だと思って良いしFlexは一部成功していた。
ActionScript2.0はそれ以前のActionScript2.0以前を切り捨てる行為であり、クリエイターが離れる要因となった。ES4はclassが目玉ではあったがブラウザ陣営の意見が合わず、その後白紙となりActionScrip3.0は取り残された。
それでも、FlashPlayer を動作させることができれば業界の変化に追随できるはずだった。
5) iPhoneのActionScript3.0への仕打ち
2006年はiPhone発売前夜である。iPhoneが2008年に開発環境を提供したことでアプリの時代が始まる。FlashPlayerでコンテンツを作るためのツールがOSⅩも使えたことからFlashコンテンツクリエイターがこぞってiOSアプリ開発に参入していった。
FlashPlayer自体はActionScript3.0を扱う開発者層を盾にiPhoneへの領土拡大を目指したが、Appleの当時のCEOであるスティーブ・ジョブスにFlashPlayer自体が全否定されてしまった。全否定とは、
- モバイルWebブラウザ(Safari)でFlashPlayerは動作させない
- ActionScript3.0ビルドベースのiOSアプリも申請却下する
で、FlashPlayerはiPhoneアプリ進出を挫かれてしまった(後にActionScript3.0ビルドベースは許可されている)。PCでは考えられないエネルギー効率の悪さ、セキュリティホールの多さをスマートフォンに持ち込みたくなかったなどの理由、Flashコンテンツ排除を狙ったなど憶測はいくつかあるが、事実としてはFlashPlayerはスマートフォンから締め出され2020年にFlashPlayerはWebからも消滅するという事実である。
中間コードの利点に目をつける、Scriptの標準化に合わせようとしたActionScript3.0は2020年を見れば的外れではなかったが、マイクロソフトが業界を歪めたなかで生まれた妥協の上に成り立っていたFlasdhPlayerが時代が変わり更なる強者Apple、Googleの登場でセキュリティ重視、業界標準の強力な牽引者で脆くも破れ去っている。
6) まとめ
技術的なつながりがFlashPlayer(ActionScript3.0)とApple開発者とであったり(LLVM)、Flashコンテンツ作成ツールが動いてたOSがOSⅩ(macOS)でクリエイター層が初期iOSアプリに流入してきたりといった流れが約12年(オリンピックイヤー4年分)で起きている。
UI周りの重鎮Appleが重い腰を上げて(四半世紀ぶり)SwiftUIを提供し始めたのは、Web開発者の総数に期待しているのだろう。
個人的な意見を述べれば、既存のiOSアプリ開発者を新参のクリエイター層で押し流す意図があると思うし、己が押し流されるがかどうかについて一度問い直し、くるべき状況に止まるか去るかを考えてみての良いかと思う。
