NGK2021SでHaxe最新事情の話をした

speakerdeck.com

要点は、

  • もしHaxeの最新情報が欲しかったら Haxe Roundup を見ような
  • Haxeはゲームクライアントでの採用事例が多いけど、Webフロントエンドでの採用は減り気味

という話です。あと、少し説明を端折った内容としては、JVMターゲットに関して、

  • JVMターゲットの開発は活発だが、まだ枯れたとは言い難い
  • JVMターゲットでもし問題が出たとしても、Javaターゲットに切り替えればJava環境で動作するプログラム自体は開発可能

という感じです。

Webフロントエンドについては、TypeScriptがデファクトスタンダードだが、静的型というイディオムをどうしても受け付けられない人がJavaScriptで書くというの多数派の世界です。何らかの信条がある少数派が、Haxe/JSに限らず、Scala.jsとかElmとかBlazorとか、その他の手段を取っている世界でもあります。

スライドではあまり触れませんでしたが、私がHaxe/JSでWebフロントエンドを書いている理由を補足すると、

  • TypeScriptは機能不足だし、型システムに無理がありすぎると思っている
    • 代数的データ型(もっというとGADT)とパターンマッチがないし、マクロというか、コンパイル時に型安全にAST変換する機構がない
    • 過去のJavaScriptで実装されたライブラリの「何でもありのインターフェース設計」に対して無理やりにでも型がつけられるようにしているせいで、複雑怪奇すきる(JSに型を付けるという考え方が出自なので、この方向性自体は間違っていないと思うが、Not For Meという話)
  • TypeScriptはコンパイルが遅い
    • バージョンアップでチューニングされているらしいというのは、たまに記事でもるので、これは認識が古い可能性はある
    • Haxeは過去のバージョンからコンパイルが相当速い(蛇足的だが、現在のHaxeコンパイラはメニーコア対応に構造的な問題があるので、シングルコア性能が必要)
  • JSのツールチェインにそれほど興味がない
    • 私のメインの開発領域が業務システムやPWAなので、JSのダウンロードサイズを数10KBレベルでカリカリにチューンすべき!みたいな意識が薄い(もちろん小さいに越したことはない)
    • ブラウザ上で動作するゲームの開発に関わった時に、突き詰めてもビルド後JSサイズが圧縮前で15MBを切れなかった(それでも当初から7-8分の1ぐらいにはした)のだが、そこに対してはほぼノークレームだった経験から、かなり認識が変わってきている
    • もちろん、10msec単位の表示遅延が発生すると、売上に直結する分野があることも認識しているので、活動分野が違うよねとしか
  • Haxe 4以降で不満点がかなり改善されてきている
    • アロー関数、final など、最近の言語ならごく当たりの話
    • 4.2でModule-level filedsが入るのも大きい
    • hx2dts のような、.d.tsHaxe externに変換するツールが準公式として開発中

という感じで、TypeScriptに不満があるので、消去法と過去の経験値からHaxeを選んでいるという状況です。Haxe/JSでWebフロントエンドを開発すること減少傾向にあることは、取り巻くを環境を考えると仕方ないなあと納得できる面と、必要な材料が揃ってきたから死んだ扱いにするのも違うかなと思います。TypeScriptが嫌だというケースにおいて、Scala.jsと同列ぐらいには候補と考えても良いんじゃないでしょうか。

ちなみにデンキヤギという会社では、Haxe/JSとScala.jsの人口比はほぼ同じです(アルバイトはカウントしていない)。その他には、F# Boleroで開発している人間もいます。

もしHaxeが突然死するようなことがあれば、普通に考えればScala.jsに行くかなーという感じですが、私一人で勝手にやるとしたらNimに強い関心があります。Haxe 3にはかなり不満があったので、Haxe 4が来るのがもっと遅かったら、今頃はNimの人だったかもしれません。

とはいえ、TypeScriptは絶対やらないということはなくて、必要があればTypeScriptもやる可能性はあります。