詳しくは割愛しますが、先日 TypeScriptのany型に対するスタンスでTwitter等で論争が起きるという事象が発生していました。TypeScriptはJavaScriptの互換性の点で、とても素晴らしい利点を持つ言語です。ただ同時に、JavaScriptの負債をモロに受けてしまうという点で非常に繊細な言語であるとも言えます。技術選定には、健全な理由と不健全な理由がそれぞれ存在し、それらを慎重に加味しなければ、不利益を被ることがあります。そもそもこのような論争が発生しながらも、無理して使い続けてしまうことが今回もっとも不健全だと強く感じました。
any型を持つTypeScriptを選ぶべき健全なケースとして次のようなケースが考えられます。JavaScriptの資産が多く残っており、徐々に移行を進めるというシチュエーションでは、any型を使い十分推論可能な部分から型を明示していくなどany型が十分活躍しany型 == 悪 ではありませんし、むしろ歓迎すべきポイントとなります。
逆に新規開発をする上で、TypeScriptを熟達した人間ばかりでなく、不用意にany型を使用してしまいJavaScriptと変わらないか、それよりも悪化してしまうようなケースを不健全であると感じます。もちろんtsconfigやeslintを使えばanyだけでなく他の罠を回避することができますが、キチンと設定しなければならない。せっかくのJavaScriptの自由さが損なわれてしまう。などの不健全さはすべて拭い切ることはできません。今回の論争を鑑みるに健全さをキープできない環境が多いのではないかと推測できました。
それでは、なるべく不健全さが生じない健全な言語の選び方に、どのような駆け引きがあるでしょうか？ 例えば、elmのようにany型が存在しない言語を選ぶこともできます。そもそも存在しないものに関して議論する余地は起き得ないのです。とても健全ですね？ もちろんすべてのケースにおいてelmが健全ではありません。どのようなケースにも不健全さは生じます。例えば、JavaScriptの資産を使うだけで運用し続けれてしまう場合には、わざわざelmを使わなくても良いですし、JavaScriptの資産を無理やり呼び出す(JavaScriptのコードを呼び出すports
という仕組みがあります)のは利点をかなり殺してしまいます。
以下、単なるelmの宣伝です。苦手な方はお気をつけください。
他、TypeScriptを使っていて不健全だと思い、Elmで解決できるという点を列挙したいと思います。
- 実行時エラーが起き、その度デバッガを見ている -> No Runtime Exceptions
- VDOMのパフォーマンスが気になる -> Great Performance
- package.jsonの管理が煩雑で、依存関係解決に工数がかかってしまう -> Enforced Semantic Versioning
- アセットサイズが重くなってしまう -> Small Assets
- コンパイル時間が遅い -> Compile Times
- エラー文章がわかりにくい -> 親切過ぎるエラーメッセージを届ける言語 Elm
- 機能が多くキャッチアップや教育に時間がかかってしまう -> all syntax, elm-guide
- 状態管理やMiddlewareのライブラリ選ぶに困ってしまう -> The Elm Architecture
- イミュータブルを導入するために特定のライブラリに依存してしまう -> elm core packages
- 複雑なフォームに対応できない -> フォームバリデーションからフォームデコーディングの時代へ
以上のどれかに多く時間を割いてしまった経験がある方は、是非elmを検討してみてください。学習コストを払うだけの価値は十分にあるはずです。WEBフロント開発をするときのデファクトスタンダードの一つとなることを願っています。少しでも不健全な状態が減ると良いですね！