18 ms·

Prepack helps make JavaScript code more efficient

836 points by jimarcey 9y ago

web-guy 9y ago
I did an experiment to look for synergy from combining Prepack with the Closure compiler: http://www.syntaxsuccess.com/viewarticle/combining-prepack-and-closure-compiler http://www.syntaxsuccess.com/viewarticle/combining-prepack-a... The result was pretty good.
Hydraulix989 9y ago
Looks 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 most people/users actually have installed on their computers/devices and use won't support it for another 3-5 years. Meanwhile, the everyday JS coder wants to use ES7 from last year but has to settle for the bandaid solution of Babel because the browsers aren't going to be ready for it yet. Google's Native Client had the right idea but never quite took off (nor was it ever adopted by anybody else): https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf https://static.googleusercontent.com/media/research.google.c... This type of working solution would also stave off the Electron-ification of desktop apps (which means an effective halving of my laptop battery life, spinning up wasted CPU cycles -- like 13% being spent on rendering a blinking cursor, and reducing my computer's RAM by a factor of eight as just about everything I run on my computer now is its own separate bloated Chrome instance -- Slack, Atom, VSCode, Skype, Telegram, Discord, Spotify, ...). EDIT: Facebook employees, please stop downvoting my quality content. It is getting tiresome.
- NTillmann 9y ago
  Prepack is quite complementary to traditional compilers. It's strength is that it comes with full knowledge of the JavaScript built-ins, and it uses that to pre-evaluate the code at compile time. In an extreme case, an entire program can get reduced to the final result.
  - Hydraulix989 9y ago
    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.
- dennykane 9y ago
  I was right there a year or two ago developing portable native client things for my project, Linux on the Web (I was able to get vim and python running). Projects like that can pioneer a whole lot of new techniques and infrastructure that can be very easily applied to whatever technology is eventually going to win out.
  - Hydraulix989 9y ago
    @dennykane It's a shame seeing your comments are getting downvoted on here too. It really leaves me with a bad impression about how FB operates. @rattray Even without access, downvotes don't just happen out of nowhere; you have to admit that this just looks too obvious to any reasonable person. I'm curious what you thought was downvote-worthy of my original post pre-edit? I get it, rules are rules, and this is a matter of principle.
    - seattle_spring 9y ago
      Late to the party, but I suspect you were downvoted for your arrogant and condescending tone, combined with your sense of unsubstantiated victimhood.
      - deleted 9y ago
        [deleted]
      - Hydraulix989 9y ago
        I'm not sure how you can leap to conclusions about my tone of voice from textual comments? One user @rattray is even citing quotes from the rule book to me here, and somehow I'm the one being condescending? But hey, regardless of the situation, nobody deserves to be insulted like this! You can do better, man. I can give you the benefit of the doubt; I suspect you wouldn't ever act this way in person to anybody. I also don't see how any sort of purported victimhood would be unsubstantiated (I just don't happen to take website comments from strangers all that seriously): I'm just trying to talk about WebAssembly, and this troll spends their Friday night posting these kinds of inflammatory comments on nearly-dead threads from the beginning of the week. :( As a reminder, you're breaking the very first rule -- "be civil" -- since we're sticklers about the rules here. You are acting very rude!
- rattray 9y ago
  From the guidelines: > Please resist commenting about being downvoted. It never does any good, and it makes boring reading. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Disclaimer: I do not work at Facebook.
  - Hydraulix989 9y ago
    While I appreciate your vigilantism (given you aren't actually a moderator nor do you work at FB), the real elephant in the room is that HN really needs to a better solution for vote collusion. I am already familiar with the guidelines, and I usually follow this rule to a tee, but the optics here are damning. What I'd really like to see is this discussion steered back on topic. It was originally interesting and productive. I like talking about web technologies; it is my passion.
    - SquareWheel 9y ago
      Frankly I only downvoted because of the unfounded accusations of Facebook shilling. There's a certain level of pretentiousness in thinking one's comments could only ever be downvoted because somebody was literally paid to do it. And that attitude rubs me the wrong way. To bring it back to the discussion itself, I'm also a huge fan of web technologies, so I'm always glad to see further optimizations being made. I'm hesitant to use it now as it's still so early, but would like to see it mature so it can be included as a step in our gulp/grunt build processes.
      - Hydraulix989 9y ago
        Continuing the discussion means not opportunistically taking a cheap shot first. :(
        SquareWheel 9y ago
        You're right, but I also didn't realize until after I'd commented that I was replying to the same author as the parent poster.
- hoschicz 9y ago
  How much marketshare do you think that Javascript will lose once WebAssembly gets mainstream? Has it evolved so much that it's now a language you would pick out of free will? With ES6, I'm hearing that it's actually usable and kinda nice, but every time I use JS for something instead of Python, I get hit with things like the weird typing that you just can't change.
  - Hydraulix989 9y ago
    "How much marketshare do you think that Javascript will lose once WebAssembly gets mainstream?" I'm no fortuneteller, but I suspect that people writing the most demanding client applications for web will be very happy when it does. Browser-desktop convergence wasn't meant to happen through JS, and after the proliferation of the hacks that we have today to get around inherent design flaws in the language, it really shows. "Has it evolved so much that it's now a language you would pick out of free will?" "Free will" is a very good way of putting it. I suspect some Node developers were ex-frontend devs that just didn't want to learn another language. Moreover, the realities of project management, human resource allocation, and fast iteration are the forcing function behind using Electron instead of building a real desktop app.
    - voltagex_ 9y ago
      > are the forcing function behind using Electron instead of building a real desktop app. I have to work hard to not fall into this way of thinking most of the time. I am as frustrated as you with the proliferation of Electron apps. But a lot of the time it boils down to: Application X would not exist if Electron did not exist. Cross platform dev is hard. More programmers, no matter what language they use, is a positive thing. Lowering the barrier to entry via things like Chrome Dev Tools, Electron and related technologies is a good thing. After all, how many people are still using the first programming language they started with?
      - _pmf_ 9y ago
        > More programmers, no matter what language they use, is a positive thing. Lowering the barrier to entry via things like Chrome Dev Tools, Electron and related technologies is a good thing. Why? Are more plumbers also a good thing, even though this reduces the average wage of the plumber and the quality of plumbing?
- denois 9y ago
  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.
dennykane 9y ago
The existence of this project says that JS is supposed to be taken as a very serious programming language now. But what, exactly, is it that is so serious that JS can be used for, which will start making hardcore developer's minds see its unlimited possibilities, as a deeply systematic runtime environment? I'm saying its something like: https://linuxontheweb.appspot.com/about https://linuxontheweb.appspot.com/about
slackingoff2017 9y ago
This looks cool, but is it doing anything that an engine like V8 doesn't already do? Since the JS still isn't actually compiled the browser engine still parses everything and does its own optimizations. Are there some benchmarks showing actual speed improvements?
NTillmann 9y ago
Hi, I am Nikolai Tillmann, a developer on the Prepack project. I am happy to answer any questions!
- technion 9y ago
  Thanks for posting here Nikolai. In terms of the development status, does the current codebase generally work with React? I'm happy to throw this at my codebase and report bugs, but whether React itself (which is ~95% of my bundle size) is expected to work (unlike some other optimising products) would say a lot about what the expectation might be.
- CaveTech 9y ago
  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?
- pbreit 9y ago
  Can you provide any indications of the size of performance improvements?
  - NTillmann 9y ago
    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.
- artursapek 9y ago
  Can it be plugged into webpack for production builds? (I know it's not production ready yet)
  - phpnode 9y ago
    Yes, as of about 25 mins ago - https://github.com/gajus/prepack-webpack-plugin https://github.com/gajus/prepack-webpack-plugin
jamescostian 9y ago
The examples are very far from the JS I see and read, but this is definitely a very useful tool. It seems like gcc -Olevel. It would be interesting to incorporate some sort of tailoring for JS engines into this, like how a compiler might try to make x86-specific optimizations. For example, if you know your target audience mostly runs Chrome (or if the code is to be run by node), you might apply optimizations to change the code to be more performant on V8 (see https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k... for example). I love it and can't wait to use it on some projects!
- djsumdog 9y ago
  The examples seem more typical of Coffeescript output.
  - SamBam 9y ago
    You've mentioned that a couple times, but I'm really not seeing it. What to you looks like coffeescript there?
    - jessaustin 9y ago
      "Coffeescript output" is javascript so it doesn't look much like coffeescript. Presumably GP doesn't like the specific javascript idioms to which coffeescript transpiles.
aylmao 9y ago
Facebook's javascript / PL game doesn't disappoint. This is awesome!
vikeri 9y ago
I was under the impression that V8 and the like are so optimized that this would give marginal gains. Would love to be wrong though. Do you have any performance benchmarks?
- jamescostian 9y ago
  One of the examples contains a function to calculate the nth fibonacci number, and then a variable uses the result of that function. Prepack doesn't seem to optimize for V8 in particular; rather, it just does some calculations ahead of time. V8 cannot possibly do these optimizations. How would it know that e.g. my code tries to calculate PI to 1000 decimals? That's where prepack steps in and calculates PI to 1000 decimals for you during your build-step, so that the JS you ship doesn't have to do that calculation.
- gavinpc 9y ago
  The benefit of this would be at runtime when implementing interpreters: > experiment with JavaScript features by tweaking a JavaScript engine written in JavaScript, all hosted just in a browser; think of it as a "Babel VM", realizing new JavaScript features that cannot just be compiled away I've been playing with making toy languages inside of Javascript, and I believe there's lots of untapped power there. The paradigm battles don't have to be: we can run all sorts of paradigms in the same VM, with data executing as code. This means that you can decompose expressions to see where they came from (e.g. the steps in a state machine that yielded an evaluation result). If you believe (as I do) that invisibility-by-default is one of the greatest pain points in the history of computing, then these sorts of approaches are essential. The problem with doing that is that some things will be slower than they would in "native" JS. I've been proceeding anyway and thinking that could be dealt with later. So I'm bookmarking this, because it attacks that exact problem: runtime-compilation of generated AST's. The name is a little unfortunate, in that respect, though, especially since it will make people think it's a build tool like Webpack. Webpack is for dead fish. This is incomparably more powerful. edit so to answer your original question, this would piggyback on the optimizations of the VM (V8 or SpiderMonkey, or whatever), taking for granted that JS which is not needlessly verbose (as generated code must sometimes be), can be run nearly optimally.
tyingq 9y ago
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?
- NTillmann 9y ago
  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.
  - Hydraulix989 9y ago
    The real litmus test: Does FB use it in production yet?
  - newman314 9y ago
    Has this been tried on popular JS packages such as jquery?
hdhzy 9y ago
This looks very good indeed but the lack of initial data model very severely limits the production usability of this tool. You can't use "document" and "window" ... It's the same problem TypeScript have/had that for external libs you need definition files for it to work. Now if we had TypeScript-to-assumeDataProperty generator that would be VERY interesting!
- kylemathews 9y ago
  This is a very early release. I'm sure there'll be a "build for the web" mode soon enough.
ianbicking 9y ago
A long time ago there was a theory about using Guile (the GNU Scheme) as a general interpreter for languages using partial evaluation: you write an interpreter for a language in Scheme, use a given program as input, and run an optimizer over the program. This turns your interpreter into a compiler. I played around with the concept (making a Tcl interpreter), and it even kind of worked, often creating reasonably readable output. Prepack looks like the same kind of optimizer – it could be a fun task to write an interpreter and see if this can turn it into a compiler/transpiler.
- kryptiskt 9y ago
  Pypy does it a lot like that.
  - progval 9y ago
    RPython, to be more accurate
- dgreensp 9y ago
  What you're talking about -- writing an interpreter that's optimized into a compiler -- is actually coming in the soon-to-be-released Java 9. Check out Graal and Truffle. I'm pretty excited to play with it at some point. Prepack reminds me more of a "supercompiler," because it focuses on partial evaluation rather than optimization.
  - ianbicking 9y ago
    Your "supercompiler" phrase made me think about what happens if you start applying the partial evaluation over and over. Of course nothing happens... unless you know something more than what you knew before. Which you might! That in turn made me think of the Wolfram Language, which feels like this to me – you declare things, and as the set of declarations continues the language starts to "know" more things, and your statements become more concrete. This is interesting because it's all automated, you can undo things, change them, implicitly loop them by considering multiple possibilities. I'm not sure you could take Prepack and do this. But it sure seems interesting. A kind of partial evaluation coding notebook... not so unlike a symbolic spreadsheet I suppose.
Waterluvian 9y ago
What percentage of typical code is packable like this? What I really need is a way to easily determine, "is it worth bothering with a tool like this?"
chmod775 9y ago
I 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 initialization), to get it to make any optimizations at all. Very impressive overall.
- michaelmior 9y ago
  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`.
  - cblappert 9y ago
    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.
- MaxLeiter 9y ago
  Seems to not support some implementations of require() - did you have any problems?
- maaaats 9y ago
  How was the speedup? That's what I would use this for, not some small minification gains.
  - slackingoff2017 9y ago
reaction 9y ago
Has anyone used this with webpack + reactjs ?
iamleppert 9y ago
Not a comment about the tool, which looks cool and well done. It's sad that there are developers and projects who write the type of code that causes these sorts of performance trade offs. I stopped writing this kind of fancy code a long time ago when I realized it wasn't worth it. You're just shooting yourself in the foot in the long run. I think static analysis performance optimization tools are great but a certain part of me thinks it just raises the waterline for more shitty code and awful heavy frameworks that sacrifice the user experience for the developer experience. "Just run it through the optimizer" so we don't actually have to think about what a good design looks like...
- mpolichette 9y ago
  I disagree with the premise a little bit. A tool like this could allow you to write code which is better suited for a human to read/maintain, but then still get the performance optimizations of pre-computed results being sent over the wire.
- gavinpc 9y ago
  There is some confusion in this thread about the purpose of this tool, which is targeted at generated code—specifically, code generated by other compilers. In order to get language features that don't exist in javascript, code has to be generated in a more or less context-agnostic way. This (as I understand it) brings more context to bear, to reduce the cost of the new abstractions for your specific usage.
  - djsumdog 9y ago
    Ah that makes sense. I was wondering why the examples all looked like Coffeescript output.
  - wereHamster 9y ago
    Why improve the compilers when we can have yet another tool to layer on top of our ever growing tool stack.
    - 9y ago
kccqzy 9y ago
This reminds me of Morte, an experimental mid-level functional language created by Gabriel Gonzalez. They both seem to be super-optimizing, that is partially executing the program in question. Of course it is a great deal easier to do in a functional language than JavaScript. http://www.haskellforall.com/2014/09/morte-intermediate-language-for-super.html http://www.haskellforall.com/2014/09/morte-intermediate-lang...
KirinDave 9y ago
I wonder what this would do to Purescript code?
frik 9y ago
How 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 one to read the docu first)
- jagthebeetle 9y ago
  This was my immediate question. For want of a more rigorous test, the online closure compiler service (https://closure-compiler.appspot.com/home https://closure-compiler.appspot.com/home) failed to produce equivalent or shorter output for all but the first example.
- matt4077 9y ago
  Closure compiler optimizes code size, while this optimises code execution.
  - bpicolo 9y ago
    I see that it claims that, but that's not entirely true. The closure compiler does a variety of perf optimizations as well (e.g. inlining). Closure is really a great compiler, it's just a shame it doesn't interact well (that is, at all) with the modern JS ecosystem.
    - tadeegan 9y ago
      As someone who works on Closure Compiler, this is one of my biggest gripes with the project. Things are getting better though! CC now supports node's module resolution algorithm. It works pretty well with Es6 imports but not so well with CommonJS (mostly because the exports are impossible to statically analyze). Within Google, CC is heading towards being a an optimizing backend for other less painful languages such as Typescript (tsickle) and the yet-to-be-released J2CL compiler. CC does pretty well with these examples (our debugger is not quite as flashy): https://closure-compiler-debugger.appspot.com/#input0%3D%252F%252F%2520From%2520Prepack.io%2520%2522Hello%2520World%2522%250Avar%2520s%253B%250A(function%2520()%2520%257B%250A%2520%2520function%2520hello()%2520%257B%2520return%2520'hello'%253B%2520%257D%250A%2520%2520function%2520world()%2520%257B%2520return%2520'world'%253B%2520%257D%250A%2520%2520s%2520%253D%2520hello()%2520%252B%2520'%2520'%2520%252B%2520world()%253B%250A%257D)()%253B%250A%250Aconsole.log(s)%253B%26input1%26conformanceConfig%26externs%26refasterjs-template%26includeDefaultExterns%3D1%26CHECK_SYMBOLS%3D1%26MISSING_PROPERTIES%3D1%26TRANSPILE%3D1%26CHECK_TYPES%3D1%26COMPUTE_FUNCTION_SIDE_EFFECTS%3D1%26FOLD_CONSTANTS%3D1%26DEAD_ASSIGNMENT_ELIMINATION%3D1%26INLINE_CONSTANTS%3D1%26INLINE_FUNCTIONS%3D1%26INLINE_VARIABLES%3D1%26FLOW_SENSITIVE_INLINE_VARIABLES%3D1%26INLINE_PROPERTIES%3D1%26REMOVE_DEAD_CODE%3D1%26EXTRACT_PROTOTYPE_MEMBER_DECLARATIONS%3D1%26REMOVE_UNUSED_PROTOTYPE_PROPERTIES%3D1%26REMOVE_UNUSED_VARIABLES%3D1%26COLLAPSE_VARIABLE_DECLARATIONS%3D1%26COLLAPSE_ANONYMOUS_FUNCTIONS%3D1%26COLLAPSE_PROPERTIES%3D1%26DEVIRTUALIZE_PROTOTYPE_METHODS%3D1%26REWRITE_FUNCTION_EXPRESSIONS%3D1%26DISAMBIGUATE_PROPERTIES%3D1%26AMBIGUATE_PROPERTIES%3D1%26PROPERTY_RENAMING%3D1%26OPTIMIZE_CALLS%3D1%26OPTIMIZE_PARAMETERS%3D1%26OPTIMIZE_RETURNS%3D1%26MOVE_FUNCTION_DECLARATIONS%3D1%26MARK_NO_SIDE_EFFECT_CALLS%3D1%26CROSS_MODULE_CODE_MOTION%3D1%26CROSS_MODULE_METHOD_MOTION%3D1%26CLOSURE_PASS%3D1%26PRETTY_PRINT%3D1 https://closure-compiler-debugger.appspot.com/#input0%3D%252...
gajus 9y ago
A webpack plugin for prepack. https://github.com/gajus/prepack-webpack-plugin https://github.com/gajus/prepack-webpack-plugin
deleted 9y ago
[deleted]
dschnurr 9y ago
This is cool–it's worth mentioning that you might be trading runtime performance for bundle size though, here's a contrived example to demonstrate: http://i.imgur.com/38CR3Ws.jpg http://i.imgur.com/38CR3Ws.jpg
- evv 9y ago
  Keep in mind that everything is gzipped nowadays, so it may not make a big difference in network usage. Although it is still likely to cause some memory overhead
  - franciscop 9y ago
    No, I have done and pubpished an article about how gzip works with JS and the result will compress pretty well. Not better than the code, but I would guess within the same order of magnitude.
    - vmasto 9y ago
      JavaScript parsing is still a huge bottleneck. 1mb of it will still take 1 whole second to parse in V8 (note: just to parse it, not actually evaluate or run it!).
      - franciscop 9y ago
        I think this is (so far) for snippets. I agree otherwise though
- zupa-hu 9y ago
  It's in beta stage, so that's not unexpected. They can easily add a cost function later that considers multiple parameters.
yladiz 9y ago
I hate to bring this up whenever I see a Facebook project, but it still warrants saying: the patents clause in this project, like in others including React, is too broad. I really wish they made a "version 3" that limited the scope of the revocation to patents pertaining to the software in question, e.g. Prepack, React, rather than a blanket statement that covers any patent assertion against Facebook. While I suppose the likelihood of this occurring is small, I can imagine a company holding some valid patents, such as something related to VR, that aren't related to Prepack that Facebook infringes upon, as well as using a software that Facebook produces like Prepack, sue Facebook for infringement, and then losing the right to use Prepack as a result. From my understanding these kinds of clauses are beneficial overall, but the specific one that Facebook uses is too broad. Tangentially related: what would happen if you did sue Facebook for patent infringement, and continued to use this software?
- andreyf 9y ago
  IANAL, but most likely: nothing. Less likely: Facebook counter-sues you for patent infringement and (maybe?) has a slightly better case as long as you keep using it. Your lawyers tell your engineers to rewrite everything without Facebook technologies and it's all a big pain in the ass and you regret ever suing Facebook for patent infringement.
  - K2L8M11N2 9y ago
    Would the same still apply to the output of the programs, e.g. could you keep the optimized code generated by Prepack?
    - andreyf 9y ago
      That's for the court to decide, assuming Facebook has patents on Webpack. To minimize liability, probably best not to.
- abritinthebay 9y ago
  This gets brought up every time, even after many times it's been clarified (even by lawyers) that it gives you more rights overall (as the downsides to it are true either way). Remember - without that patent grant you have no rights to any of Facebook's patents anyhow. With it, you do. So the worst case is that you'd be in the same situation if you didn't have the grant.
dandare 9y ago
What is the business model for a tool like this? Who has the resource to spend man/years of work while also create such a fantastic, simple yet comprehensive landing page?
- jfarmer 9y ago
  It's a Facebook project.
- yoodenvranx 9y ago
  On the very bottom of the page it says "Facebook"
- kylemathews 9y ago
  It's by Facebook. They have 1.x billion users across their web and mobile products all of which run JavaScript. Tiny improvements in product performance equals big $$$. Easily justifies efforts like this. And the rest of us get to free-ride :-)
ericmcer 9y ago
Pretty cool, it did not make much difference in my application size, as it has very little static data in it. It seems pretty rare to do something like: fib(2); and more common to do: getInputOrHttpOrSomethingAsync().then(function(a){fib(a)});
Kamgunz 9y ago
Very interesting, nobody mentioned how formal and quite technical this README is, it goes really into details about what it does, and even future plans laid in three sections across 30 bullet points. One bullet point in the really far future sections said "instrument JavaScript code [in a non observable way]" emphasis mine, that part was noted in several other bullet points. It seems to me every compiler/transpiler/babel-plguin changes JavaScript code in a non observable way, no? Just a theory, but that undertone sounds to me like the ability to change/inject into JavaScript code undetectably on the fly in some super easy way. Just another day at Facebook's office...
- CGamesPlay 9y ago
  Your tin foil hat can go away when you consider that you're instrumenting code that will permanently run in an observable sandbox. You control the server (for node) and can watch what external requests it's making; and while you don't directly control the client, you do have access (via the web inspector) to all external requests it's making.
arota 9y ago
This is exciting, and has a lot of potential to significantly improve JS library initialization time. I wonder if this is the same project[0] Sebastian McKenzie previewed at React Europe 2016? [0] https://www.youtube.com/watch?v=xbZzahWakGs https://www.youtube.com/watch?v=xbZzahWakGs
- hzoo 9y ago
  Yep it is! https://twitter.com/dan_abramov/status/859817680857165824 https://twitter.com/dan_abramov/status/859817680857165824
- sergioramos 9y ago
  It is. Source: https://twitter.com/dan_abramov/status/859817680857165824 https://twitter.com/dan_abramov/status/859817680857165824
iMark 9y ago
The destination page looks uncomfortably like Webpack's. Not the best idea, imho.
untog 9y ago
This should have a big impact on the "cost of small modules", as outlined here: https://nolanlawson.com/2016/08/15/the-cost-of-small-modules/ https://nolanlawson.com/2016/08/15/the-cost-of-small-modules... Which is to say, one of its most effective use cases will be making up for deficiencies in Webpack, Browserify and RequireJS. Which I'm a little ambivalent about - I wish we could have seen improvements to those tools (it's possible, as shown by Rollup and Closure Compiler) rather than adding another stage to filter our JavaScript through. But progress is progess.
- deleted 9y ago
  [deleted]
- k__ 9y ago
  I saw a Webpack example and it looked smaller & faster. So it seems like a good thing.
bthornbury 9y ago
Awesome project, the performance gains seem real, but why wouldn't these optimizations be happening at the javascript JIT level in the vm? (serious question) React / javascript programming, is the most complex environment I've ever dug into, and it's only getting more complex. create-react-app is great for hiding that complexity until you need to do something it doesn't support and then it's like gasping for air in a giant sea of javascript compilers.
- throwawaymsft 9y ago
  download js -> run through JIT compiler -> execute vs. run through JIT compiler -> download js -> execute Whatever overhead the JIT compiler adds will be latency for the user.
  - mbel 9y ago
    In the second case it's AOT (ahead of time) not JIT (just in time) compiler.
- franciscop 9y ago
  Because they'd have to happen every time for every user, so there'd be no real gain there. It has to happen as the code is published in .min.
chime 9y ago
This has promise but still needs more work. I added one line to their 9 line demo ( https://prepack.io/repl.html https://prepack.io/repl.html ) and it ballooned to 1400+ lines of junk: (function() { function fib(x) { y = Date.now(); // the useless line I added return x <= 1 ? x : fib(x - 1) + fib(x - 2); } let x = Date.now(); if (x * 2 > 42) x = fib(10); global.result = x; })(); I understand Date might not be acceptable for inner loops but a lot of my code that deals with scheduling would benefit significantly if I could precompute some of the core values/arrays using a tool like prepack.
- shuzchen 9y ago
  It's not a useless line, because prepack has no idea what Date.now() does (there are no guarantees in javascript that it hasn't been replaced with another function). It might mutate some global state somewhere, so the resulting code needs to call Date.now() as often as it would've if fib(10) was called. Basically the output is the unrolled version of the recursion, which cuts down on function invocation (comparatively expensive in dynamic languages). If you replaced the line with say: `var y = 4;` you'll notice that it has been optimized out.
  - KallDrexx 9y ago
    But should it still unroll the recursive calls and balloon the code out just because a mutatable function call was made, or should it leave it as an actual recursive function call.
  - magicalist 9y ago
    > Basically the output is the unrolled version of the recursion, which cuts down on function invocation (comparatively expensive in dynamic languages). You're right about why it's included, but this is a bug, not a feature. If this is a hot function it'll be optimized. The recursive call is a known, non-dynamic invocation so the function location will be inlined leaving just the fairly low function call overhead itself. There's a reason nobody does arbitrary-length loop unrolls. I would definitely bet that this is a bug to be fixed :) Right now you can see this if you call fib(20) in that example...the compiler times out while trying to unroll that far. Clearly that behavior won't stick around.
avodonosov 9y ago
How does one measures performance improvement for a web page gained from such tools?
drumttocs8 9y ago
Coming from a non-CS background, I've always wondered why you can't "convert" code from one framework or paradigm to another. For instance, converting a project from jQuery to React. If you can define the outputs, why can't you redefine the inputs? That's what it seems like this project does... I suppose converting frameworks would be a few orders of magnitudes harder though.
- batmansmk 9y ago
  Can you turn lead in gold? Maybe using nuclear transmutation. But the potential cost of the process seems higher than the benefits. Can you convert a code base to React from Angular? Maybe, but the effort to write this converter is higher than rewriting the code base.
- _pmf_ 9y ago
  The problem is not converting; the problem is converting in a way that the result is usable by a human.
- joslin01 9y ago
  Different design patterns
kasper93 9y ago
I think that just in time compilers are better at doing thier things. Sure it is nice project that can interpret and print preprocessed js, but I think it might in fact not bring speed in most cases. And the current state doesn't even know how to constant fold this loop. function foo() { const bar = 42; for (let i = 0; i <= bar; i++) { if (i === bar) { return bar; } } };
- yairhaimo 9y ago
  As long as the ahead of time optimizations that dont have a large enough negative drawback in another criteria (speed vs size) are welcomed by me, even if the JIT can do the same optimizations too. Regarding your code example, maybe prepack was changed in the past week and a half, but it is folded quite fine when i tried it: (function() { function foo() { const bar = 42; for (let i = 0; i <= bar; i++) { if (i === bar) { return bar; } } }; console.log(foo()); })();
jlebrech 9y ago
I want something that can separate my code into what can be precompiled into wasm and what has to stay in JS. maybe just insert comments so i can see what needs to be done.
kamranahmed_se 9y ago
> helps make javascript code more efficient https://github.com/facebook/prepack/issues/543 https://github.com/facebook/prepack/issues/543 Are you sure?
k__ 9y ago
Just throw your webpack bundles in and be amazed.
Traubenfuchs 9y ago
I can't get anything to work in it. Just for fun I put the not minifed vue.js source inside and I get: null or undefined TypeError at repl:537:23 at repl:5:16 at repl:2:2
xg15 9y ago
function define() {...} function require() {...} define("one", function() { return 1; }); define("two", function() { return require("one") + require("one"); }); define("three", function() { return require("two") + require("one"); }); three = require("three"); ---> three = 3; There is a certain irony that now it's possible to do optimisations like that in javascript - a dynamically typed language with almost no compile time guarantees. Meanwhile java used to have easy static analysis as a design goal (and I think a lot of boilerplate is due to that goal) but the community relies so much on reflection, unsafe access, dynamic bytecode generation, bytecode parsing etc that such an optimisation would be almost impossible to get right.
- lurker456 9y ago
  it's possible to do such optimizations for a (safe) subset of javascript, such as these pure functions. Arguably java has a larger subset even today.
  - xg15 9y ago
    I think the remarkable point in the above optimisation was that the non-pure functions define() and require() were also subject of optimisation even though the optimizer had no special knowledge about them. Using symbolic execution, the optimizer nevertheless was able to reason about them.
austincheney 9y ago
Errors on all my code: * http://prettydiff.com/lib/ http://prettydiff.com/lib/ * https://raw.githubusercontent.com/prettydiff/biddle/master/biddle.js https://raw.githubusercontent.com/prettydiff/biddle/master/b...
mstade 9y ago
I'm happy to see there's an option to use this with an AST as input, more tools like this should follow suit. Hopefully it can then push us to a place where there's a standard JS AST such that we don't reinvent that wheel over and over. Babel seems to be winning here, but I don't think it matters so much which one wins so long as any one does. This tool looks interesting, particularly the future direction of it, but I'm weary about efficiency claims without a single runtime metric posted. The claims may be true, initializing is costly, but so is parsing huge unrolled loops. For an optimization tool, I'd hope to see pretty strong metrics to go along with the strong claims, but maybe that is coming? Interesting work, nonetheless!

836 points by jimarcey 9y ago

I did an experiment to look for synergy from combining Prepack with the Closure compiler: http://www.syntaxsuccess.com/viewarticle/combining-prepack-and-closure-compiler http://www.syntaxsuccess.com/viewarticle/combining-prepack-a... The result was pretty good.

Hydraulix989 9y ago

Looks 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 most people/users actually have installed on their computers/devices and use won't support it for another 3-5 years. Meanwhile, the everyday JS coder wants to use ES7 from last year but has to settle for the bandaid solution of Babel because the browsers aren't going to be ready for it yet. Google's Native Client had the right idea but never quite took off (nor was it ever adopted by anybody else): https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf https://static.googleusercontent.com/media/research.google.c... This type of working solution would also stave off the Electron-ification of desktop apps (which means an effective halving of my laptop battery life, spinning up wasted CPU cycles -- like 13% being spent on rendering a blinking cursor, and reducing my computer's RAM by a factor of eight as just about everything I run on my computer now is its own separate bloated Chrome instance -- Slack, Atom, VSCode, Skype, Telegram, Discord, Spotify, ...). EDIT: Facebook employees, please stop downvoting my quality content. It is getting tiresome.

NTillmann 9y ago
Prepack is quite complementary to traditional compilers. It's strength is that it comes with full knowledge of the JavaScript built-ins, and it uses that to pre-evaluate the code at compile time. In an extreme case, an entire program can get reduced to the final result.
- Hydraulix989 9y ago
  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.
dennykane 9y ago
I was right there a year or two ago developing portable native client things for my project, Linux on the Web (I was able to get vim and python running). Projects like that can pioneer a whole lot of new techniques and infrastructure that can be very easily applied to whatever technology is eventually going to win out.
- Hydraulix989 9y ago
  @dennykane It's a shame seeing your comments are getting downvoted on here too. It really leaves me with a bad impression about how FB operates. @rattray Even without access, downvotes don't just happen out of nowhere; you have to admit that this just looks too obvious to any reasonable person. I'm curious what you thought was downvote-worthy of my original post pre-edit? I get it, rules are rules, and this is a matter of principle.
  - seattle_spring 9y ago
    Late to the party, but I suspect you were downvoted for your arrogant and condescending tone, combined with your sense of unsubstantiated victimhood.
    - deleted 9y ago
      [deleted]
    - Hydraulix989 9y ago
      I'm not sure how you can leap to conclusions about my tone of voice from textual comments? One user @rattray is even citing quotes from the rule book to me here, and somehow I'm the one being condescending? But hey, regardless of the situation, nobody deserves to be insulted like this! You can do better, man. I can give you the benefit of the doubt; I suspect you wouldn't ever act this way in person to anybody. I also don't see how any sort of purported victimhood would be unsubstantiated (I just don't happen to take website comments from strangers all that seriously): I'm just trying to talk about WebAssembly, and this troll spends their Friday night posting these kinds of inflammatory comments on nearly-dead threads from the beginning of the week. :( As a reminder, you're breaking the very first rule -- "be civil" -- since we're sticklers about the rules here. You are acting very rude!
rattray 9y ago
From the guidelines: > Please resist commenting about being downvoted. It never does any good, and it makes boring reading. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Disclaimer: I do not work at Facebook.
- Hydraulix989 9y ago
  While I appreciate your vigilantism (given you aren't actually a moderator nor do you work at FB), the real elephant in the room is that HN really needs to a better solution for vote collusion. I am already familiar with the guidelines, and I usually follow this rule to a tee, but the optics here are damning. What I'd really like to see is this discussion steered back on topic. It was originally interesting and productive. I like talking about web technologies; it is my passion.
  - SquareWheel 9y ago
    Frankly I only downvoted because of the unfounded accusations of Facebook shilling. There's a certain level of pretentiousness in thinking one's comments could only ever be downvoted because somebody was literally paid to do it. And that attitude rubs me the wrong way. To bring it back to the discussion itself, I'm also a huge fan of web technologies, so I'm always glad to see further optimizations being made. I'm hesitant to use it now as it's still so early, but would like to see it mature so it can be included as a step in our gulp/grunt build processes.
    - Hydraulix989 9y ago
      Continuing the discussion means not opportunistically taking a cheap shot first. :(
      - SquareWheel 9y ago
        You're right, but I also didn't realize until after I'd commented that I was replying to the same author as the parent poster.
hoschicz 9y ago
How much marketshare do you think that Javascript will lose once WebAssembly gets mainstream? Has it evolved so much that it's now a language you would pick out of free will? With ES6, I'm hearing that it's actually usable and kinda nice, but every time I use JS for something instead of Python, I get hit with things like the weird typing that you just can't change.
- Hydraulix989 9y ago
  "How much marketshare do you think that Javascript will lose once WebAssembly gets mainstream?" I'm no fortuneteller, but I suspect that people writing the most demanding client applications for web will be very happy when it does. Browser-desktop convergence wasn't meant to happen through JS, and after the proliferation of the hacks that we have today to get around inherent design flaws in the language, it really shows. "Has it evolved so much that it's now a language you would pick out of free will?" "Free will" is a very good way of putting it. I suspect some Node developers were ex-frontend devs that just didn't want to learn another language. Moreover, the realities of project management, human resource allocation, and fast iteration are the forcing function behind using Electron instead of building a real desktop app.
  - voltagex_ 9y ago
    > are the forcing function behind using Electron instead of building a real desktop app. I have to work hard to not fall into this way of thinking most of the time. I am as frustrated as you with the proliferation of Electron apps. But a lot of the time it boils down to: Application X would not exist if Electron did not exist. Cross platform dev is hard. More programmers, no matter what language they use, is a positive thing. Lowering the barrier to entry via things like Chrome Dev Tools, Electron and related technologies is a good thing. After all, how many people are still using the first programming language they started with?
    - _pmf_ 9y ago
      > More programmers, no matter what language they use, is a positive thing. Lowering the barrier to entry via things like Chrome Dev Tools, Electron and related technologies is a good thing. Why? Are more plumbers also a good thing, even though this reduces the average wage of the plumber and the quality of plumbing?
denois 9y ago
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.

dennykane 9y ago

The existence of this project says that JS is supposed to be taken as a very serious programming language now. But what, exactly, is it that is so serious that JS can be used for, which will start making hardcore developer's minds see its unlimited possibilities, as a deeply systematic runtime environment? I'm saying its something like: https://linuxontheweb.appspot.com/about https://linuxontheweb.appspot.com/about

slackingoff2017 9y ago

This looks cool, but is it doing anything that an engine like V8 doesn't already do? Since the JS still isn't actually compiled the browser engine still parses everything and does its own optimizations. Are there some benchmarks showing actual speed improvements?

NTillmann 9y ago

Hi, I am Nikolai Tillmann, a developer on the Prepack project. I am happy to answer any questions!

technion 9y ago
Thanks for posting here Nikolai. In terms of the development status, does the current codebase generally work with React? I'm happy to throw this at my codebase and report bugs, but whether React itself (which is ~95% of my bundle size) is expected to work (unlike some other optimising products) would say a lot about what the expectation might be.
CaveTech 9y ago
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?
pbreit 9y ago
Can you provide any indications of the size of performance improvements?
- NTillmann 9y ago
  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.
artursapek 9y ago
Can it be plugged into webpack for production builds? (I know it's not production ready yet)
- phpnode 9y ago
  Yes, as of about 25 mins ago - https://github.com/gajus/prepack-webpack-plugin https://github.com/gajus/prepack-webpack-plugin

jamescostian 9y ago

The examples are very far from the JS I see and read, but this is definitely a very useful tool. It seems like gcc -Olevel. It would be interesting to incorporate some sort of tailoring for JS engines into this, like how a compiler might try to make x86-specific optimizations. For example, if you know your target audience mostly runs Chrome (or if the code is to be run by node), you might apply optimizations to change the code to be more performant on V8 (see https://github.com/petkaantonov/bluebird/wiki/Optimization-killers https://github.com/petkaantonov/bluebird/wiki/Optimization-k... for example). I love it and can't wait to use it on some projects!

djsumdog 9y ago
The examples seem more typical of Coffeescript output.
- SamBam 9y ago
  You've mentioned that a couple times, but I'm really not seeing it. What to you looks like coffeescript there?
  - jessaustin 9y ago
    "Coffeescript output" is javascript so it doesn't look much like coffeescript. Presumably GP doesn't like the specific javascript idioms to which coffeescript transpiles.

aylmao 9y ago

Facebook's javascript / PL game doesn't disappoint. This is awesome!

vikeri 9y ago

I was under the impression that V8 and the like are so optimized that this would give marginal gains. Would love to be wrong though. Do you have any performance benchmarks?

jamescostian 9y ago
One of the examples contains a function to calculate the nth fibonacci number, and then a variable uses the result of that function. Prepack doesn't seem to optimize for V8 in particular; rather, it just does some calculations ahead of time. V8 cannot possibly do these optimizations. How would it know that e.g. my code tries to calculate PI to 1000 decimals? That's where prepack steps in and calculates PI to 1000 decimals for you during your build-step, so that the JS you ship doesn't have to do that calculation.
gavinpc 9y ago
The benefit of this would be at runtime when implementing interpreters: > experiment with JavaScript features by tweaking a JavaScript engine written in JavaScript, all hosted just in a browser; think of it as a "Babel VM", realizing new JavaScript features that cannot just be compiled away I've been playing with making toy languages inside of Javascript, and I believe there's lots of untapped power there. The paradigm battles don't have to be: we can run all sorts of paradigms in the same VM, with data executing as code. This means that you can decompose expressions to see where they came from (e.g. the steps in a state machine that yielded an evaluation result). If you believe (as I do) that invisibility-by-default is one of the greatest pain points in the history of computing, then these sorts of approaches are essential. The problem with doing that is that some things will be slower than they would in "native" JS. I've been proceeding anyway and thinking that could be dealt with later. So I'm bookmarking this, because it attacks that exact problem: runtime-compilation of generated AST's. The name is a little unfortunate, in that respect, though, especially since it will make people think it's a build tool like Webpack. Webpack is for dead fish. This is incomparably more powerful. edit so to answer your original question, this would piggyback on the optimizations of the VM (V8 or SpiderMonkey, or whatever), taking for granted that JS which is not needlessly verbose (as generated code must sometimes be), can be run nearly optimally.

tyingq 9y ago

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?

NTillmann 9y ago
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.
- Hydraulix989 9y ago
  The real litmus test: Does FB use it in production yet?
- newman314 9y ago
  Has this been tried on popular JS packages such as jquery?

hdhzy 9y ago

This looks very good indeed but the lack of initial data model very severely limits the production usability of this tool. You can't use "document" and "window" ... It's the same problem TypeScript have/had that for external libs you need definition files for it to work. Now if we had TypeScript-to-assumeDataProperty generator that would be VERY interesting!

kylemathews 9y ago
This is a very early release. I'm sure there'll be a "build for the web" mode soon enough.

ianbicking 9y ago

A long time ago there was a theory about using Guile (the GNU Scheme) as a general interpreter for languages using partial evaluation: you write an interpreter for a language in Scheme, use a given program as input, and run an optimizer over the program. This turns your interpreter into a compiler. I played around with the concept (making a Tcl interpreter), and it even kind of worked, often creating reasonably readable output. Prepack looks like the same kind of optimizer – it could be a fun task to write an interpreter and see if this can turn it into a compiler/transpiler.

kryptiskt 9y ago
Pypy does it a lot like that.
- progval 9y ago
  RPython, to be more accurate
dgreensp 9y ago
What you're talking about -- writing an interpreter that's optimized into a compiler -- is actually coming in the soon-to-be-released Java 9. Check out Graal and Truffle. I'm pretty excited to play with it at some point. Prepack reminds me more of a "supercompiler," because it focuses on partial evaluation rather than optimization.
- ianbicking 9y ago
  Your "supercompiler" phrase made me think about what happens if you start applying the partial evaluation over and over. Of course nothing happens... unless you know something more than what you knew before. Which you might! That in turn made me think of the Wolfram Language, which feels like this to me – you declare things, and as the set of declarations continues the language starts to "know" more things, and your statements become more concrete. This is interesting because it's all automated, you can undo things, change them, implicitly loop them by considering multiple possibilities. I'm not sure you could take Prepack and do this. But it sure seems interesting. A kind of partial evaluation coding notebook... not so unlike a symbolic spreadsheet I suppose.

Waterluvian 9y ago

What percentage of typical code is packable like this? What I really need is a way to easily determine, "is it worth bothering with a tool like this?"

chmod775 9y ago

I 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 initialization), to get it to make any optimizations at all. Very impressive overall.

michaelmior 9y ago
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`.
- cblappert 9y ago
  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.
MaxLeiter 9y ago
Seems to not support some implementations of require() - did you have any problems?
maaaats 9y ago
How was the speedup? That's what I would use this for, not some small minification gains.
- slackingoff2017 9y ago

reaction 9y ago

Has anyone used this with webpack + reactjs ?

iamleppert 9y ago

Not a comment about the tool, which looks cool and well done. It's sad that there are developers and projects who write the type of code that causes these sorts of performance trade offs. I stopped writing this kind of fancy code a long time ago when I realized it wasn't worth it. You're just shooting yourself in the foot in the long run. I think static analysis performance optimization tools are great but a certain part of me thinks it just raises the waterline for more shitty code and awful heavy frameworks that sacrifice the user experience for the developer experience. "Just run it through the optimizer" so we don't actually have to think about what a good design looks like...

mpolichette 9y ago
I disagree with the premise a little bit. A tool like this could allow you to write code which is better suited for a human to read/maintain, but then still get the performance optimizations of pre-computed results being sent over the wire.
gavinpc 9y ago
There is some confusion in this thread about the purpose of this tool, which is targeted at generated code—specifically, code generated by other compilers. In order to get language features that don't exist in javascript, code has to be generated in a more or less context-agnostic way. This (as I understand it) brings more context to bear, to reduce the cost of the new abstractions for your specific usage.
- djsumdog 9y ago
  Ah that makes sense. I was wondering why the examples all looked like Coffeescript output.
- wereHamster 9y ago
  Why improve the compilers when we can have yet another tool to layer on top of our ever growing tool stack.
  - 9y ago

kccqzy 9y ago

This reminds me of Morte, an experimental mid-level functional language created by Gabriel Gonzalez. They both seem to be super-optimizing, that is partially executing the program in question. Of course it is a great deal easier to do in a functional language than JavaScript. http://www.haskellforall.com/2014/09/morte-intermediate-language-for-super.html http://www.haskellforall.com/2014/09/morte-intermediate-lang...

KirinDave 9y ago

I wonder what this would do to Purescript code?

frik 9y ago

How 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 one to read the docu first)

jagthebeetle 9y ago
This was my immediate question. For want of a more rigorous test, the online closure compiler service (https://closure-compiler.appspot.com/home https://closure-compiler.appspot.com/home) failed to produce equivalent or shorter output for all but the first example.
matt4077 9y ago
Closure compiler optimizes code size, while this optimises code execution.
- bpicolo 9y ago
  I see that it claims that, but that's not entirely true. The closure compiler does a variety of perf optimizations as well (e.g. inlining). Closure is really a great compiler, it's just a shame it doesn't interact well (that is, at all) with the modern JS ecosystem.
  - tadeegan 9y ago
    As someone who works on Closure Compiler, this is one of my biggest gripes with the project. Things are getting better though! CC now supports node's module resolution algorithm. It works pretty well with Es6 imports but not so well with CommonJS (mostly because the exports are impossible to statically analyze). Within Google, CC is heading towards being a an optimizing backend for other less painful languages such as Typescript (tsickle) and the yet-to-be-released J2CL compiler. CC does pretty well with these examples (our debugger is not quite as flashy): https://closure-compiler-debugger.appspot.com/#input0%3D%252F%252F%2520From%2520Prepack.io%2520%2522Hello%2520World%2522%250Avar%2520s%253B%250A(function%2520()%2520%257B%250A%2520%2520function%2520hello()%2520%257B%2520return%2520'hello'%253B%2520%257D%250A%2520%2520function%2520world()%2520%257B%2520return%2520'world'%253B%2520%257D%250A%2520%2520s%2520%253D%2520hello()%2520%252B%2520'%2520'%2520%252B%2520world()%253B%250A%257D)()%253B%250A%250Aconsole.log(s)%253B%26input1%26conformanceConfig%26externs%26refasterjs-template%26includeDefaultExterns%3D1%26CHECK_SYMBOLS%3D1%26MISSING_PROPERTIES%3D1%26TRANSPILE%3D1%26CHECK_TYPES%3D1%26COMPUTE_FUNCTION_SIDE_EFFECTS%3D1%26FOLD_CONSTANTS%3D1%26DEAD_ASSIGNMENT_ELIMINATION%3D1%26INLINE_CONSTANTS%3D1%26INLINE_FUNCTIONS%3D1%26INLINE_VARIABLES%3D1%26FLOW_SENSITIVE_INLINE_VARIABLES%3D1%26INLINE_PROPERTIES%3D1%26REMOVE_DEAD_CODE%3D1%26EXTRACT_PROTOTYPE_MEMBER_DECLARATIONS%3D1%26REMOVE_UNUSED_PROTOTYPE_PROPERTIES%3D1%26REMOVE_UNUSED_VARIABLES%3D1%26COLLAPSE_VARIABLE_DECLARATIONS%3D1%26COLLAPSE_ANONYMOUS_FUNCTIONS%3D1%26COLLAPSE_PROPERTIES%3D1%26DEVIRTUALIZE_PROTOTYPE_METHODS%3D1%26REWRITE_FUNCTION_EXPRESSIONS%3D1%26DISAMBIGUATE_PROPERTIES%3D1%26AMBIGUATE_PROPERTIES%3D1%26PROPERTY_RENAMING%3D1%26OPTIMIZE_CALLS%3D1%26OPTIMIZE_PARAMETERS%3D1%26OPTIMIZE_RETURNS%3D1%26MOVE_FUNCTION_DECLARATIONS%3D1%26MARK_NO_SIDE_EFFECT_CALLS%3D1%26CROSS_MODULE_CODE_MOTION%3D1%26CROSS_MODULE_METHOD_MOTION%3D1%26CLOSURE_PASS%3D1%26PRETTY_PRINT%3D1 https://closure-compiler-debugger.appspot.com/#input0%3D%252...

gajus 9y ago

A webpack plugin for prepack. https://github.com/gajus/prepack-webpack-plugin https://github.com/gajus/prepack-webpack-plugin

deleted 9y ago

[deleted]

dschnurr 9y ago

This is cool–it's worth mentioning that you might be trading runtime performance for bundle size though, here's a contrived example to demonstrate: http://i.imgur.com/38CR3Ws.jpg http://i.imgur.com/38CR3Ws.jpg

evv 9y ago
Keep in mind that everything is gzipped nowadays, so it may not make a big difference in network usage. Although it is still likely to cause some memory overhead
- franciscop 9y ago
  No, I have done and pubpished an article about how gzip works with JS and the result will compress pretty well. Not better than the code, but I would guess within the same order of magnitude.
  - vmasto 9y ago
    JavaScript parsing is still a huge bottleneck. 1mb of it will still take 1 whole second to parse in V8 (note: just to parse it, not actually evaluate or run it!).
    - franciscop 9y ago
      I think this is (so far) for snippets. I agree otherwise though
zupa-hu 9y ago
It's in beta stage, so that's not unexpected. They can easily add a cost function later that considers multiple parameters.

yladiz 9y ago

I hate to bring this up whenever I see a Facebook project, but it still warrants saying: the patents clause in this project, like in others including React, is too broad. I really wish they made a "version 3" that limited the scope of the revocation to patents pertaining to the software in question, e.g. Prepack, React, rather than a blanket statement that covers any patent assertion against Facebook. While I suppose the likelihood of this occurring is small, I can imagine a company holding some valid patents, such as something related to VR, that aren't related to Prepack that Facebook infringes upon, as well as using a software that Facebook produces like Prepack, sue Facebook for infringement, and then losing the right to use Prepack as a result. From my understanding these kinds of clauses are beneficial overall, but the specific one that Facebook uses is too broad. Tangentially related: what would happen if you did sue Facebook for patent infringement, and continued to use this software?

andreyf 9y ago
IANAL, but most likely: nothing. Less likely: Facebook counter-sues you for patent infringement and (maybe?) has a slightly better case as long as you keep using it. Your lawyers tell your engineers to rewrite everything without Facebook technologies and it's all a big pain in the ass and you regret ever suing Facebook for patent infringement.
- K2L8M11N2 9y ago
  Would the same still apply to the output of the programs, e.g. could you keep the optimized code generated by Prepack?
  - andreyf 9y ago
    That's for the court to decide, assuming Facebook has patents on Webpack. To minimize liability, probably best not to.
abritinthebay 9y ago
This gets brought up every time, even after many times it's been clarified (even by lawyers) that it gives you more rights overall (as the downsides to it are true either way). Remember - without that patent grant you have no rights to any of Facebook's patents anyhow. With it, you do. So the worst case is that you'd be in the same situation if you didn't have the grant.

dandare 9y ago

What is the business model for a tool like this? Who has the resource to spend man/years of work while also create such a fantastic, simple yet comprehensive landing page?

jfarmer 9y ago
It's a Facebook project.
yoodenvranx 9y ago
On the very bottom of the page it says "Facebook"
kylemathews 9y ago
It's by Facebook. They have 1.x billion users across their web and mobile products all of which run JavaScript. Tiny improvements in product performance equals big $$$. Easily justifies efforts like this. And the rest of us get to free-ride :-)

ericmcer 9y ago

Pretty cool, it did not make much difference in my application size, as it has very little static data in it. It seems pretty rare to do something like: fib(2); and more common to do: getInputOrHttpOrSomethingAsync().then(function(a){fib(a)});

Kamgunz 9y ago

Very interesting, nobody mentioned how formal and quite technical this README is, it goes really into details about what it does, and even future plans laid in three sections across 30 bullet points. One bullet point in the really far future sections said "instrument JavaScript code [in a non observable way]" emphasis mine, that part was noted in several other bullet points. It seems to me every compiler/transpiler/babel-plguin changes JavaScript code in a non observable way, no? Just a theory, but that undertone sounds to me like the ability to change/inject into JavaScript code undetectably on the fly in some super easy way. Just another day at Facebook's office...

CGamesPlay 9y ago
Your tin foil hat can go away when you consider that you're instrumenting code that will permanently run in an observable sandbox. You control the server (for node) and can watch what external requests it's making; and while you don't directly control the client, you do have access (via the web inspector) to all external requests it's making.

arota 9y ago

This is exciting, and has a lot of potential to significantly improve JS library initialization time. I wonder if this is the same project[0] Sebastian McKenzie previewed at React Europe 2016? [0] https://www.youtube.com/watch?v=xbZzahWakGs https://www.youtube.com/watch?v=xbZzahWakGs

hzoo 9y ago
Yep it is! https://twitter.com/dan_abramov/status/859817680857165824 https://twitter.com/dan_abramov/status/859817680857165824
sergioramos 9y ago
It is. Source: https://twitter.com/dan_abramov/status/859817680857165824 https://twitter.com/dan_abramov/status/859817680857165824

iMark 9y ago

The destination page looks uncomfortably like Webpack's. Not the best idea, imho.

untog 9y ago

This should have a big impact on the "cost of small modules", as outlined here: https://nolanlawson.com/2016/08/15/the-cost-of-small-modules/ https://nolanlawson.com/2016/08/15/the-cost-of-small-modules... Which is to say, one of its most effective use cases will be making up for deficiencies in Webpack, Browserify and RequireJS. Which I'm a little ambivalent about - I wish we could have seen improvements to those tools (it's possible, as shown by Rollup and Closure Compiler) rather than adding another stage to filter our JavaScript through. But progress is progess.

deleted 9y ago
[deleted]
k__ 9y ago
I saw a Webpack example and it looked smaller & faster. So it seems like a good thing.

bthornbury 9y ago

Awesome project, the performance gains seem real, but why wouldn't these optimizations be happening at the javascript JIT level in the vm? (serious question) React / javascript programming, is the most complex environment I've ever dug into, and it's only getting more complex. create-react-app is great for hiding that complexity until you need to do something it doesn't support and then it's like gasping for air in a giant sea of javascript compilers.

throwawaymsft 9y ago
download js -> run through JIT compiler -> execute vs. run through JIT compiler -> download js -> execute Whatever overhead the JIT compiler adds will be latency for the user.
- mbel 9y ago
  In the second case it's AOT (ahead of time) not JIT (just in time) compiler.
franciscop 9y ago
Because they'd have to happen every time for every user, so there'd be no real gain there. It has to happen as the code is published in .min.

chime 9y ago

This has promise but still needs more work. I added one line to their 9 line demo ( https://prepack.io/repl.html https://prepack.io/repl.html ) and it ballooned to 1400+ lines of junk: (function() { function fib(x) { y = Date.now(); // the useless line I added return x <= 1 ? x : fib(x - 1) + fib(x - 2); } let x = Date.now(); if (x * 2 > 42) x = fib(10); global.result = x; })(); I understand Date might not be acceptable for inner loops but a lot of my code that deals with scheduling would benefit significantly if I could precompute some of the core values/arrays using a tool like prepack.

shuzchen 9y ago
It's not a useless line, because prepack has no idea what Date.now() does (there are no guarantees in javascript that it hasn't been replaced with another function). It might mutate some global state somewhere, so the resulting code needs to call Date.now() as often as it would've if fib(10) was called. Basically the output is the unrolled version of the recursion, which cuts down on function invocation (comparatively expensive in dynamic languages). If you replaced the line with say: `var y = 4;` you'll notice that it has been optimized out.
- KallDrexx 9y ago
  But should it still unroll the recursive calls and balloon the code out just because a mutatable function call was made, or should it leave it as an actual recursive function call.
- magicalist 9y ago
  > Basically the output is the unrolled version of the recursion, which cuts down on function invocation (comparatively expensive in dynamic languages). You're right about why it's included, but this is a bug, not a feature. If this is a hot function it'll be optimized. The recursive call is a known, non-dynamic invocation so the function location will be inlined leaving just the fairly low function call overhead itself. There's a reason nobody does arbitrary-length loop unrolls. I would definitely bet that this is a bug to be fixed :) Right now you can see this if you call fib(20) in that example...the compiler times out while trying to unroll that far. Clearly that behavior won't stick around.

avodonosov 9y ago

How does one measures performance improvement for a web page gained from such tools?

drumttocs8 9y ago

Coming from a non-CS background, I've always wondered why you can't "convert" code from one framework or paradigm to another. For instance, converting a project from jQuery to React. If you can define the outputs, why can't you redefine the inputs? That's what it seems like this project does... I suppose converting frameworks would be a few orders of magnitudes harder though.

batmansmk 9y ago
Can you turn lead in gold? Maybe using nuclear transmutation. But the potential cost of the process seems higher than the benefits. Can you convert a code base to React from Angular? Maybe, but the effort to write this converter is higher than rewriting the code base.
_pmf_ 9y ago
The problem is not converting; the problem is converting in a way that the result is usable by a human.
joslin01 9y ago
Different design patterns

kasper93 9y ago

I think that just in time compilers are better at doing thier things. Sure it is nice project that can interpret and print preprocessed js, but I think it might in fact not bring speed in most cases. And the current state doesn't even know how to constant fold this loop. function foo() { const bar = 42; for (let i = 0; i <= bar; i++) { if (i === bar) { return bar; } } };

yairhaimo 9y ago
As long as the ahead of time optimizations that dont have a large enough negative drawback in another criteria (speed vs size) are welcomed by me, even if the JIT can do the same optimizations too. Regarding your code example, maybe prepack was changed in the past week and a half, but it is folded quite fine when i tried it: (function() { function foo() { const bar = 42; for (let i = 0; i <= bar; i++) { if (i === bar) { return bar; } } }; console.log(foo()); })();

jlebrech 9y ago

I want something that can separate my code into what can be precompiled into wasm and what has to stay in JS. maybe just insert comments so i can see what needs to be done.

kamranahmed_se 9y ago

> helps make javascript code more efficient https://github.com/facebook/prepack/issues/543 https://github.com/facebook/prepack/issues/543 Are you sure?

k__ 9y ago

Just throw your webpack bundles in and be amazed.

Traubenfuchs 9y ago

I can't get anything to work in it. Just for fun I put the not minifed vue.js source inside and I get: null or undefined TypeError at repl:537:23 at repl:5:16 at repl:2:2

xg15 9y ago

lurker456 9y ago
it's possible to do such optimizations for a (safe) subset of javascript, such as these pure functions. Arguably java has a larger subset even today.
- xg15 9y ago
  I think the remarkable point in the above optimisation was that the non-pure functions define() and require() were also subject of optimisation even though the optimizer had no special knowledge about them. Using symbolic execution, the optimizer nevertheless was able to reason about them.

austincheney 9y ago

Errors on all my code: * http://prettydiff.com/lib/ http://prettydiff.com/lib/ * https://raw.githubusercontent.com/prettydiff/biddle/master/biddle.js https://raw.githubusercontent.com/prettydiff/biddle/master/b...

mstade 9y ago

I'm happy to see there's an option to use this with an AST as input, more tools like this should follow suit. Hopefully it can then push us to a place where there's a standard JS AST such that we don't reinvent that wheel over and over. Babel seems to be winning here, but I don't think it matters so much which one wins so long as any one does. This tool looks interesting, particularly the future direction of it, but I'm weary about efficiency claims without a single runtime metric posted. The claims may be true, initializing is costly, but so is parsing huge unrolled loops. For an optimization tool, I'd hope to see pretty strong metrics to go along with the strong claims, but maybe that is coming? Interesting work, nonetheless!