書いたTypeScriptがブラウザで動く未来 (#85)

* update

* updte

* update

app/routes/posts/typescript-browser-support.mdx

@@ -0,0 +1,93 @@
+---
+title: "書いたTypeScriptがブラウザにそのまま配信する"
+description: "Node.jsのTypeScriptサポートが進んでいることで、ほぼ全ての主要なJavaScriptランタイムでTypeScriptが動くようになってきています。しかし、最も人気なランタイムであるブラウザでは、引き続きJavaScriptしか動作しません。ブラウザでTypeScriptを直接動かす未来はあり得るのか？その可能性と課題について、考えてみたいと思います。"
+date: "2024/12/19"
+updatedAt: "2024/12/19"
+path: "typescript-browser-support"
+published: true
+---
+
+[2024年 ユウトの一人アドベントカレンダー](https://adventar.org/calendars/9980)の19日目の記事です。
+
+## Intro
+
+Node.jsのTypeScriptサポートが進んでいることで、ほぼ全ての主要なJavaScriptランタイムでTypeScriptが動くようになってきています。
+しかし、最も人気なランタイムであるブラウザでは、引き続きJavaScriptしか動作しません。
+
+ブラウザでTypeScriptを直接動かす未来はあり得るのか？その可能性と課題について、考えてみたいと思います。
+
+## 前提
+
+Node.jsやDenoも、TypeScriptファイルを実行しているように見えて、最終的にはSWCなどのトランスパイラを使用し、JavaScriptにトランスパイルするようになっています。
+これは最終的に機械語に変換してくれるv8などのJavaScriptエンジンがJavaScriptしか受け付けないようになっているのと、そもそもTypeScriptはJavaScriptのスーパーセットです。
+
+そのため、以降の話も、「JavaScrtptにトランスパイルされる」ということは必須で考えていきたいと思います。
+
+## 現状
+
+現状のフロントエンド開発の流れをおさらいしておきましょう。
+モダンフロントエンド開発では、以下のようなステップが挟まっているかと思います。
+
+1. Transpile
+2. Bundle
+3. Minify
+
+トランスパイルでtsからjsに変換したり、jsの構文を最新のものではなく古い構文にしたり、jsxからjsにしたり色々します。
+
+そしてモジュールの読み込みコストを減らすために、バンドルします。
+
+最後に、不要なコメントやコードなどを少しでも減らすためにminifyします。
+
+これらが、現代フロントエンド開発における配信ステップかなと思います。
+
+## 課題
+
+筆者が考えるに、直接動作をさせるには、以下のような課題が生まれると思っています。
+
+- パフォーマンス
+- tsxの扱い
+- エンジン側の対応コスト
+
+### パフォーマンス
+
+ブラウザがNode.js同様、TypeScriptからJavaScriptへのトランスパイル処理を行ってくれたとします。
+フロントエンド開発で配信されるJavaScriptの量を考えた時に、ブラウザ側でTypeScriptのトランスパイル処理を行うのは非現実的かと思ってしまいます。
+
+そしてこの時、おそらくバンドルはWebpackなどのバンドラが行ってくれているはずなので、バンドルされたtsファイルの中には型注釈などがついていて、これをブラウザが側で除去するというステップが発生することになります。
+
+### tsxの扱い
+
+ここでさらに話をややこしくするのが、jsxです。Reactアプリケーションを使う場合、jsxを扱うと思います。TypeScriptなら拡張子はtsxですね。
+
+jsxも当然ですが、ランタイムのネイティブサポートは行われていないので、最終的にはJavaScriptのトランスパイルされます。
+ブラウザがjsxからjsのトランスパイルも行ってくれるとは思えないので、tsxの場合、わざわざtsxからtsにトランスパイルしたものをブラウザに送って、
+さらにブラウザがtsからjsにトランスパイルするって処理を行うことになります。
+
+それだったら、tsxからjsにトランスパイルしてそれを配信しちゃった方が楽じゃん。ってなると思います。
+
+### エンジン側の対応コスト
+
+tsxを間に挟んでしまいましたが、パフォーマンスの話に戻ると、JavaScriptエンジン側がTypeScriptをネイティブサポートするという選択肢はどうでしょうか。
+こうするとブラウザのトランスパイル処理は不要になるので、パフォーマンスの問題は突破できるはずです。
+
+しかしこれは当然ながら膨大な時間とコストがかかるのと、エンジン側からすると、型情報は必要ないので、不要なコストでもあるかもしれません。
+
+もっというと、TypeScriptはJavaScriptのスーパーセットです。おそらくTypeScriptが真に独立した言語にならない限りは、エンジンが対応することもないでしょう。
+
+## JSに型がつけばいいのでは？
+
+きっと誰もがN回思ったことでしょう。
+JavaScriptの構文はtc39によって、ステージが4になると格ブラウザがサポートを進めるようになっています。
+
+なので必然的に、型のサポートを進めればいいのでは？と思うかもしれません。
+実際、そういったプロポーザルは存在します。[https://github.com/tc39/proposal-type-annotations](https://github.com/tc39/proposal-type-annotations)
+
+ただもう動いてないので、やはり入らないんでしょう。
+
+## まとめ
+
+正直JSに型相当の機能が入るとは到底思っていないです。TypeScriptって立派なものがあるなら、もうそっちに頼ればいいじゃんっていうのも、至極当然な意見です。
+
+しかし、今の現代Webフロントエンド開発において、TypeScriptがなくてはならない存在になっていることも事実です。
+
+もしかしたらTypeScript相当の強力な型付き言語がブラウザで動くようになるかもしれないので、そういった未来を楽しみに、引き続き技術を向き合っていきたいですね。