Perry vs. 대안들
TypeScript를 배포하는 다른 방법들 — 런타임, 컴파일러, 크로스 플랫폼 UI 프레임워크 — 과 Perry를 비교합니다. 솔직하고, 출처가 명시되어 있으며, 측정 가능한 수치는 그대로 제시합니다.
Perry vs Bun
Bun은 JavaScript/TypeScript 런타임이자 번들러, 패키지 매니저, 테스트 러너를 모두 갖춘 올인원 도구로, 자체 런타임을 코드와 함께 묶어 단일 실행 파일을 만들 수도 있습니다. Perry는 다른 길을 택합니다 — LLVM을 통해 TypeScript를 곧바로 네이티브 머신 코드로 컴파일합니다. 바이너리 안에는 JavaScript 엔진도, 런타임도 없으며 작은 네이티브 실행 파일만 남습니다. Bun과 Perry는 TS-바이너리 출력이라는 점에서는 겹치지만, 그 바이너리에 JavaScript 엔진이 들어가야 하는지에 대해서는 의견이 갈립니다.
Perry vs Deno
Deno는 V8 기반의 현대적인 JavaScript·TypeScript 런타임으로, 일급 TypeScript 지원, 권한 기반 보안 모델, 그리고 V8을 애플리케이션과 함께 단일 실행 파일로 번들링하는 `deno compile` 명령어를 제공합니다. Perry는 TypeScript를 곧바로 네이티브 머신 코드로 컴파일합니다 — 출력에 V8이 없고, 런타임 계층도 없으며, 작은 네이티브 바이너리만 남습니다.
Perry vs Static Hermes
Static Hermes (`shermes`)는 Hermes 엔진을 통해 강타입화된 JavaScript/TypeScript 부분 집합을 사전 컴파일하려는 Meta의 연구 단계 시도로, 주로 React Native를 겨냥합니다. Perry는 같은 일반 아이디어 — TypeScript를 네이티브로 컴파일하기 — 를 다른 방식으로 풀고 있습니다. Rust로 독립적으로 만들어졌고 LLVM을 백엔드로 사용하며, 현재 동작하는 컴파일러, 25개 이상의 네이티브 UI 위젯, 10개의 컴파일 타겟이 출시되어 있습니다. 2026년 4월 기준, Perry의 자체 벤치마크 슈트는 Static Hermes를 동급 비교 대상으로 시도했지만 표준 패키지 매니저로는 깔끔하게 설치되지 않았다고 보고합니다.
Perry vs Electron
Electron은 Chromium과 Node.js를 앱과 함께 묶어 웹 기술 (HTML/CSS/JS)로 크로스 플랫폼 데스크톱 앱을 만들 수 있게 해줍니다. Perry는 TypeScript를 곧바로 네이티브 머신 코드로 컴파일하고, UI는 실제 플랫폼 위젯 — AppKit, UIKit, GTK4, Win32, JNI — 을 통해 그립니다. Electron의 메시지는 웹 기술 재사용이고, Perry의 메시지는 TypeScript에서 작은 네이티브 바이너리와 네이티브 UI를 만드는 것입니다.
Perry vs Tauri
Tauri는 Rust 백엔드와, 운영체제에 내장된 웹뷰 — Windows의 WebView2, macOS의 WKWebView, Linux의 WebKitGTK — 안에서 동작하는 프런트엔드로 크로스 플랫폼 데스크톱 (그리고 점차 모바일) 앱을 만드는 프레임워크입니다. Tauri 앱은 OS 웹뷰가 번들되지 않기 때문에 Electron보다 훨씬 작습니다. Perry는 다른 길을 택합니다 — 웹뷰 자체를 쓰지 않고, HTML 렌더링도 없이, TypeScript를 곧바로 네이티브 머신 코드로 컴파일하여 실제 플랫폼 위젯을 구동합니다.
Perry vs React Native
React Native는 JavaScript/TypeScript로 iOS와 Android의 네이티브 UI를 구동할 수 있게 해줍니다 — UI 컴포넌트는 JS-to-네이티브 브리지 (또는 New Architecture에서는 같은 개념적 형태의 JSI/Fabric 레이어)를 통해 플랫폼 위젯에 매핑됩니다. Perry는 다른 접근을 택합니다: TypeScript를 사전에 네이티브 머신 코드로 컴파일하고, 네이티브 UI는 런타임 브리지가 아니라 컴파일된 바이너리의 일부가 됩니다.