Hacker News Reader

Comment by rFlex | Hacker News Reader

One of the Valdi's authors here. It's using native views under the hood, like React Native, and there are 3 modes of compilation/execution for the TS source. It can be interpreted from JS (TS compiled to minified JS source), interpreted from JS bytecode (TS compiled to JS source, minified, then compiled to JS bytecode ahead of time), or compiled to native code directly (TS compiled to C ahead of time).

View on HN

An AOT TS -> C compiler is fantastic - how much of the language is supported, what are the limitations on TS support? I assume highly dynamic stuff and eval is out-of-scope?

Most of the TS language is supported, things that are not can be considered bugs that we need to fix. Eval is supported but it won't be able to capture variables outside of the eval string itself. We took a reverse approach than most other TS to native compiler projects: we wanted the compiler to be as compatible with JS as possible, at the expense of reducing performance initially, to make it possible to adopt the native compiler incrementally at scale.

There are significant trade-offs with this compiler at the moment: it uses much more binary size than minified JS or JS bytecode, and performance improvements goes from 2x to sometimes zero. It's a work-in-progress, it's pretty far along in what it supports, but its value-proposition is not yet where it needs to be.

Can this compiler be used outside of Valdi? TS to native AOT sounds incredible.

Quickjs will do this.

Reply on news.ycombinator.com