2025/5/23(金)〜5/24(土)の二日間で、東京の神田で開催されたTSKaigi2025の参加レポートです。
このレポートではDay2で私が聴講したセッションの軽いまとめ＆感想と、全体の感想を書いていこうと思います！
ちなみにDay1の参加レポートはこちら...！！
TSKaigiって...？
TSKaigiとは、一言で言えばTypeScriptコミュニティのお祭りです。
世界一のオフラインのTypeScriptカンファレンスで、TypeScriptに関わる開発者、エンジニア、企業が一堂に会し、最新の技術動向、ベストプラクティス、事例共有などを行う場として2024年に始まりました。
タイムテーブル
Day2のタイムテーブルについては以下リンクの通りです。
「トグルルーム」「アセンドトラック」「レバレジーズトラック」の３つのステージがあり、それぞれでセッションがあります。(見たいセッションの時間帯が被ってしまった時は、涙を飲んで何のセッションを聞くのか決断する必要があります。)
聴講したセッション
TypeScriptネイティブ移植観察レポート TSKaigi 2025
by berlysia
「TypeScriptのネイティブ実装の移植について」のお話でした。
ネイティブ実装に移植することになった背景としては、JavaScriptは計算負荷の高いコンパイラの用途で使用するには限界があったため、Goへ移植するという内容でした。移植については、関数から関数へ１：１レベルでの移植が行われたそうです。
なぜ「移植」という選択肢を選んだのかについては、型チェッカーにとっては後方互換性が絶対という理由があります。古いバージョンでコンパイルできたものが新しいバージョンでコンパイルできなくなるのは困りますよね...。
Goを選んだ理由として、以下の条件をバランスよく満たすのがGoであったからという理由です。(スライドから引用)
- 関数＋データ構造での手続的な実装スタイルとの親和性
- ガベージコレクションをもち、循環参照を自然に扱える
- 共有メモリを用いた並列処理が自然にできる
- クロスプラットフォームにネイティブコードで動作する
ネイティブ実装の移植の背景について、いろいろ知ることができました。一番驚いたのは、移植にあたりAIベースの一括変換は使われていないという点でした。「自動変換→手動修正→テスト」の繰り返しで移植していったというところは非常に驚きました。プレビュー版も触ってみようと思います！
TypeScript Language Service Plugin で CSS Modules の開発体験を改善する
by mizdra
「CSS Modules の開発体験を改善するために」というお話でした。
CSS Modulesの欠点としてコードジャンプ等のエディタの言語機能が動作しないという点が挙げられました。言語機能は、エディタからLanguage Server(以降LS)を介して機能を提供しています。またLSは言語ごとに分かれており、TypeScriptのLSではTypeScriptの言語機能しか提供しておらず、言語を横断した機能提供ができていなかったという理由で、CSS Modulesはエディタの言語機能が動作しませんでした。
この問題を解決するために以下のようなVSCodeの拡張機能があるそうです。この拡張機能でTypeScriptとCSSの言語を跨いだ言語機能を使用できるそうです。
ただ、VSCodeの拡張機能であることからVSCode以外で使用することができないという問題点があり、mizdraさんが作成された「CSS Modules Kit」が紹介されました。(私も使用しております！)
CSS Modules Kitを構成している「ts-plugin」の仕組みについて説明がありました。TypeScriptとCSS横断の言語機能を実装についてはVolar.jsが使用されているようです。
実際に使用している「CSS Modules Kit」について色々知ることができ、大変勉強になりました。開発体験の向上において、こうしたツールの重要性を再認識する良い機会となりました。
複雑なフォームを継続的に開発していくための技術選定・設計・実装
by izumin5210
「難しいフォームに設計と技術選定で立ち向かう」というお話でした。
フォームライブラリ＋バリデーションスキーマの限界として、フォームが複雑になるとuseEffect()＋useState()などを使用する必要があったり、コードが壊れやすい状態になります。
コードを健全にするには「UIとロジック部分を分離すること」と「計算する必要がある場合は、状態ではなく値として扱うこと」といったことが重要であるとあげられました。MobXやJotaiなどを使用して、複雑なフォームを改善する例などが紹介され、私はフォームライブラリ＋バリデーションスキーマで戦ってきたので、目から鱗の知見を得ることができました。
またこのセッションは同意するところが非常に多く、首が取れるぐらい頷き続けました。
技術書をソフトウェア開発する - jsprimerの10年から学ぶ継続的メンテナンスの技術
by azu
azuさんが執筆している「jsprimerというJS入門書をどうやって作っている/更新してるのか、オープンソースと持続性」についてのお話でした。
印象的だったのが、「書きやすさより読みやすさを優先する」という話です。
- 既知の言葉で未知を説明する。
- まず既知の言葉を使ってコードの説明をした上で、コードを表示する。その後に補足を説明する。
-
textlintで文章校正、表現を統一する。
- 自然言語の文章を校正するためのツール。
私自身も定期的に技術記事などを書いており、どうしたら読みやすい記事になるだろうかと考えながら執筆しているのですが、azuさんの読みやすくする工夫を知ることができ、非常にありがたかったです。特にtextlintなどで、統一性の担保ができればちょっとしたミスなども防ぐことができるなあと思いました。
機能的凝集の概念を用いて複数ロール、類似の機能を多く含むシステムのフロントエンドのコンポーネントを適切に分割する
「複数ロール、類似の機能を多く含む複雑なシステム設計でコンポーネントを適切に分割する」というお話でした。
フロントエンドのコンポーネントについて、ロールごとに条件分岐するのか、コンポーネントごと分割するのかというところで、正解はないという前提のもと「ロールごとにコンポーネント分割する」を目指す、といった事例の紹介がありました。
- 論理的凝集
- 似たような処理をフラグや条件を切り替えて一つにまとめている状態
- コンポーネントの中で条件分岐が増える。
- 機能的凝集
- モジュール全体が単一の明確な目的のために構成されている状態
- ロールごとにコンポーネント自体分ける。
機能的凝集パターンの説明で「共通化したいなと思う、エンジニア的な嗅覚・直感」の話が印象的でした。見た目は同じコンポーネントだが、意味的には同じと言えないコンポーネントなどについて、コードを局所的に見て共通化したい！となっても、機能的な関連性をきちんと評価する必要があるとのことです。確かに、要件・デザイン・APIスキーマなどから総合的に判断する必要があります。
また論理的凝集に比べ機能的凝集の方が、コードのメンテナンス性が非常に高いという点があるといった一方、冗長な表現になりやすいというところはなるほどなあと思いました。また、共通化するというのはエンジニアの性みたいなところもあると思いますが、きちんと機能的な意味合いを考慮した上で行う必要があると改めて思いました。
"良い"TSのコードを書く為のマインドセット
by Kei
題名の通り「"良い"TSのコードを書く為のマインドセット」についてのお話でした。
「Soundness(健全性)」と「Usability(実用性)」のトレードオフを意識することが重要であるとのことです。
実用性を優先するとパフォーマンスを優先でき、健全性を優先すると堅牢性を得る代わりに、パフォーマンスを犠牲にするパターンがあるということで納得感がありました。TypeScriptだけでなく、ソフトウェア開発全般でこのマインドセットを活かしていきたいなと思います！
また、テーマが「TypeScriptと哲学的に向きあう」ということもあり、説明の中で三段論法でソクラテスという単語が出てきた時はびっくりしましたが、TypeScriptの文脈に落とし込まれていて、他では聞けないようなユニークで面白いセッションでした！
全体の感想
どのセッションも内容が濃く、登壇者の皆さんの熱量が伝わってきて、ものすごく刺激を受けました。普段の開発ではあまり意識できていなかった視点や、「そんな考え方・アプローチがあるのか」となるような知見が多く、自分の引き出しが確実に増えたと実感しています。
一方で、圧倒される場面も多く、「自分はまだまだだなあ」と感じることもありました。でもそれと同時に、前向きな気持ちも強くなり、いい意味でのエネルギーをたくさんもらいました。
そして何より、TypeScriptを軸に集まった人たちと「好き」を共有できる空間がとても居心地よく、楽しかったです。
最後に、膨大な準備を重ねて登壇された皆さま、そしてイベント全体を丁寧に運営してくださった皆さま、本当にありがとうございました。
最高のイベントを、ありがとうございました！
Discussion