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
Prepack helps make JavaScript code more efficient
191–200 of 233 posts
Re: Prepack helps make JavaScript code more efficient
#192This 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…
Well, if you have 1400 lines of 100 prime numbers each one, and a last line to retrieve one of them, if i ask for the 140.000 prime, that solution would be better (in terms of speed) than 10 lines making calcs for any prime number.
If you know the possible range of accepted inputs, 1400 loc would be better than 10.
One normally think much more loc is worst than a one line solution, but that's, like most answers, always depends.
And that's a simple case. There are lot of similar cases one dont realize.
Re: Prepack helps make JavaScript code more efficient
#193I 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…
How was the speedup? That's what I would use this for, not some small minification gains.
I'm gonna guess nothing. Static inline isn't going to help a language that needs to get compiled again in browsers. In all likelihood an engine like chrome will do all the optimizations they're doing and more.
It's like optimizing handwriting for readability than typing it out. You're running a transform on the code that changes the format completely, how optimized the original form is doesn't matter.
Re: Prepack helps make JavaScript code more efficient
#194 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;
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.
Re: Prepack helps make JavaScript code more efficient
#195I 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…
> 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.
Again, keep in mind that in your example, the company still has a license to use React. What you're losing is your explicit grant of a license to the patents Facebook MAY have on the technology. But nobody has ever identified such a patent, and one of the core React devs is on record as saying he isn't aware of any either.
Re: Prepack helps make JavaScript code more efficient
#196Earlier quoted context omitted.
Some people think so. Others aren't so sure. US courts have not yet ruled on it. However, even the people who DO think an implicit grant exists would mostly agree that the implicit grant is not sublicensable, which makes it a horrible mess and probably unusable. An explicit grant is strongly preferable, IF people can agree on the terms. Facebook's terms are on the harsh side, but there's clear advantages to it existi…
> US courts have not yet ruled on it. They sort of have. A patent has to be a major and "dominant" part of the implicitly licensed tech for it to be granted. Basically - all existing case law says that you get some rights from implicit grants but it's also far less than explicit ones like FB's
Thanks for the info.
Re: Prepack helps make JavaScript code more efficient
#197function 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 compil…
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.
Re: Prepack helps make JavaScript code more efficient
#198Earlier quoted context omitted.
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.
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 a…
> CC is heading towards being a an optimizing backend for other less painful languages such as Typescript
I actually considered musing about something like this in my post. Typescript support would be very interesting.
Fwiw, the tooling support around the CC has been a problem historically. We relied on Plovr for a long time, but eventually it fell unmaintained, and there wasn't an alternative for a lot of the relevant parts (e.g. gathering source files you care about). Some important dev features also just didn't quite work as intended (sourcemaps) for a long time.
Re: Prepack helps make JavaScript code more efficient
#199Errors on all my code:
* https://raw.githubusercontent.com/prettydiff/biddle/master/b...
Re: Prepack helps make JavaScript code more efficient
#200I'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!