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?

▲ nl an hour ago | parent [-]

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

▲ ventana an hour ago | parent | next [-]

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

  $ cat index.ts
  import * as express from 'express';
  const app = express();

which gives

  $ perry index.ts
  Collecting modules...
    JS module: express -> /private/tmp/ex/node_modules/express/index.js
  Error: build pulled in `perry-jsruntime` (QuickJS-based eval-equivalent runtime)   via the following file(s):
    - /private/tmp/ex/node_modules/express/index.js [express]
  
  `perry-jsruntime` is treated as a privileged dependency on par with adding a JIT to the binary — it re-introduces arbitrary runtime code execution and defeats Perry's structural advantage over Node. Refusing to link by default. (#499)
  
  To enable, set `perry.allowJsRuntime: true` in the host package.json, or pass `--enable-js-runtime` on the CLI for a one-off build. (Falls under `--lockdown` deny set when that flag ships — see #496.)

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.

	▲	nl an hour ago \| parent [-]
		Fair, but might have been worth including that in your initial comment because the docs don't mention that at all.

▲ pjmlp 32 minutes ago | parent | prev [-]

> 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.