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

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

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

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.

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.

Hey ventana,

(I'm the founder of Perry) thanks for giving it a try and let me be upfront with you: Compiling express has been one of the hardest challenges for Perry. I'm 99% sure it still does not work out of the box just yet - which is why we pivoted to fastify more than express.

That said, the last few days we made great progress to get Perry to compile packages "lik" Express (lot's of dynamic imports) much better.

I'll retry this once our current batch of Nodejs parity issues are resolved.

Just to be clear though: No v8 runtime, we actually took out the v8 engine we had optionally included thus far because the benefits no longer outweight the disadvantages.

If you want to tag along the progres follow me on X (@proggeramlug), that's where I share the most up to date progress on Perry.

Also, it is definetely a goal to compile apps that use Express and that will happen - not commiting to a timeline but just in the last few days we got so much closer.

Thanks for following up!

Don't get me wrong, I'll be totally excited to replace my card game app backend with a static binary, that's why I immediately went on trying Perry :)

Just to give you an idea what I'm trying to achieve: I'm currently hosting it on a single VPS. Node is handling the average of 30 qps, peaking up to 100 qps, just fine, with P99 latency being safely below 100ms and only occasional spikes of P99 to up to a second. The spikes are probably caused by some VPS sluggishness as I just use filesystem to periodically dump the in-memory games state.

But I expect I might eventually start seeing performance issues, so rewriting to a language that compiles to a native binary is on the table. I was considering Golang or Rust; making the current codebase compile to a binary would be a miracle saving me quite some time, even if I just vibe-code the rewrite :)

Just to chime in, i was having decent luck compiling Express apps to a binary using the experimental Node built-in executable feature--two years ago i was able to ship a single-binary Node-Express server without much headache.

Doesn't avoid the runtime, but it made deployment really easy.

Otherwise, I'm just using Go for backend now.