TypeScript vs JavaScript
前にも軽くTypeScript触ってアプリを作ったけど個人的にいまいち踏み込めないでいるのでそのもやっとした感覚の言語化
5000兆回くらい言われてるだろうけど
以下の記事に考え方が近かったかもしれない
要は型システムというのは生産性やバグの検出をするために多少よく働いてくれるが本質的ではないという点だ
それより本質的に重要なのはテスト（TDD）でコード自体でコードの動作を保証することであり、これは型があろうがなかろうがどの言語でも変わらない
というのもそもそも現実的に発生するバグというのは8割方spec missでありtype missではないからだ
型があろうがインピーダンスミスマッチし仕様を分かっていなければいくらでもバグは生まれる
spec missは原理的に型で防ぐのは不可能で正しく仕様を把握するしかない
そのためにコードをコード自体で動作保証するというのが有効なのは隠れた仕様上のミスも拾い上げてくれるところで、ある引数とその出力のテストをするなら引数を色々変えて負数にしたりnullにしたりといったテストをテストを書いていく中で思いつく
そのイテレーションの繰り返しの中で仕様に対する理解が深まりこの仕様は本当はどういった入力値が必用でどういった入力値を防がなければならないのかといったバリデーションも思いつく
型安全ということをビジネス価値として訴求出来るポイントのように語られるけど実際はTSでやり直すことでリプレイスの機会が発生しビジネス価値をそこまで説明しなくても負債を返上出来るという点でポジショントークのように語られることが多いような気がする
JS自体がそれなりにMatureな言語になってきておりTypeScriptのフィードバックもあってツーリング周りが強力になっているというのも大きい
ESLint, VSCodeで型推測もTypeScript程までとはいかないもののかなりの程度検出してくれる
行儀の悪いコードもESLintルールのプリセットで拒否出来る
変更のないlet, 再束縛されるconst等
eslintが重要なのはこういったopinionatedだけど洗練されたベストプラクティスルールをまとめたことでありstylelint等他のツーリングへも影響を与えた
言語ランタイム自体での型の弱さを補完するためのツーリングであり個人的にはランタイム自体で保証するより静的解析で保証する方が拡張性といった点で有利ではないかと思う
ランタイムレベルでの型保証はコンパイル出来ないことであるがCIと静的解析を通じたCI/CD環境により似たことは既に可能になっている
サーバサイドでの動的型(PHP, Ruby等)では比較的昔からCI/CDはやってきたがフロントでのCI/CD環境も整ってきている（Headless Chrome, Cypress, Jest等）ので型システム自体の恩恵を受けることはWebにおいてはあまり少ない
結局Microsoftの問題を解決するために生まれた言語なのではという感覚が常にある
汎用的な問題解決というよりはMicrosoftというBig Techカンパニーで新しく開発者目線で開発体験を更新しようとした時にどういった言語が必用だったかという状況で2012年当時の選択肢としてJSはAltJS真っ盛りな中どれも採用するには至らず言語を開発することだったというのはMicrosoftという環境だったからだと思う
.NET FrameworkといったランタイムのためにC#が生まれたようにそもそもMicrosoftにはあるソリューションを開発するために一から自分達で言語を設計するという選択肢があった
これは巨大なテックカンパニーになるにつれて重要になる選択肢であり、ビッグカンパニーが抱える問題はそもそもスタートアップといった少人数での開発とは全く論理が異なり、One-fit-Allなソリューションは常に存在しない（銀の弾丸は存在しない）
big companyになるほどスケールメリットが生まれ自分たちが100％コントローラブルなツーリングチェインを生み出すということは重要になる（政治的にも）
90000人の開発者を抱える会社が抱える問題というのはただ単にサードパーティのOSSを導入すれば解決するというようなレベルではなくむしろ自分達の問題に最適化されたツールチェインを生み出すことにある
そういった上で政治的に有利な状況を生み出すためにエコシステムを生み出すというのは長期的に見ればROIが大きい
型によるtype missを防ぐだけでバグ検知率が2割上がるなら十分投資対効果は見込める
VSCodeのためだけに生まれた言語であり前提条件を単純にしてしまえば90000人で同時にNode.jsネイティブなエディタを開発するためには何が必用か？と考えるとTypeScriptということだったのかと思う
MSで大量に抱えているC# DeveloperをJSランタイムでも違和感なく作業してもらうため, つまりJSランタイムにおけるC#を作るためにTypeScriptが必要だった
そういった点で常にTypeScriptはVSCode以外のソリューションとしてはオーバースペックで有り続けるような感覚を持ち合わせている
繰り返しになるがOne-size-fits-Allなソリューションは存在しない
だからこそMicrosoftもVSCodeのためだけに言語を開発したのだろうしそれだけVSCodeに賭ける思いが強かったということだ（そして文字通りMicrosoftは復権し開発者のためのテックカンパニーとして存在感を増した）
JSとの後方互換性を維持するといったのもVSCodeを開発するために必用であったからでここももやっとする
結局ランタイムは同じでV8エンジンもしくは既存のNode処理系のため根本的なランタイムが抱える問題などを解決するためのソリューションではない
JSエコシステムをほぼそのまま使えるといったことは利点にもなるが結局TSからJSにトランスパイルすることには変わらずそれぞれのJS処理系が対象としている問題領域は変わらないのでJSが向いていない領域では使いづらい
切り捨てるならスパっと切り捨ててほしい感はある
Denoのように
最近DHHがTypeScriptをTurboからDropしたことでやや再燃しつつある話題
その決定に対してTypeScript Crusaders (TypeScript十字軍）がリポジトリを荒らすということが発生
少なくともリポジトリオーナーの決定である以上何を使おうが自由なはず
MicrosoftはTypeScriptの熱烈な信奉者の形成には成功しているようだけど他の言語に切り替えただけでその決定を貶めるようなコミュニティの汚点になるような行為は諌めるべきだと思う
結局DHHの TypeScript is JavaScript! という発言に尽きる気はする
JavaScriptのSuper Setに過ぎないからJavaScriptの問題は解決出来ているわけではないし、型で防げる問題は全体の2割程度
Turboにおいてはそれよりも設計に注力したり、distribution時にトランスパイルで問題が発生しないようにポータブルにしたり、テストを拡充してspec missを減らすなど他にやることはいくらでもある中、型パズルをするという優先順位が低かっただけにすぎない