ブラウザで動くほぼ唯一のプログラミング言語 JavaScript です

Web ブラウザ全盛の現在 JavaScript は数あるプログラミング言語の中でも 最も普及していると言っても過言でないです

Web サイトだけでなく サーバー・モバイルアプリまで その気になればなんでも作れてしまう汎用性と

ブラウザの開発者ツールをひらけば とりあえずすぐに動かせる手軽さで

初めてのプログラミング言語に JavaScript を選ぶ初心者の方も多いはずです

しかしこの JavaScript ブラウザ由来であるが故の制限や その複雑な歴史的経緯から 初心者が理解しづらいところが いくつもあります

この動画では これから JavaScript を触ってみようという人や ちょっとやってみたけど本格的な開発は わからない用語があってさっぱりわからないという人向けに 歴史的経緯に触れながら 現在の JavaScript を取り巻く環境をざっくり 紹介したいと思います

JavaScript の歴史

誕生

JavaScript が産声を上げた 1995 年 Web ブラウザは現在のように リッチな UI を持ったものではなく

文書を閲覧するだけの 今で言うとダウンロード機能付き PDF ビューワー のようなものでした

最初の JavaScript は当時使われていた Web ブラウザーの Netscape Navigator に組み込まれる形で実装されましたが

このときはまだ Javacript ではなく LiveScript と呼ばれており のちに Netscape 社と業務提携していた Sun Microsystems が発表して注目を集めていた Java の 人気にあやかる形で JavaScript に改名されました

こういった経緯もあり JavaScript という名前の商標権は Sun Microsystems そして現在ではそれを買収した Oracle 社が保有しています

翌年以降競合となる Web ブラウザー 特に Internet Explorer が JavaScript の導入を 進めますが Netscape 側がライセンスを発行しなかったため 独自実装となる JScript を組み込んで IE3 はリリースされました

これ以降多くの Web ブラウザーが JavaScript を導入しますが そのほとんどが独自実装の JavaScript だったため

あるブラウザでは動くけど他のブラウザでは動かない 文法が多くあるあることが問題となりました

この JavaScript の互換性の問題を解決するために JavaScript の共通の仕様を ECMA International という 標準化団体のもとで決めていくことになりました

この仕様は標準化団体の名前をとって ECMAScript と名付けられ 1997 年に初版が作られてから いくどかの改訂を経て現在でも使われています

なんで JavaScript の仕様なのに ECMAScript という 別の名前が使われているかというと 先に述べたように JavaScript の商標を Sun Microsystems が保有していたからというのが 理由の一つみたいです

成熟

HTML を補助するプログラミング言語として 導入された当初の JavaScript は カーソルをピカピカさせる程度のものでしたが

① JavaScript で動的にデータを取得する Ajax という技術が流行したこと ② 動的なページを作るのに広く使われていた Flash を iOS がサポートしなかったこと などの追い風を受けて 急速に成長していきました

一方で JavaScript を動かすブラウザもたくさん作られ シェアを取り合うブラウザ戦国時代となります

2000 年代には Windows OS に 同梱されていた Internet Explorer が 一強となりましたが

2008 年にリリースされた Google Chrome が 急激に市場を席巻し

現在では 50%以上のシェアをもつ Chrome Internet Explorer の次世代版である Edge MacOS や iOS に搭載されている Safari Netscape Navigator の流れを汲む Firefox が市場を寡占しています

これらのブラウザはもちろん すべて EcmaScript に準拠した JavaScript を実行することができますが

JavaScript を動作させるためのソフトウェア いわゆる JavaScript エンジンは それぞれ独自のものが使われているため

すべてのブラウザが最新の言語仕様や機能に 対応しているというわけではありません

そのため割と最近までこれらの差異をなくすための いわゆる Polyfill と呼ばれるライブラリが よく使われていましたが

特に対応が遅れていた Internet Explorer の 正式サポートが切れた現在となっては Polyfill を使う機会も かなり少なくなってきています

ちなみに JavaScript エンジンには それぞれ名前がついていて Safari のものは JavaScriptCore Firefox のものは SpiderMonkey Chrome のものは V8 と呼ばれています

Edge は Internet Explorer から引き継いだ Chakra と呼ばれるエンジンを使っていたのですが 2020 年から コア部分を Chrome と全く同じものに変更したので 現在は V8 を使っています

多様化

ブラウザの JavaScript が成熟していく一方で JavaScript をもっと色々な場所で使える ようにしようという動きも始まりました

その主役となったのが 2009 年にリリースされた Node.js です

Node.js は Chrome から V8 だけを 引っこ抜いてきて

ブラウザに存在しない 例えばファイル操作やプロセス管理のような機能を つけることによって

コンピューターの上で直接 JavaScript を使える ようにしたものでした

Node.js はすでに浸透していた JavaScript で書けて さらに当時話題になっていたクライアント 1 万台問題 をクリアできるという利点もあったため サーバーの開発言語として急激に広まっていきました

さらに Node.js を使ってデスクトップアプリを作る Electron や

JavaScript でモバイルアプリを作れる React native などが登場し

JavaScript は一気に多様化していきました

そんな Node.js が JavaScript の世界に持ち込んだ 大きな概念がモジュールシステムです

JavaScript はブラウザでは HTML の script タグに 読み込ませて使うものだったため

ファイルの分割という概念がほとんどありませんでした

大きくなりすぎたら別のファイルを別の script タグに 読み込ませればよかったからです

jquery などのライブラリを使うときも script タグで 読み込んでおけば問題ありませんでした

しかし Node.js ではそうはいきません 複雑なサーバーのロジックを一つのファイルに 閉じ込めるのはとても現実的でなく

またブラウザのように複数のファイルを 一つの HTML で使うこともできません

そこで Node.js は require という関数に ファイルパスを渡すことで 別のファイルの JavaScript を使うことのできる システムを導入しました

外部のライブラリは package.json というファイルに まとめて書いておくことで node_modules という フォルダに自動でダウンロードできて それらも同じように require できるようになりました

これらの仕組みは Node Package Manager 略して npm として Node.js に同梱されました

複雑化

Node.js に導入されたモジュールシステムが とても便利だったので これをブラウザの JavaScript でも使いたい という人が現れました

しかし当然ブラウザの JavaScript には そんな機能はありません

そこでモジュールに分けた JavaScript を 一つのファイルにまとめてしまって ブラウザでも使えるようにしてしまおう！ というツールが登場します

この複数の JavaScript をまとめて一つのファイルに するツールのことをバンドラーと呼びます

最も有名なバンドラーは Webpack ですが そのほかにも Rollup や parcel つい最近発表された turbopack などもあります

バンドラーの登場によってサーバー開発だけでなく フロントエンドの開発にも npm が 使われるようになり フロントエンドもサーバーサイドも npm を使った JavaScript で書くことが一般的になりました

しかしまだ厄介な問題が出てきます それが ESModules の登場です

Node.js で生まれたモジュールシステムは EcmaScript(さっき話した標準仕様)の 2015 年にリリースされたバージョンである ES6 に取り込まれましたが

Node.js の require キーワードを使った 記法ではなく 新たに import という記法を追加する形で 取り込まれました

こうして生まれた EcmaScript のモジュールシステムを ESModules それに対して Node.js に元々あった モジュールシステムを CommonJS Modules と呼びます

ESModules の方が新しく また標準化された仕様なので Node.js でも ESModules を使った書き方が 取り入れられ始めます

しかし当然 CommonJS を前提に作られた Node.js 上でそのまま ESModules を 動かすことはできないため

ESModules で書かれた JavaScript の ファイルを CommonJS に変換する トランスパイラというツールの利用が一般的になりました 最も有名でよく使われているトランスパイラは Babel です

このような経緯を経て JavaScript の開発は サーバーサイドの場合 ESModules で書いた JavaScript を Babel で CommonJS に変換して実行 フロントエンドの場合 ESModules で書いた JavaScript を Babel で CommonJS に変換し さらに Webpack でバンドルしてブラウザで実行 というスタイルで行われるようになりました

さてこれでようやく JavaScript の最近の開発スタイルに 追いつくことができました

色々と便利な補助ライブラリが出てきているので もしかしたらあまり意識しなくても JavaScript をかけちゃう場面があるかもしれませんが

最近の JavaScript 開発ではほとんどの場合この トランスパイル → バンドル まとめて「ビルド」というステップが行われています

ここまでで 書いたものを直接動かせるはずの JavaScript 開発が なぜこんなに複雑化しているかが なんとなくわかったと思いますが 最後に避けては通れない Typescript の話をしましょう

とその前に四方山話のコーナーです

四方山話

今日の雑談テーマは「WebAssembly」です JavaScript はブラウザで動くほぼ唯一の言語ですが 実は JavaScript 以外の言語を ブラウザ上で動かす仕組みがあります それが WebAssembly 略して WASM です

WebAssembly はざっくりいうと Javascript 以外の言語で 書かれたプログラムを ブラウザ向けに変換することで ブラウザでも動かせるようにしちゃおうぜ！ というもので

機械が直接読み取れるバイナリ形式なので 文字列を読み込んで実行しないといけない JavaScript と比べてパフォーマンスに優れる という特徴があり

また WebAssembly にさえ変換できれば C 言語や Rust で書かれたソースコードを そのまま動かすことができるため 過去に C 言語で書かれた多くのライブラリを そのままブラウザ上で使えるという 大きなメリットもあります

ただしこれは JavaScript に とって代わるためのものではなく あくまで JavaScript と併用するための 技術だとされています

これまでのような HTML を書き換えたり サーバーと通信するような処理は JavaScript で書いて 一部の重い処理や 既存の別言語の実装を利用したい場合に WebAssembly を使う という使い分けをしていくのが良さそうです

実際に Unity で作ったゲームを WebAssembly 向けにビルドして ブラウザで遊べたり デザインツールの Figma が 読み込みの重い処理に WebAssembly を 使っていたりなど すでに実用化されているケースも あるようなので 気になった人は ぜひ調べてみてください

Typescript の登場

Node.js や各種ツールのおかげで サーバーサイド フロントエンド アプリなど 多くの環境で使われるようになった JavaScript ですが

大規模開発に使われるようになるにつれて 言語仕様自体の貧弱さが問題になるようになりました

それを補うために ECMAScript に新たな文法が 導入されたり JavaScript 自体を置き換えるために Dart という 全く新しい言語が作られたりしましたが

各種ブラウザに組み込まれている JavaScript を 更新したり置き換えたりすることは容易ではなく 開発者が満足する言語仕様を満たすことはできませんでした

そこで JavaScript を置き換える代わりに トランスパイラ使って JavaScript に変換することで 機能を拡張した新しい言語が登場しました これらをまとめて AltJS と呼びます

CoffeeScript や Elm PureScript などそれぞれ特色を持った 多くの AltJS が登場しましたが

中でも Microsoft が開発した Typescript は 既存の JavaScript の文法をほとんど変更せずに 静的型付けが行えるということで大流行し 現在では多くの大規模プロジェクトで 導入されるようになりました

Typescript は Babel のように ESModules を CommonJS に変換する機能も備えていたため トランスパイラを Babel から Typescript に 置き換える、もしくは併用して ビルドされるようになりました

まとめ

歴史的経緯から複雑になった JavaScript 開発ですが 現在では Typescript をトランスパイラで JavaScript に 変換したあとバンドラを使って一つのファイルにまとめる という開発スタイルで一旦は落ち着いています

しかし Typescript を最終的に一つの JavaScript に まとめるという目的は同じでも 使いやすさや速度の改善のため 毎月のように新しいツールが出続けています

また Node.js の後継として Typescript を 直接実行できる Deno というツールが開発されたり

ブラウザがバンドルされていない ESModules を 直接読み込める Native ESM に対応し始めたりと

JavaScript を取り巻く環境は ずっと日進月歩で変わり続けています

追いつくのは大変ですが常に新しいものが 生まれ続けるのが JavaScript の醍醐味でもあるので 一緒に JavaScript の未来に期待しましょう

それではまた次回