TypeScriptを使ってみて「使うべき」と思った話

TypeScript Electron NodeJS

最近、ずっとブログを休んでいましたが、そろそろ再開。ただ、以前のような話は少なくなる見込みです。

個人的にTypeScriptとElectronでアプリケーションを書いています（Eto.Formsもいいのですが、プラットフォームごとの挙動の違いの扱いがつらいところです。GUIがシンプル、かつ、マルチプラットフォームでも主な対象がWindows、というケースなら向いていると思います）。

とりあえず、今回はポエム的に印象だけさらっと書いておきます。

開発の流れを作るのが本当に大変

JavaScript界隈のほとんどで言えることですが、開発で使う要素が非常に多く、なおかつ頻繁に変化しているため、基本構造や開発フローを作るのに苦労しました。

Electronも、TypeScriptとElectronの組み合わせも、サンプルはたくさんあるのですが、公式サンプルとあまり変わらないシンプルすぎるものか、特定のフレームワーク（ReactかAngular）に強烈に依存するものがほとんどと感じました。

自分の場合、少なくとも数年間、片手間で（仕事でも重要な趣味でもなく）メンテナンスを続ける、という前提で考えているので、頻繁に構成要素が更新されると追従コストがあふれてしまいます。また、データ構造はシンプルなもので、（追従コストを考えると）フレームワークは使わない方がいいと判断しました。

とりあえず数か月前に検討した結果、現状は次の形で動かしています。

  • 開発用のNode.jsは、WindowsではNodistを利用して管理
  • ビルドなどはnpm script
  • tsからjsへのトランスクリプトはtsc
    • webpackなどでの一括ビルドは回避：ツールチェインの変更がしんどいのと、jsになった結果が簡単に分かった方が問題を切り分けやすいため
  • jsはwebpackで結合とuglifyをかけて、main.jsとrenderer.jsを生成
    • webpack内でbabel-loaderを利用
  • jQueryとjQuery UI（両方ともjQuery UIのDialogだけが目的）はビルド後の領域に直接配置（npm管理外）
    • TypeScriptからは@typesで型定義のみ利用
    • DOM操作はDialog処理以外は（Dialogの中身も含めて）jQueryは使わず、素のTypeScript（Vanilla TS？）で操作

これでも開発用Node.jsとnpm、ビルド用のTypeScriptとwebpackとbabel、動作用のElectronは比較的更新が頻繁ですし、それぞれ動きは別なので、十分負担です。特にビルド周りは、近いうちに見直したいと思っています。

ここにNodeで使えるサードパーティのライブラリやrenderer側のフレームワークなどが加わると、個人が片手間に追従するのは厳しいのでは、と感じてしまいます。業務などで重複する領域を扱っていれば、追従の手間はそちらに投げられるのでしょうけど。

TypeScriptは段々楽になる

最初は、TypeScriptだと面倒と感じるシーンもありました（「JavaScriptなら簡単なのに～！」という気持ち）。しかし、使い続けると、むしろ楽に感じられてきました。

「自分で書いた領域が型つきになることで自動的な型チェックが済む」ことはよく言われますが、加えて、既存ライブラリ（NodeやElectronの標準APIも含めて）を使う上でも便利です。引数や戻り値の理解（やドキュメント記述）が不十分な部分は、TypeScriptのコーディング自体で詰まりやすく、結果的に早期に対処できるので。

もちろん型チェックは完璧ではありません。Electronだと、例えばmainとrendererを接続するIPCでは、引数チェックが途切れます。誤解していれば簡単にバグります。

それでも、危ない箇所は見当がつきやすいため、かなり落ち着いた気分でコードが書けます。正直なところ、素のJavaScriptでいきなり書くのは避けたいな、と思う程度にはTypeScriptが気に入りました。

VSCodeはVSじゃない

不満は、VSCodeです。自分が見かける範囲では非常に評価が高いのですが、Visual Studio上でC#のコードを書いてIntelliSyncの恩恵を最大限享受できていた自分が比べると、VSCode上でのTypeScriptは、ちょっと微妙です。

最も不満なのは、入力中の補完候補の表示が途中までしか出ないこと。

f:id:mokake:20180704183416p:plain

マウスカーソルをあてた状態ですら先が見えません。引数も戻り値も（確定しないと）見えないので、補完候補を活用したコーディングはしづらい、という印象を受けます。「IDEじゃなくてエディタだから」といっても、「フォーカスのあたった候補はシグネチャを全部表示する」ぐらいはやってくれても……と思ってしまいます。

まあそれでも3プラットフォームで共通で使えるし特別な設定が比較的少なくて済むので使っていますが。