Wrote a thing about what makes Elysia stand out in a performance benchmark game

Basically, there's a JIT "compiler" embedded into a framework

This approach has been used by ajv and TypeBox before for input validation, making it faster than other competitors

Elysia basically does the same, but scales that into a full backend framework

This gave Elysia an unfair advantage in the performance game, making Elysia the fastest framework on Bun runtime, but also faster than most on Node, Deno, and Cloudflare Worker as well, when using the same underlying HTTP adapter

There is an escape hatch if necessary, but for the past 3 years, there have been no critical reports about the JIT "compiler"

What do you think?

Sounds plausible, but the article itself lists a number of downsides to this, including a statement about potential security problems with a somewhat wishy washy "The input is almost never user-controlled". That "almost never" is a big red flag to me - sounds like there are known security holes that are being glossed over.

So my question is whether there are any real-world scenarios where the performance gains will make a difference to the end customer? Because if not, this framework would bring on the known downsides without a compelling reason for doing so aside from bragging rights of "we're the fastest"

> Sucrose looks at code and tells the "compiler" to only parse params and skip parsing other parts of the request like body, query, headers entirely as it's not need.

My understanding is that just offering a request object with lazy accessors would solve this issue, although the accessor itself would have some overhead in repeat accesses.

> Elysia has two special optimizations for response mapping functions: mapResponse and mapCompactResponse.

This section feels a bit abstract - some transformation examples would be nice.

> Sucrose read the code without executing it by using Function.toString() then perform our own custom pattern-matching to extract useful information about what parts of the request are actually needed by the route handler.

Hmm.

Is doing stuff like constant folding pre-execution really worth it? I mean, won't the engine itself (V8, JSC, MozJS) be doing it anyway? I know that Google's Closure Compiler — probably still the most advanced JS optimized — also does it but I can't help but think it's probably pointless.

I was really confused about what a JIT "Compiler" for a JavaScript framework means, but it turns out it means something like I've done myself.

My site https://c50.fingswotidun.com/ uses the same trick to generate code for the image generation.

Between the confusion of what Compile, JIT, Engine, Runtime, and FrameWork is (which I blame Bun a little bit for starting this entire Runtime/Engine confusion). I think we might need some new terminology to describe this method.

Maybe a made-up word is needed, JIT was good in that an acronym with a vowel made it wordable and specific.

I'm not familiar with Elysia but how does this handle subfunctions? e.g. if my code is

const app = new Elysia() .patch('/user/:id', (request) => { return handleUserRequest(request); })

or some other custom logic, does it automatically need to fall back to full parsing?

Frameworks. Plural.