Live data from Hacker News

Prepack helps make JavaScript code more efficient

prepack.io

151–160 of 233 posts

Re: Prepack helps make JavaScript code more efficient

#151

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

It's a brilliant tool, bravo! Why did you go down that road instead of heap snapshot? Portability?

Conceptually, Prepack would go together well with heap snapshots, as Prepack figures out what is the concrete heap, and what are residual computations. If we tweak Prepack to completely separate these two aspects in the generated code, then you'd heap snapshot after the concrete part has been build, and still run the fixup code at runtime.

Re: Prepack helps make JavaScript code more efficient

#152

Earlier quoted context omitted.

And the weakness, legally speaking, of implicit patent grants was one major reason why GPL moved from v2 to v3. Explicit is much much safer for users of software, legally speaking, because implicit grants have to be settled in court . If you really want to go to court over it, and can afford it, then you may be right. Want to test that against Facebook? They reasoned (quite rightly) that it would be silly to suggest…

What would their case be? "Yes, we gave away the software and documented it and paid designers to design it all pretty and spent marketing effort promoting it but nobody is allowed to use it because it's patented technology"? Has any court ever ruled that a permissive license like BSD does not include a patent grant when it says "use in source and binary forms, with or without modification, are permitted"? Because th…

Patents doesn't mean "nobody is allowed to use it"; patents mean "you are required to license the patent from the patent-holder, which usually requires paying royalties."

I could totally see the point of a FOSS software project that implements a patented algorithm, where people work together to improve the thing but everyone who uses it still has to get a license from the patent-holder. (For a recently-top-of-mind example, Fraunhofer's MP3 decoding patent.)

Thus, it's not obvious that a FOSS license automatically implies patent release. Fraunhofer could have open-sourced some reference MP3 encoder themselves, without releasing the MP3 patents.

Re: Prepack helps make JavaScript code more efficient

#153

Earlier 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.

I don't understand this perspective.

The justice system is like a computer. It has no common sense; it has no "Do What I Mean" button. You have to write things out in full explicitness, for it to do anything predictable/sensible at all.

And just like with explicitness in programming, explicitness in a contract doesn't translate to "more things that could go wrong"; it's instead fewer degrees of freedom. More things pinned down; fewer left to interpretation.

Re: Prepack helps make JavaScript code more efficient

#154
post #132

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

Hi! Judging from the comments only this looks to be a great tool. Good job! I'm a developer currently learning more backend and JS. I hope this question doesn't come out as arrogant. I heard once that "a good compiler should be able to compile itself". Does prepack prepack itself to run faster or can it just for the fun of it? :-)

Not quite. This PR is almost ready to do it.

https://github.com/facebook/prepack/pull/397

Currently it is blocked on Map/Set support in the output which is an outstanding issue. We could also try it with a Map/Set polyfill.

We're very close to being able to though!

In fact, this isn't just Prepack itself but it is Prepacking the JS part of the entire Node.js runtime as well!

Re: Prepack helps make JavaScript code more efficient

#155

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 initiali…

Do you happen to know if this is similar to what Google's Closure Compiler for javascriptw ould do?

It says on the bottom of the page that prepack optimizes for performance/less computation while closure optimizes for file size.

Re: Prepack helps make JavaScript code more efficient

#156
post #153

Earlier quoted context omitted.

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.

I don't understand this perspective. The justice system is like a computer. It has no common sense; it has no "Do What I Mean" button. You have to write things out in full explicitness, for it to do anything predictable/sensible at all. And just like with explicitness in programming, explicitness in a contract doesn't translate to "more things that could go wrong"; it's instead fewer degrees of freedom . More things…

I expect that unexpected results may come from unexpected scenarios, but not in relation to basic questions that appear to already be addressed in the contract, like "can I use this software?" If I can't trust that a statement means what it says, no amount of elaboration can clarify the contract.

Re: Prepack helps make JavaScript code more efficient

#157

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 initiali…

Do you happen to know if this is similar to what Google's Closure Compiler for javascriptw ould do?

Closure Compiler does much of the same things; but I think prepack is looking to do considerably more compile-time evaluation; closure compiler only does some of this.

I think prepack will also generally generate larger, bulkier code than you might get out of closure compiler. When I give prepack code from closure compiler, it seems to make the code much larger but change nothing. Your mileage may vary.

Re: Prepack helps make JavaScript code more efficient

#158

Earlier quoted context omitted.

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.

"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 sh…

> 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?

Re: Prepack helps make JavaScript code more efficient

#159

Earlier 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.)

This sounds like FUD. When has a simple license like BSD been interpreted to not grant rights to the patents implemented in the technology being licensed? The language there is really clear.

I don't know. Turn it around: when has it been interpreted to grant rights to patents implemented? Is there case law that establishes estoppel for such a thing? Has it been tested? Are your lawyers good enough?

These are questions that you should be asking because the name of the game is minimizing risk.

Re: Prepack helps make JavaScript code more efficient

#160
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; } } };

Post reply on HN