Strict subset of typescript that allows even smaller/faster binaries

[venkatd]

Interesting project! I bet this was a lot of work to build.

Not a user of this project but came up on my Twitter and had a random thought.

It might be interesting for those who are willing to avoid dynamic features, restrict themselves to certain types, or use some perry specific stdlib, you could provide even smaller, faster binaries.

Thoughts?

[proggeramlug]

Thanks for taking a look and for the thoughtful suggestion! It's a reasonable instinct — AssemblyScript/Static Hermes/etc. have shown that a strict subset can buy you real wins, so the question is well worth raising.

The short answer is that Perry has been deliberately trying to extract those wins without asking users to opt into a different language, and so far that's been working out:

• Object layout. Phases 1/3/4 of our object-layout work (shape inference on object literals, synthetic anonymous-class generation, return-type inference flowing through method calls) gives idiomatic TS the same monomorphic layouts a strict subset would force. Users write normal TypeScript; the compiler picks up the structure.
• Per-file opt-in where it actually pays. Where a more aggressive codegen path genuinely needs a hint, we've used JSDoc pragmas — e.g. @perry-lazy for tape-based JSON parse. That's a smaller commitment than a separate dialect and composes file-by-file.
• Binary size is mostly already handled by the linker. With --gc-sections + function-sections, code paths the program doesn't reference (mysql2 bridges, regex, half the stdlib) get dropped at link time. A hello.ts is ~0.5 MB on Windows, a few MB on macOS — most of "use a smaller subset" is what the linker is already doing for you.
• Where Perry still has perf headroom, it's not a language-feature problem. The remaining gaps (e.g. RSS vs Bun on JSON-heavy workloads) are GC/allocator architecture — generational GC, escape analysis, precise root tracking — tracked in docs/memory-perf-roadmap.md. A subset wouldn't move those numbers.

So the philosophy is: keep it full TypeScript, lean on inference + linker DCE for the common case, add narrow pragma-scoped opt-ins where there's a measurable win. A separate dialect would fragment the value prop ("your existing TS just works") for gains we're already capturing.

Really appreciate you flagging it though — it's the kind of question worth having a clear answer to.

[venkatd]

All make sense thanks for sharing the reasoning behind it!