Since Porffor can compile itself (you can run the compiler inside of Porffor), any calls to eval could be compiled to Wasm (via executing the Porffor compiler in Porffor JS engine) and executed performantly on the same JS context *

*or at least, in theory

I haven't used it, but reading their landing page, Porffor says their runtime is vastly smaller because it is AOT. If the compiler had to be bundled with the executable, then the size of the executable would grow much larger.

Yeah, but you'd only need to include Porffor into compiled code if it used eval.

And most devs stay away from eval for well-deserved security reasons.

That wouldn't work: The Wasm spec does not allow for modifying an already running program (e.g. JIT).

AFAIK the only option is to include an interpreter.

You don't need to modify an already running program, you can plug new functions into an existing Wasm program via a table, and even attach variables via globals or function arguments.

I'd recommend checking the work on making SpiderMonkey emit Wasm as a backend

For now, unless it is given a literal string (eg `eval('42')`) eval just won't work.

With a string literal it works, with a dynamic string it just gives an undefined reference error to eval.