Re:Reasons to think that, in terms of influence if not wealt...
by ikeyany on Sunday February 18, 2018 @02:08AM
(#16404874)
> The idea is to run your JS program as part of compilation, evaluating it as much as you can. Then take what's left in the heap and serialize it back to JS. Then ship that to browsers/devices.
Could you elaborate on what is cool about that? I feel like I'm missing something...sounds like it analyzes javascript to make it run faster.
Re:Reasons to think that, in terms of influence if not wealt...
by bcherny on Sunday February 18, 2018 @04:32PM
(#16408840)
If you have some JavaScript code, it goes through a few phases as it's evaluated by your browser:
1. Parsing
2. JIT optimizing
3. Compilation to bytecode
4. Re-optimization as the program runs
Steps 1 and 2 are expensive, and there are a few ways to cut down on them:
- Removing dead code before you ship
- Optimizing your code for the JIT compiler (eg. Closure Compiler does this)
- Webassembly
- Pre-evaluating your code with Prepack
More philosophically, the question is "when does my code run?". The answer has usually been "on the client". With Prepack, the answer is "as much as possible during compilation, and the remainder on the client".
The idea is to run your JS program as part of compilation, evaluating it as much as you can. Then take what's left in the heap and serialize it back to JS. Then ship that to browsers/devices.
AFAIK, that sort of AoT evaluation has been limited to academia and niche applications in Haskell and OCaml because purity analysis is so tricky in languages that don't track effects.