Prepack is quite complementary to traditional compilers. It's strength is that it comes with full knowledge of the JavaScript built-ins, and it uses that to pre-evaluate the code at compile time. In an extreme case, an entire program can get reduced to the final result.
Right, I tried editing my post a bit more to make it clearer:
Added the adjective "optimizing" to "compiler" in the first sentence (I meant something like LLVM opt, what you get when you -O3 your Makefile -- constant folding, loop unrolling, dead code elimination, compile-time constexpr function evaluation -- your extreme example being running the entire program at compile-time).
Added quotes around JS "compiler" -- what your run-of-the-mill JS developers call "compilers" aren't actually real optimizing compilers, even though the JS world would say otherwise, but I digress. Yours is the first to even come close.
Your approach is subject to all sorts of breakages. You mention the lack of "environments" in your documentation which means Prepack out-of-the-box is completely oblivious to the browser itself -- the DOM, etc. What really is annoying is if Fib(6) gets replaced with 8 (including the whole definition of Fib itself, then I can't pop open my console anymore and type Fib(3) -- nor can I bind a UI control to a textbox that evaluates Fib(text) in the box).
An actual working compiler takes in account the "execution environment" as a whole. You can't Fib(x) Linux into oblivion.