はじめに
こんにちは皆さん、素敵なエンジニアライフをお過ごしでしょうか？
自分はGithub CopilotとCursorに囲まれて幸せに暮らしています。
プログラミングといえばちょっと前までは、インターネットの奥底に眠る解決策を発掘する大変な作業でしたが、昨今はAIの発展によってとっても快適にコードが書けるようになりました。とっても素晴らしいことです。
しかしAIで幸せになりすぎた故に、そのありがたみを忘れてしまった存在がいるのではないでしょうか。
そう...TypeScriptのことを!!!!
今回の記事では、Webフロントの救世主(メシア)たる彼の歴史を振り返りつつ、その解決した問題の大きさを学んで行きましょう。
そもそもTypeScriptは何者
TypeScriptとはMicrosoftによって開発された、JavaScriptの上位互換言語(スーパーセット)です。
上位互換言語という言葉が表すように、TypeScriptはJavaScriptに対する互換性を持ち、そのすべての機能が利用できるようになっています。
その関係性は、SassとCSSだったり、C++とC言語、KotlinとJavaのそれに近いと言えるでしょう。
では、TypeScriptを上位互換たらしめる機能とは、一体何なのでしょうか。
それこそが...静的型付けの機能です。
TypeScriptとは名前の通り、JavaScriptに静的型付けを導入することを目的として開発された言語です。
変数や引数、返り値に型を指定することによって、JavaScriptは実行するまでコードの安全性が保証されないという問題を解決することができるようになりました。
なぜTypeScriptは必要とされたのか
TypeScriptを導入することは、JavaScriptに型という安全性を持ち込むというメリットがありますが、同時にそれはJavaScriptの柔軟性を殺すということでもあります。
ちょっとTypeScriptを書いてみるとわかりますが、いままでJavaScriptだと許されていた柔軟な書き方が許されなくなり、慣れるまではストレスが凄いです。(慣れてきても、初めて使うライブラリは型定義を理解するまでストレスフル)
しかしながら、そのようにJavaScriptの良さを失う結果になろうとも、エンジニアたちはWebフロントの世界に型による安寧を求めました。
それはなぜだったのでしょうか？ 歴史からその流れを学んでみましょう。
TypeScriptの歩んできた道
序章 JavaScript誕生
JavaScriptは1990年代にNetscapeによって、クライアントサイドで動くプログラム言語として開発されました。当時としては、JavaScriptはHTMLの補助的な役割を担う言語であり、あまり重要視されていませんでした。
第2章 Flash黄金時代
2000年代初頭、この時代にはJavaアプレットやAdobe Flashを利用したWebアプリケーションが台頭しました。こうした流れの中で、ブラウザで実行される言語の1つとしてJavaScriptにも注目が集まり始めました。
第3章 失われた10年
JavaScriptにも注目が集まると、徐々にJavaScriptで大規模開発がしたいという需要が生まれ始めました。そこでITの各ベンダー(Netscape, Microsoft etc...)が集まり、TC39という会合にてECMAScript 4(ES4)という言語仕様が議論されました。
そこでは以下のような機能が議題に上がっています。
- モジュール
- クラス
- 静的型付け
- Nullable型
- ユニオン型
- ジェネリクス
これらはまさしくTypeScriptによって導入された静的型付けと、それに関連する各種機能であり、20年も前からTypeScriptはエンジニアに待ち望まれていたと言えるでしょう。
ただ残念ながら、既存のJavaScriptとの互換性を持てないことからMicrosoftの反対もあり、ES4は中止となってしまいました。
第4章 黒船、Google Mapの登場
JavaScriptの進化が足踏み状態となり、大規模開発には耐えない言語であるというイメージが支配的な中、衝撃的な出来事が起こりました。
それはGoogle Mapの登場です。
Google MapはAjaxという仕組みを利用し、そのインタラクティブな操作性を実現していました。
AjaxとはAsynchronous JavaScript and XMLの略で、XMLHttpRequestオブジェクトという非同期通信の仕組みを提供するオブジェクトを利用し、XMLを非同期的にサーバーから取得し、HTMLの一部を書き換えることでリロード無しでの画面変更を実現しました。
これによりJavaScriptでも大規模アプリケーションは作れるという機運が高まることなりました。
第5章 一世を風靡するAltJS
Google Mapの成功により、ブラウザさえされば何もインストールする必要がないWebアプリケーションは、エンジニアたちにとってより一層魅力的なものとなりました。
2005年にJSフレームワークの先駆けであるPrototype.js、翌年にjQuery、2009年にAngularJS、2010年にBackbone.jsが発表されWebフロントエンドの流れが活発になっていきました。
そんな中、JavaScriptは静観の姿勢を見せ続けました。革新的変更をもたらすES4は頓挫してしまい、大規模アプリケーションの需要に答える変更が行われることはありませんでした。
そこでエンジニアたちは「JavaScriptにコンパイルできる言語を作ればよいのではないか」と考え始めました。そうした発想の中で生まれてきたのが、CoffeeScriptです。
CoffedeScriptはRubyのような簡潔な文法でコーディングができ、クラス指向を取り入れ、class構文を採用していました。
これがオブジェクト指向に慣れしたんだエンジニアたちの間で好評となり、Ruby on Railでもフロントエンド用言語として採用されることとなりました。
第6章 ついに動き出した真打
CoffieScriptが大成功を収めた一方で、2008年になるとECMAScriptに動きが生まれました。
一度は頓挫したES4でしたが、その革新的すぎる仕様を反省し、既存のJSとの互換性を保ちながらES4の一部仕様を採用するHarmonyという言語仕様が検討される事となりました。
Harmonyでは大規模開発に不可欠なmodule構文やimport/export、またclass構文などが議論され、その一部がECMAScirpt2015として採用されることとなりました。
こうしてECMAScirptを議論するTC39が徐々に機能するようになり、JavaScriptの将来性が期待されるようになりました。
第7章 TypeScriptの誕生
ECMAScript 2015の議論が白熱する中、2012年にTypeScriptは発表されました。TypeScriptの目的はますます困難化する大規模開発の改善であり、JavaScriptのスーパーセット、モジュール性、型を強調して開発が行われました。
TypeScirptは劇的な言語仕様の変更を行ったCoffeeScriptとは対象的に、JavaScriptの文法を拡張するに留めるスーパーセット言語の戦略を採用しました。
これにより、TypeScriptを導入したとしても既存のJavaScript資産を活用することができ、またチームメンバーの学習コストを抑えることもできました。
モジュール性はJavaScriptを利用した大規模開発において大きな利便性をもたらしました。特にコードを適切な粒度を分割できたり、実装をカプセル化したり、変数名や関数名が衝突しにくくなる仕組みを導入したりすることで、JavaScriptでの大規模開発を現実的なものとしました。
そして型はTypeScriptの最も大きな特徴です。型の恩恵としてコードジャンプやコード補完を可能にし、また型情報がドキュメントになることや、プログラムを動かす前にソースコードのチェックを行えるというメリットをもたらしました。
これらの機能を提供することにより、主に大規模なチーム開発において生産性を向上させることとなりました。
終章 TypeScriptとECMAScript 2015
このようにしてJavaScriptに大規模開発へ耐えうる機能を追加したTypeScriptでしたが、モジュール性はECMAScript 2015でも似た仕組みがJavaScriptに導入されたことでユニークな特徴ではなくなっています。
しかしながら、型の機能は依然としてTypeScriptに特有のものであり、依然としてTypeScriptは最も人気のAltJSとして確固たる地位を築いています。
まとめ
TypeScriptはかねてからあった、JavaScriptのスケーラビリティの課題へ対応するために生まれました。
その優位性はJavaScriptの進化により薄れている部分もありますが、依然として型を提供することによる、開発・運用上の優位性は失われていません。
結論
TypeScriptは型を提供することで、コード自体がドキュメントになる仕組みや、コード補完・型チェックといった大規模開発をするにあたって嬉しい機能をたくさん提供しています。
それによってJavaScriptだとすぐにコードが難読化し、変更不能・運用不能になってしまうという問題を解決しているということですね。