A webpack plugin for prepack. https://github.com/gajus/prepack-webpack-plugin
Prepack helps make JavaScript code more efficient
61–70 of 233 posts
Re: Prepack helps make JavaScript code more efficient
#62Looks like it's applying the same sort of optimizations a normal optimizing compiler would. With all of these JS "compilers" and transpilers, at some point, it just makes sense to build a client-side language in the browser that compiles down to native and runs sandboxed. I'm excited for WebAssembly, but I realize that, like with all shiny new web things (for example, WebRTC on Safari/iOS), mainstream browsers that m…
I also don't understand why is your comment downvoted. I think that some people don't want to lose their hard-earned JavaScript skills and try to downvote everything that bless WebAssembly in any way.
Re: Prepack helps make JavaScript code more efficient
#63How does it compare to Google's closure compiler? It is considered by many best in class. It understands the code (uses Java based Rhino Javascript engine), while most alternatives (UglifyJS & co) just monkey patch things. You can trust the Google's closure compiler output. Edit: @jagthebeetle: have you tried "advanced mode"? (One should read the documentation before using it, it's really a game changer but requires…
This was my immediate question. For want of a more rigorous test, the online closure compiler service (https://closure-compiler.appspot.com/home) failed to produce equivalent or shorter output for all but the first example.
Re: Prepack helps make JavaScript code more efficient
#64[deleted]
Re: Prepack helps make JavaScript code more efficient
#65I just ran this on a huge JS project that has a quite intensive "initialization" stage (modules being registered, importing each other, etc.), and prepack basically pre-computed 90% of that, saving some 3k LOC. I had to replace all references to "window" with a fake global object that only existed within the outer (function() {..})() though (and move some other early stuff with side effects to the end of the initiali…
Wow. That is pretty impressive. Although as far as the changes you needed to make are considered, my understanding from a brief skim of the page was that `__assumeDataProperty` would be sufficient for supporting use of `window`.
It depends on what you use from window. If no functions on `window` are called during initialization you could just use `__assumeDataProperty` on all the properties of `window` you access.
If you call a function on `window` during initialization you would need to use `__residual` to emit the code into the residual program (assuming the call has no side effects on the heap that need to be seen by other initialization code). This is because otherwise Prepack cannot know how the abstract function would modify the heap (if it is an arbitrary function it could modify the global object for example), so it is not safe to execute.
Re: Prepack helps make JavaScript code more efficient
#66Hi, I am Nikolai Tillmann, a developer on the Prepack project. I am happy to answer any questions!
This is fucking impressive!
Just evaluated this:
(function() {
var a = 'a';
var b = [a, 'b', 'c']
.filter((i, index) => i.charAt( 1 - index) !== 'b')
.map(i => i + '!')
.join(',')
console.log(b)
})()
Re: Prepack helps make JavaScript code more efficient
#67Hi, I am Nikolai Tillmann, a developer on the Prepack project. I am happy to answer any questions!
Can it be plugged into webpack for production builds? (I know it's not production ready yet)
Yes, as of about 25 mins ago - https://github.com/gajus/prepack-webpack-plugin
Re: Prepack helps make JavaScript code more efficient
#68Hi, I am Nikolai Tillmann, a developer on the Prepack project. I am happy to answer any questions!
This is fucking impressive! Just evaluated this: (function() { var a = 'a'; var b = [a, 'b', 'c'] .filter((i, index) => i.charAt( 1 - index) !== 'b') .map(i => i + '!') .join(',') console.log(b) })() BTW how you avoid going to infinite loops?
Another question: Does this use Flow types to optimize things like object member properties?
Re: Prepack helps make JavaScript code more efficient
#69Hi, I am Nikolai Tillmann, a developer on the Prepack project. I am happy to answer any questions!
Awesome work! Are there plans to incorporate Flow definitions as an alternative to the __assumeDataProperty helpers?
Edit: Looks like this is targeting compiler output, so Flow types would typically be gone by that stage. Integration with Flow could come via a babel plugin that emits `__assumeDataProperty()` when it encounters a convertible Flow type.