alt Hacker NewsI understand that implementing the TypeScript compiler is not the same thing as implementing all Node.js APIs, but still, advertising "no runtime" and then requiring JS runtime (and a full local Rust setup to compile it) for something as basic as an Express web server makes the "no runtime" claim look like a slight exaggeration. I'm not saying that it's bad, it's just that the website is too optimistic.
Edit: as discussed in the thread below, the most likely reason for that is that Express is pure JS with types from @types/express, so the TypeScript compiler bails on it. Reasonable, but still frustrating.
Overall, it seems like every time I decide to try a vibe coded compiler I get this feeling like when you see a plate with fruits on a table but, coming closer, see that they are fake plastic fruits. No, I cannot use it to build a native binary of my project without V8 as easy as shown on the front page. Maybe some other project, yes, but not a real one.
Unrelated: if a project is called Perry, should the icon be a platypus in a hat, you know?
Replies
This seems either wrong or very uncharitable.
> Perry exposes a faithful subset of Node.js’s stdlib HTTP server modules on top of hyper + rustls + tokio-tungstenite. The whole shape — handler signature, IncomingMessage / ServerResponse properties + methods, TLS opts, ALPN-negotiated HTTP/2, WebSocket upgrade dispatch — works unmodified, so unmodified Node servers (Express / Koa / Polka / hono via @hono/node-server / etc.) compile and run natively[1]
It's pretty standard for "no runtime" to mean nothing on the device you install the compiled target app.
I think iOS development still needs Ruby for Pod installation but no one says Swift apps need a Ruby runtime for example.
I am taking this attitude to an extreme with tsz. I don't want to announce to the world that tsz is ready until I tested it really really well.
Currently tsz passes nearly 100% of TypeScript tests but that is not enough. I want it to be able to type check complex things like type-challenges solutions or complex utility type packages. I'm stress testing it with a repo with 1.5 million lines of code.
I'm constantly assigning AI agents tasks to find bugs in tsz and open issues.
I'll say this is "alpha" when it can do all those things plus matching tsc exactly in thousands of open source projects where tsc reported type errors. It's easy to find CI runs that tsc reported errors. I'll build a database of all the cases I've verified tsz with and will publish those. Hoping that can give folks confidence that tsz is robust
For now, tsz is just a work in progress.
https://tsz.dev