JSエコシステムぶらり探訪(1): 原初のJavaScript

JavaScriptはWebブラウザの `<script>` から始まりました。まずはこの最も基本的な使い方を見ていきます。

[目次](https://qiita.com/qnighy/items/16fdd8e58309a1f706a0) [次→](https://qiita.com/qnighy/items/067dd47c48b96e772a4e)

## JavaScriptの実行モデル

モジュールの同期・非同期読み込みの話と関係するため、あらかじめJavaScriptの実行モデルを整理しておきます。

[JavaScriptはシングルスレッドです](https://html.spec.whatwg.org/multipage/introduction.html#serialisability-of-script-execution)。つまり以下のようなコードで、別のJavaScriptの処理の割り込みを受けません。

```javascript
window.counter = 0;
console.log(`counter = ${window.counter}`);
window.counter += 1;
// ←この位置で別のJavaScriptプログラムが実行されることはない
console.log(`counter = ${window.counter}`); // ←常に1になる
```

すでに多くのJavaScriptプログラムがこの仮定のもとに作られているので、これが覆されることはないでしょう。マルチスレッドによって実現したいことがある場合、かわりにマルチプロセス (Web Worker) と共有メモリ (SharedArrayBuffer) を組み合わせて使うのが現在の流れのようです。

JavaScriptの実行中は画面上の操作も全て止まってしまうため、**JavaScriptプログラムは連続して長い間実行されるべきではない**ことになります。これに該当するのは以下のような場合です。

- [`alert`](https://developer.mozilla.org/ja/docs/Web/API/Window/alert)/`confirm` などの古典的なダイアログ関数を呼び出した場合。
- 無限ループや、重い計算を実行した場合。
- [非推奨の同期的な`XMLHttpRequest`](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Synchronous_and_Asynchronous_Requests#Synchronous_request)を使った場合。

JavaScriptには (同期的な) sleep関数に相当するものが存在しませんが、これも同じような理由だと言えます。もしそういった関数があったとすると、1秒間ユーザーは何もできない、ということになってしまいます。

```javascript
// もし、同期的なsleep関数があった場合……
console.log("foo");
sleep(1000); // ←この実行中、他のJavaScriptコードは実行できない。ユーザーも画面を操作できない
console.log("bar");
```

この問題を回避するために、時間のかかる処理には同期的なAPIは使わず、非同期的なAPIを使うのが一般的になっています。たとえば上記のような(想像上の)同期的な `sleep` 関数ではなく、その非同期版にあたる [`setTimeout`]((https://developer.mozilla.org/ja/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout)) を使うと以下のようになります。

```javascript
console.log("foo");
// setTimeout自体は一瞬で終わり、1秒後に "baz" が表示される
setTimeout(() => {
  console.log("baz");
}, 1000);
// setTimeout自体は一瞬で終わるので、 "bar" はすぐに表示される
console.log("bar");
```

JavaScriptの視点からは、 `setTimeout` 自身はイベントハンドラを登録する処理にすぎないため一瞬で完了します。イベントハンドラが登録されてからイベントハンドラが実行されるまでの間に別のJavaScriptが実行されるのはおかしな話ではなく、それで期待しない挙動になってもそれはJavaScriptプログラマの責任です。そのため、ブラウザはこの時間に別の処理を遠慮なく実行できることになります。

このように「コールバックを登録する」という方法はタイマー処理に限った話ではありません。重い処理を分割するために0ミリ秒の `setTimeout` を行う手法も存在します。また、通信にも (上で挙げた同期版 `XMLHttpRequest` ではなく) 非同期的なAPIを使うのが一般的です。

```javascript
// 古典的な非同期XMLHttpRequest
var xhr = new XMLHttpRequest();
xhr.onload = function() {
  // ...
};
xhr.open("GET", "/example.json");
xhr.send();

// fetch API
fetch(new Request("/example.json"))
  .then(function(response) {
    // ...
  });
```

なお、 `XMLHttpRequest` や `setTimeout` のような比較的古いAPIはコールバックを指定するAPIを提供していましたが、このような非同期処理はプログラムが複雑化するにつれ[コールバック地獄](http://callbackhell.com/)に陥り、実際のロジックに対してコードの見通しが悪くなるため、ライブラリサポートである[Promise](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/Promise)や構文サポートである[async関数](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Statements/async_function)が導入されました。比較的新しい通信APIであるfetch APIもPromiseに基づいています。

## 原初のJavaScript

原初、JavaScriptはブラウザで実行するもので、モジュールシステムはなく、特に指定がなければグローバル空間に値が定義される仕組みでした。

```html:index.html
<!-- script.jsを読み込んで実行 -->
<script type="text/javascript" src="./script.js"></script>
<!-- HTML内に埋め込まれたスクリプトを実行 -->
<script type="text/javascript"><!--
alert("bar");
//--></script>
<noscript>JavaScriptを有効にしてください。</noscript>
```

```javascript:script.js
alert("foo");
```

ブラウザ上のJavaScriptには `window` という特殊な変数があり、グローバルな文脈で定義された変数や関数は `window` のメンバとして扱われます。 [^global-this] [^non-strict-mode]

[^global-this]: ブラウザ以外に目を向けると、環境ごとに `window`, `self`, `frames`, `global` など別の名前があったため、現在では統一的な名前として [`globalThis`](https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/globalThis) が導入されています。
[^non-strict-mode]: また、strictモードでない場合は `var`/`const`/`let`を使わない変数代入が可能で、この場合もグローバルになります。

```javascript
var x = 2;
function f() { return 3; }
console.log(window.x); // => 2
console.log(window.f()); // => 3
```

## scriptタグの同期的読み込み

原初のJavaScriptには [`document.write`](https://developer.mozilla.org/ja/docs/Web/API/Document/write) がありました。

```html
<script>
  document.write("<p");
</script>
>hoge</p>
```

この恐ろしい機能のため、ブラウザは `<script>` タグのJavaScriptの読み込みと実行が終わるまでHTMLのパースをブロックする必要がありました[^preload-scanner]。パースが進まないため、続くJavaScriptの読み込みや実行、画像の読み込みなど多くの操作も結果としてブロックされることになります。

[^preload-scanner]: 実際のところ、パーサーの挙動に影響のあるような出力が起こることは稀なので、[投機的なパースを行うpreload scannerという仕組みが存在する](https://www.igvita.com/2014/05/20/script-injected-async-scripts-considered-harmful/)ようです。

実際のところ、JavaScriptで行う多くの作業は、文書が全て読み込まれてから行いたいはずです。 (たとえば、 `document.getElementById("root")` は `<div id="root"></div>` が読み込まれた後に行いたいはずです。) こういった処理は次のように書かれることがありました。 [^dom-content-loaded]

[^dom-content-loaded]: [DOMContentLoaded](https://developer.mozilla.org/ja/docs/Web/API/Window/DOMContentLoaded_event)のほうが適切な場合もありますが、ここではより伝統的なonloadでの例を示しました。

```javascript
window.onload = function() {
  var root = document.getElementById("root");
  // rootを使った処理……
};
```

それならば、そもそも `<script>` タグを文書の最初のほうに置いてもスクリプトの実行開始タイミングには寄与しないことになります。むしろスクリプト以外の文書の構成要素 (HTML本体や画像など) のロードをブロックするデメリットのほうが大きいため、一時期は以下のように文書の最後に `<script>` を置くのが望ましいとされていました。

```html
  <!-- ... -->
  <script src="jquery.js"></script>
  <script src="script.js"></script>
</body>
```

## scriptタグの非同期的読み込み

上記の古い挙動はHTML5で改善され、 [`defer`, `async`, `type="module"` のいずれか](https://html.spec.whatwg.org/multipage/scripting.html#attr-script-async)[^defer-semantics-html4]が指定された場合にはパーサーをブロックしないようになりました。これらの関係は以下の通りです。

[^defer-semantics-html4]: `defer` はHTML 4.0の時点で存在しましたが、実行順序に関する詳細な規定は存在しませんでした。[Can I useの記述](https://caniuse.com/script-defer)を見る限り、これが実際に実装されたのもHTML5 (draft) の登場以降と考えてよさそうです。

- `type="module"` は `defer` を暗黙的に含む
- `async` は `defer` より強い
  - `defer` のほうが登場が古いため、 `async` を指定するときは `defer` も同時に指定してフォールバックを狙うことがある

asyncとdeferの違いについては省略します。

当然、これらの属性を指定した場合は `document.write` は使えなくなります。

scriptタグの非同期的読み込みに対応したブラウザでは、何を読み込むべきであるか早めに指定するほうが効率的であると考えられます。scriptタグは再び、文書の最初のほうに戻ってきました。

```html
  <!-- ... -->
  <script src="jquery.js" defer></script>
  <script src="script.js" defer></script>
</head>
<body>
  <!-- ... -->
```

## スコープを切る (IIFE)

原初のJavaScriptでは、せっかく `var` で変数宣言しても、それがグローバルスコープだったらグローバル定義になってしまうという問題がありました。

これを回避するために、[無名関数を作り、その中で作業をするというパターン (IIFE; 即時実行関数式)](https://developer.mozilla.org/ja/docs/Glossary/IIFE) が確立されました。

```javascript
var my_library = (function() {
  // my_libraryを作る作業
  // ここでvarを使っても、それ自体は外には漏れない
  return my_library;
})();
```

これにより、「1～2個程度のごくわずかな識別子をグローバルに定義する」という形のライブラリが登場するようになり、それまでのJavaScriptのあり方に比べてクリーンになりました。2010年～2015年頃に栄華を誇ったjQueryというライブラリ/フレームワークはその典型例です。 `jquery.js` を読み込むとグローバルに `$` と `jQuery` という2つの値が定義されます。 (この2つは同じものです)

このように1ファイルにまとめられたライブラリは、アプリケーションと同じサーバーにコピーして使われることもあれば、jsDelivrなどの公開サーバーにあるものを参照して使うこともありました。

この方法にはいくつかの欠点がありました。

- モジュールシステムとしては全く機能していませんでした (複数ファイル間の依存関係を記述できない)
- パッケージシステムとしては、各パッケージを1ファイルにまとめないといけないこと、間接依存を管理できないこと、またエクスポートする名前が衝突する可能性があること[^jquery-prototype]などが欠点としてありました。

[^jquery-prototype]: たとえば[prototype.js](http://prototypejs.org/)というライブラリとjQueryはどちらも `$` という名前をエクスポートしていて、両方を使おうとすれば必ず衝突する構造になっていました。

## JSmin

さらに遡ること2001年、Douglas Crockfordにより[JSmin](https://www.crockford.com/jsmin.html)が作られました。これはC言語で書かれた簡易的なプログラムで、入力JavaScriptコードから空白やコメントを除去することで、より文字数の少ない等価なJavaScriptコードを出力することができました。現在の[YUI Compressor](https://yui.github.io/yuicompressor/), [UglifyJS](http://lisperator.net/uglifyjs/), [Closure Compiler](https://developers.google.com/closure/compiler)に代表されるMinifier、そして「JavaScriptをJavaScriptに変換する」という考え方の源流であると言えます。

## まとめ

ここまでは全て、ブラウザ上の古典的な `<script>` タグだけでできることを述べてきました。この状況だけではこんにち見るようなJSエコシステムの飛躍的な発展は望めなかったかもしれません。少なくともこの段階では、モジュールやパッケージに相当する仕組みの萌芽は見られますが、間接依存やグローバル名の汚染などの問題は解決されていませんでした。

このフロントエンドの状況を覆す革新的な動きは、フロントエンドの外から始まりました。次回はその中心地ともいえるNode.jsについて説明します。

[目次](https://qiita.com/qnighy/items/16fdd8e58309a1f706a0) [次→](https://qiita.com/qnighy/items/067dd47c48b96e772a4e)