Perry Compiles TypeScript directly to executables using SWC and LLVM

Original Article ↗ Hacker News Discussion ↗

Project concept & appeal

  • Perry compiles TypeScript directly to native executables using SWC and LLVM, targeting multiple platforms and UI backends.
  • Many find the idea of cross‑platform, natively compiled TypeScript compelling, especially for replacing Node backends or avoiding Rust/Go rewrites.
  • Some are interested specifically in using the compiler independently of the bundled UI framework.

Runtime, GC, and “no runtime” claim

  • Multiple commenters dispute the “no runtime” marketing; they note any GC’d language needs a runtime, even if statically linked.
  • Maintainers clarify “no JS runtime / JIT” is the intended meaning; there is a native runtime, plus a small Perry runtime and GC.
  • Debate over terminology: some argue “no runtime” is misleading; others say it’s commonly used to mean “no VM like Node/JVM installed.”

Performance & compilation strategy

  • Perry uses NaN-boxing to support TypeScript’s dynamic semantics, similar to JavaScriptCore; this currently incurs a noticeable performance hit vs languages like Zig.
  • Roadmap mentions optimizations (typed buffers, monomorphization-style tricks) that could narrow the gap without changing semantics.
  • Claims about fully static method resolution vs vtables prompt skepticism; discussion notes fallback to vtables when static resolution is impossible.

AI-generated code, docs, and trust

  • Many criticize the site and docs as “AI slop”: repetitive marketing patterns, confusing structure, internal LLM instruction files in the repo.
  • Commit patterns and AI-written Rust raise concerns about maintainability, accountability, and who debugs deep issues (e.g., GC bugs).
  • Others argue this reflects the new normal: heavy AI assistance for large codebases, with AI also used to refactor and find bugs.

Compatibility, limitations, and JS interop

  • Users report friction compiling real projects, especially those using Express or pure-JS dependencies; Perry may fall back to a JS runtime path it now discourages/removed.
  • Confusion over when JS modules trigger a JS runtime, and how strict TypeScript typing must be to avoid it.
  • Documentation is widely described as incomplete, hard to follow, and out of sync with recent changes (e.g., removal of the JS runtime).

Related efforts & alternatives

  • Other TS-to-native projects are discussed (e.g., compiling TS via .NET NativeAOT or alternative TS typecheckers with “sound mode” goals).
  • Some prefer more conservative, well-documented approaches over what’s perceived as “vibe-coded”/AI-driven compilers.