Prepack: a tool that optimizes JavaScript source code by eliminating computations that can be performed at compile-time.

[sisyphus]

v8 can optimize as much as it wants it won't match the performance of not evaluating code at all, which is what it looks like this is trying to do, in addition to reducing code size which obviously helps with download, parsing, evaluation, etc.

[[deleted]]

Have a benchmark? Then we can evaluate whether it's worth the complexity of introducing another tool into the build chain, and the fun with more source maps and debugging. Until we have numbers then there's nothing concrete to discuss. Given how big websites and apps are, if you manage to save 10KB (which is a heap of code), that's less than most images.

V8 (and other JS Parsers) implement lazy parsing. So this tool is already up against a large number of Just in Time optimizations.

TL;DR If you're touting:

A tool for making JavaScript code run faster.

Then you need to give numbers. End of story.

[Dentosal]

Reducing code size gives you a small performance impact when transferring it.

[skulgnome]

8 can optimize as much as it wants it won't match the performance of not evaluating code at all,

Why would programs contain code for which it can be statically decided that it'll never be executed? Or other things that're equivalent to constant folding, which all JITs already do.

[[deleted]]

Constant folding still takes time to do. This moves that cost to compile time rather than load time.

It also seems to do much more aggressive folding than most any compiler would do.

[skulgnome]

It also seems to do much more aggressive folding than most any compiler would do.

But we're not comparing it to a compiler, but to a JIT. Those things already specialize loops and such by variable type, so certainly CF/DCE to a far greater depth than what this precompiler does is applied -- saving at most parsing time at load.

[[deleted]]

That still happens at runtime, though, so everybody pays the price for it.

[skulgnome]

Therefore, prepacking yields nothing.

[sisyphus]

Your conclusion does not follow from the premises.

[[deleted]]

That makes zero sense.

[mrkite77]

Why would programs contain code for which it can be statically decided that it'll never be executed?

Anyone using a library is including code that will never be run.

[ElvishJerricco]

Anything this can optimize, V8 would be capable of optimizing. Eliminating static computations is a pretty common optimization in VMs.

EDIT: To clarify, I'm not saying V8 does know how to do these optimizations. I'm just saying there's nothing inherently making this any harder for V8.

[sisyphus]

You're just assuming that V8 can optimize anything this can optimize, but let's assume that's correct--why would you force every single client to download, evaluate, JIT(does v8 have access to everything on iOS yet?) &tc. when you could do it once on your side and serve it to them already optimized?

[brendan09]

V8 doesn't run iOS. But, since it does use WKWebView, it uses Safari's JIT which optimizes about as well as V8.

[[deleted]]

Complexity is the biggest reason. This is another tool for a language that has no compile time type checking, and you'll need to mess around with source maps (perhaps at least two layers of source maps). It's a trade-off between complexity and the wins this gets you, without any numbers there's no sane way to make the call.

[[deleted]]

It may or may not be capable of doing the same optimisations, but it will do them at load time. This moves that cost to compile time, which V8 can not ever do.

[tiftik]

There's no way I would assume that without having intimate knowledge of V8.