Prepack helps make JavaScript code more efficient • Hacker News Board

Re: Prepack helps make JavaScript code more efficient

#101

Post by abritinthebay » Wed, May 03, 2017, 8:29 PM UTC

andreyf wrote: post #96

abritinthebay wrote: post #87

Earlier quoted context omitted.

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.

False: an implicit patent grant means that by open sourcing a piece of software you imply that people can, you know, use it.

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

Re: Prepack helps make JavaScript code more efficient

#102

Post by dgreensp » Wed, May 03, 2017, 8:33 PM UTC

ianbicking wrote: post #33

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

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.

Re: Prepack helps make JavaScript code more efficient

#103

Post by maaaats » Wed, May 03, 2017, 8:43 PM UTC

abritinthebay wrote: post #87

yladiz wrote: post #79

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…

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.

They could use some proper, standard license, though. Then people wouldn't complain. Like Apache license.

Re: Prepack helps make JavaScript code more efficient

#104

Post by maaaats » Wed, May 03, 2017, 8:44 PM UTC

chmod775 wrote: post #37

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…

How was the speedup? That's what I would use this for, not some small minification gains.

Re: Prepack helps make JavaScript code more efficient

#105

Post by untog » Wed, May 03, 2017, 8:45 PM UTC

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

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.

Re: Prepack helps make JavaScript code more efficient

#106

Post by CGamesPlay » Wed, May 03, 2017, 8:51 PM UTC

Kamgunz wrote: post #91

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/b…

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.

Re: Prepack helps make JavaScript code more efficient

#107

Post by adamsea » Wed, May 03, 2017, 8:57 PM UTC

chmod775 wrote: post #37

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?

Re: Prepack helps make JavaScript code more efficient

#108

Post by bthornbury » Wed, May 03, 2017, 9:04 PM UTC

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.

Re: Prepack helps make JavaScript code more efficient

#109

Post by hokkos » Wed, May 03, 2017, 9:13 PM UTC

msoad wrote: post #66

NTillmann wrote: post #5

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

This is fucking impressive! Just evaluated this: (function() { var a = 'a'; var b = [a, 'b', 'c'] .filter((i, index) => i.charAt( 1 - index) !== 'b') .map(i => i + '!') .join(',') console.log(b) })() BTW how you avoid going to infinite loops?

That is not surprising, your filter/map/join only use constants, it probably does an eval().

Re: Prepack helps make JavaScript code more efficient

#110

Post by SamBam » Wed, May 03, 2017, 9:14 PM UTC

djsumdog wrote: post #55

jamescostian wrote: post #9

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

The examples seem more typical of Coffeescript output.

You've mentioned that a couple times, but I'm really not seeing it. What to you looks like coffeescript there?