Hi, I am Nikolai Tillmann, a developer on the Prepack project. I am happy to answer any questions!
Do you have any performance benchmarks?
Prepack helps make JavaScript code more efficient
181–190 of 233 posts
Re: Prepack helps make JavaScript code more efficient
#182I 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…
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.
No, that question is unsettled.
If you know better, you might want to give an answer here:
https://law.stackexchange.com/questions/14337/q-about-conseq...
Re: Prepack helps make JavaScript code more efficient
#183> helps make javascript code more efficient
https://github.com/facebook/prepack/issues/543
Are you sure?
Re: Prepack helps make JavaScript code more efficient
#184I 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…
I can't edit my post since it's been too long, but I do want to clarify that when I say valid patent, I mean a patent that has been granted by the patent office and isn't held by a non practicing entity.
I could easily see a company 1) using something Facebook has created, like React, for a VR based UI; 2) patenting something related to their VR technology; 3) Oculus making the same kind of technology and not paying the company royalties/licensing its usage; and, 4) suing Oculus for patent infringement.
Of course it is within Facebook's right to make the patent clause as broad as it is, but I don't feel like it is fair that the company above would not be able to use React because Facebook infringed on a patent unrelated to React. It would be a lot nicer if Facebook either used an already existing license like Apache 2, or updated the patent clause to be more specific.
Re: Prepack helps make JavaScript code more efficient
#185Just throw your webpack bundles in and be amazed.
Re: Prepack helps make JavaScript code more efficient
#186This 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... 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) r…
I saw a Webpack example and it looked smaller & faster. So it seems like a good thing.
Re: Prepack helps make JavaScript code more efficient
#187Awesome 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…
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.
In the second case it's AOT (ahead of time) not JIT (just in time) compiler.
Re: Prepack helps make JavaScript code more efficient
#188Earlier quoted context omitted.
That "pile of explicitness" replaces a pile of implicitness wrapped up in case law and statutes that are relevant to any case that arises but you don't know about . Because what you read in a license is not what matters--how do you know you understand them as they will be interpreted by a court of law? What do you not know that you do not know? (This is why companies have legal teams.)
If I can't trust the justice system to interpret a simple contract plainly, then I don't have a chance of actually understanding the legal implications of a more complex contract.
You're assuming that because a contract is simple you're more likely to understand it correctly. That is horribly misguided.
In all likelihood you don't fully understand contracts regardless of length because you're unaware of the entire legal environment they exist in. The reason contracts often have weird stilted phrases is that they have specific meanings established over decades if not centuries of legal battles over those semantics.
A good example for doing this right are the Creative Commons licenses: they come with a summary in plain English for humans and a full license text for the legal system.
Re: Prepack helps make JavaScript code more efficient
#189This has promise but still needs more work. I added one line to their 9 line demo ( 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 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…
Doesn't this make Prepack completely unusable? Surely it should try to apply its optimizations to each block of code, and for each block where the "optimized" version results in more lines of code - or perhaps better, more operations - the optimizations are thrown out, keeping that block of code untouched? It makes no sense to use an optimization tool that does the exact opposite in cases it cannot handle. In no worl…
"Prepack is still in an early development stage and not ready for production use just yet. Please try it out, give feedback, and help fix bugs."
Re: Prepack helps make JavaScript code more efficient
#190This has promise but still needs more work. I added one line to their 9 line demo ( 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 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…
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 (comparativel…
Also the lack of variable declaration in `y = Date.now()` made y an implicit global, so it couldn't be optimised out no matter what. Even doing `let y = Date.now()` cuts out 400 lines.