Prepack helps make JavaScript code more efficient

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.

How "safe" is it? I'm thinking, for example, of Google's closure compiler and the advanced optimizations, which can break some things.

Or roughly, if it compiles without errors, is it safe to assume it won't introduce new bugs?

To really see the benefits, you need to use it an environment where the parsing overhead gets cached. In terms of pure execution time, we see improvements of up to 10x for the initialization phase.

It's not yet ready for production, so there are some bugs and cases where we should reject a program but don't do that yet.

Having said that, it's quite safe, but won't be undetectable. Code using eval could detect injected identifiers, we don't currently aim at preserving function names, and the method bodies you get with toString() are altered. That should be roughly it.

It doesn't seem like this tool supports global level objects.

For instance, a common pattern being:

(function(w) { console.log(w.location); })(window)

This results in issues because it's unaware that window would contain other methods. Is it possible to exclude certain objects in this case?