PerryでTypeScriptをnative binaryへ変える前に読む実行方式と計測

TypeScriptを実行形式へ変えるPerry

PerryはRustで書かれたnative TypeScript compilerです。READMEでは、SWCがTypeScriptをparseし、LLVMがmachine codeへcompileすると説明しています。Node.jsを各環境へinstallしたり、Electronへbrowser engineをbundleしたりせず、programをbinaryとして配布することが中心の設計です。webをtargetにする場合はJavaScriptまたはWebAssemblyを出力できます。

READMEの標語は、TypeScriptを書き、nativeでどこへでもshipするという方向を示します。Perry側の説明では、macOS、Windows、Linux、iOS、Android、watchOS、TVをnative targetにし、同じcodebaseから複数platformへ展開できるとされています。これはcompilerのtarget範囲を示す主張であり、既存のNode applicationが無変更で全OSへ移植できるという保証ではありません。

採用判断では、まず実行形式を必要とする理由を明確にします。serverの起動時間、配布容量、Node runtimeの管理、desktop UI、mobile連携のどれが要件なのかを分け、通常のNode.js、Bun、Electron、native言語と比較します。PerryのREADMEは自己紹介と公開benchmarkを含む資料なので、実際の業務処理は別に計測します。

AOT compileとbinary配布の利点

Perryはahead-of-time machine codeを生成し、engineの起動やJIT warmupを不要にすると説明しています。READMEの例では、perry compile src/main.ts -o myappでcompileし、生成したmyappを実行します。hello worldのnative binaryは約330KBと自報されています。配布先にJavaScript engineを用意せず、一つのbinaryを渡す形を検討できる点が特徴です。

一方、binaryが小さいという説明は、対象code、runtime機能、link設定、target、debug情報によって変わります。READMEはPerryが必要なruntimeだけをlinkすると説明し、MongoDB GUIの約7MBという例も挙げていますが、すべてのアプリが同じ容量になる根拠ではありません。compile後の容量、起動時間、依存binary、OS別の署名と配布を自分のprojectで測ります。

Electronとの差も、用途を分けて考えます。Perryの比較表はElectronがbrowser engineを含むapp bundle、Perryがnative binaryであると示します。web表示を中心にするdesktop appではElectronの機能が必要な場合もあるため、容量だけで優劣を決めません。UI、network、file system、更新、crash報告、署名を含む配布手順を一つの設計として確認します。

Node互換とnpm依存の現実

READMEは、既存のNode codeが大部分動くことをPerryの特徴として挙げています。Node自身のtest suiteに対して53のnode:* moduleをまたぐ約97%のpass rate、自報の実装としてfs、http、http2、net、tls、crypto、stream、child_process、worker_threads、fetch、web globalsなどを列挙しています。Fastify、Express、mysql2、pg、ioredis、ws、bcrypt、jsonwebtokenなど約50のpopular npm packageにも触れています。

この数字とpackage名はPerry側の公開説明です。Node互換という言葉を、すべてのversion、module、native addon、runtime挙動が一致する意味に広げません。既存applicationを移すときは、使用するNode API、package、filesystem、TLS、process、child process、環境変数、signal、streamの挙動を一覧化し、critical pathから試します。

plain JavaScriptもcompileできるとREADMEにありますが、TypeScriptの型検査とPerryのcompile成功は、業務上正しい動作を証明しません。HTTP、database、認証、file、queueを使う小さなserviceを作り、Node版との応答、例外、終了、memory、再起動を比較します。npm packageを追加するたびに、native依存、install script、license、対応targetを確認します。

native UIと11 targetの扱い

PerryのREADMEは、WebViewを使わないnative UIとしてAppKit、UIKit、Android Views、Win32、GTK4を挙げています。macOS、iOS、iPadOS、visionOS、tvOS、watchOS、Android、Wear OS、Windows、Linux、Web/WASMへ同じUI codebaseを展開する11 targetという説明もあります。home-screen widgetへの参照も記載されています。

共通UI APIがあっても、各OSのnavigation、入力、permission、background処理、通知、store規約は変わります。native widgetを利用する場合は、画面サイズ、accessibility、keyboard、touch、lifecycle、font、platform固有のerrorをtargetごとに確認します。Web/WASMはnative binaryではなく、browserで動く出力になるとREADMEが注記しているため、同じ配布物として扱いません。

最初の評価では、一覧画面、入力form、network待ち、画像、file、画面遷移を一つの小さなappへ入れます。各targetでbuildできるかだけでなく、ユーザー操作、再開、終了、OS更新、署名、配布、crash取得まで確認します。Perryがtargetを列挙していることと、第三者packageが全targetを支えることは別の条件です。

公開benchmarkを数字のまま採用しない

READMEのPerformance節には、Apple M1 Max上で繰り返した測定の中央値として、画像畳み込み、再帰Fibonacci、JSON pipeline、object allocation、array write、peak memoryの比較表があります。例として、画像畳み込みはPerry 354ms、Node.js 1207ms、Bun 915ms、Rust 392ms、JSON pipelineはPerry 39ms、Node.js 144ms、Bun 51msと記載されています。Perry側の公開測定に基づく数値であることを明示して読みます。

同じ表では、PerryがRustに近い、または上回る行があると説明されます。一方、READMEには公開suiteの中にNode.jsやBunに負ける行も含め、結果を出すと書かれています。prime sieveやmatrix multiplicationのような処理は、得意な実行経路が異なります。平均や中央値の順位だけを見て、業務処理の性能を推測しません。

比較する際は、hardware、OS、Perryのversion、compiler option、入力サイズ、warmup、反復回数、正しさの確認、memory測定方法をそろえます。READMEのbenchmarkは特定のworkloadの結果であり、I/O、database、network、compile時間、実利用者の同時要求をそのまま表すものではありません。公開harnessを読む場合も、測定条件と失敗した行を保存します。

threadとdata race安全性の主張

Perryはreal OS threadを利用し、compile時にdata raceを安全に扱う設計を特徴として挙げています。parallelMap、parallelFilter、spawnがREADMEに示され、shared mutable stateをcompilerが拒否するためdata raceがcompileできないという説明があります。JavaScriptのworkerやElectronのprocessとは違う並行処理モデルを目指していると読めます。

この方式を採用する場合、並行化できる仕事、値の共有、messageの受け渡し、停止、例外、resource解放を先に設計します。compilerが共有状態を拒否することは、並行処理の全ての問題を消すものではありません。deadlock、starvation、順序依存、外部DBの競合、fileの同時書込み、networkの再試行は別に検証します。

小さな処理でspawnとparallelMapを試し、同じ入力を繰り返した結果、終了順、例外、取消、CPU使用率、memoryを記録します。single threadとの比較で速くなる処理だけを並列化し、共有状態を無理に変更してcompilerの制約を回避しません。READMEの安全性に関する自己説明と、アプリケーションの実測結果を分けて扱います。

導入方法とrelease版の固定

READMEのGetting Startedでは、macOS、Linux、Windows向けのinstall例としてnpm install -g @perryts/perry、Homebrewのperryts/perry/perry、winget install PerryTS.Perryが示されています。projectはperry init my-appで作成し、directoryへ移動してperry run .で起動します。Fastifyをimportするnpm利用例も掲載されています。

素材の取得日時は2026年8月29日です。release情報にはv0.5.1220、v0.5.1219、v0.5.1182が記録されています。Perryの説明はpre-1.0段階のprojectとして読む必要があり、取得時点のreleaseを安定した長期互換版と断定しません。install経路、binary、compiler、runtime、package lock、targetを一組で保存します。

既存TypeScriptを移す前に、hello world、file処理、HTTP、database、UI、workerを別の小さな例でcompileします。compile error、実行時例外、binary容量、起動時間、更新とrollbackを記録し、Node.js版との出力を比較します。Perryの性能を採用根拠にする場合も、公開表ではなく自分の主要処理で再計測します。

MITライセンスと採用範囲の結論

Perryの素材上のlicenseはMITです。利用、改変、再配布を検討する際は、採用版のLICENSE、依存package、LLVM、SWC、native UI、npm module、モデルや画像などの外部資産を個別に確認します。MITは性能、support、security、互換性を保証するものではありません。binaryへ何をlinkしたかと、配布時に必要な表示を記録します。

Perryが向くのは、TypeScriptを維持しながらNode runtimeの配布負担を減らしたい場合、native binaryやnative UIを必要とする場合、compile時の制約を受け入れて実行方式を固定できる場合です。Node APIやnpm native addonへ強く依存する既存app、web engineの機能が中心のdesktop app、全targetへ同じpackageを持ち込みたいappでは、移行工数を先に測ります。

最初の採用判断は、公開benchmarkの順位ではなく、対象機能のcompile成功、正しい出力、起動とmemory、target別UI、thread、依存license、配布とrollbackで行います。PerryのREADMEが示す可能性を入口にし、自分のcodebaseで失敗条件まで記録できた範囲だけを本番候補にします。

編集部の結論

Perryは、TypeScriptの記述経験を保ちながら、Node.jsやbrowser engineを同梱しないnative binaryを作りたい開発者が試せるRust製compilerです。READMEはmacOS、Windows、Linux、iOS、Android、watchOS、TV、web、WASMなど多くのtargetを挙げ、速度や容量の比較も公開していますが、数値はPerry側が示す特定環境の結果です。採用前に対象OS、Node API、thread、native UI、binary容量、compile時間、npm依存、実際の業務処理を固定し、公開benchmarkを自分の測定で置き換えてください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes