[GeoffreyPlitt]

Can you prove that any of the optimizations in your docs aren't already done by V8? I agree with the other commenters in this thread-- V8 likely does these already. You have an extraordinary claim, which requires extraordinary proof.

[batmansmk]

The whole point is to not let V8 do any job at all.

V8 == user impacted.

Compile time V8 == compiler impacted, users happy.

It's like interpreting what you can during compile time, with caching capabilities.

To speed up boot time and init time, not runtime per say.

[swsieber]

This. By transforming and evaluating things that really could be constants beforehand, V8 has less to do when it goes to run the javascript.

[pcwalton]

V8, like all tiered JITs, doesn't do many optimizations unless the code to be optimized is hot. This is the right thing for V8 to do, because most code on the Web is cold and so it's better to just run the code rather than sitting there optimizing it. But it does mean that there are a lot of optimizations that would be profitable to perform in the aggregate that are nevertheless unprofitable to do at runtime, because the time spent to optimize outweighs the running time of the unoptimized code. AOT optimizers like Prepack can solve this dilemma, by doing expensive optimizations ahead of time so that doing them won't eat into the runtime of the program.

[tadeuzagallo]

That's not all, there's the cost of (down)loading the dead code, and startup cost for loading the unoptimised cost. Even more critical when you consider environments where you can't JIT, like React Native on iOS for instance, which was one of the many motivations for Prepack AFAIK.

[timruffles]

It's much better to do this earlier. If you're asking v8 to optimise, say, the whole of React on a mobile device before first paint, that's definitely going to be slower than having the same optimisations done before V8 needs to parse/optimise it!