I 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?
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.
[1] https://docs.perryts.com/stdlib/http.html
Well, I did indeed spend some time playing with it before writing my comment. I first tried to compile the TypeScript project I'm working on, and it happens to be an Express server. After some minor unrelated fixes required (Perry does not understand importing "fs/promises", so I fixed it to import "fs" and then taking .promises) it said it needs JS runtime, and the smallest repro I found was
which gives Maybe it's because Express is written in JavaScript with external types from @types/express, that would explain why it might need JS runtime, but it does not make things easier for me.Fair, but might have been worth including that in your initial comment because the docs don't mention that at all.
I got the impression from the first comment that it was speaking from experience not the docs
It is not standard for “no runtime” to mean that. For example go has a runtime that is compiled into the binary or you can google c runtime and see a million ways the word “runtime” is used with c.
> It's pretty standard for "no runtime" to mean nothing on the device you install the compiled target app.
Only by layman that don't understand compilers.
The tone here is a bit rude but I'm still curious: what does no runtime mean to you?
It is my tone, GenX, no minced words.
The infrastructure required to support a programming language, startup and shutdown boilerplate, all the required functionality to support standard library features including integration points between language semantics and support code.
Stuff like what code runs before and after main(), trap handlers for floating point arithmetic, handling of thread local storage, bind language heap handling primitives to library code, traps for handling stack overflow errors,....
Right, runtime is so broad that it's hard to say something has "no runtime". libgcc + your choice of crt0 is a C runtime, and the JVM is a Java runtime. That's a huge spectrum.
It's worth being charitable in your interpretation though and recognising "no runtime" probably refers to JVM-shaped or Node-shaped things, not libgcc+crt0-shaped things.
Alternatively, "runtime" is a derogatory term used by programmers who want to show superiority over others who use languages with more (built-in) features than theirs.
There's practically no difference for the overwhelming majority of software these days. Most people aren't working on embedded systems or operating systems.
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
This looks exciting.
To be fair, nowhere on the frontpage does it say it can build libraries that depend on node. It seems like you are just waiting in the bushes to dis AI assisted coding.