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.
> a request object with lazy accessors would solve this issue, although the accessor itself would have some overhead in repeat accesses
The overhead can be reduced with caching. Frameworks like Java Vertx (used by Quarkus) already do it this way?
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.
> 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.
Yup, this is a one-time, startup operation, using a proper parser would make it more robust at no runtime cost.
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.
Stuff like constant folding won't take place until you hit an optimizing compiler tier. For the interpreter and baseline/template-compiler tiers, there's just not enough time to do that sort of dataflow optimization. So yes, it would help at least somewhat, esp. if you don't think the code is likely to tier up much for whatever reason (no one part is all that hot, or perhaps it's too polymorphic).
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?