Prepack helps make JavaScript code more efficient

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.

I never imagined, then (being late 90s) that a brochureware dot com might require liability boxing legally, but I never imagined whole libraries like React being adopted so wholesale, so seemingly blindly (if not blindly, why has nobody posted the outcome of due diligence? A blog topic I'd like the attention from.) and so trivially as, yes, our brochureware site just could get used against us. Our early clients expressed concern, first: we had to pass their IP hygiene checks. We adopted those, right away. Such stringencies are why many entities I've worked with, have no or empty websites, but old old registration dates on their dot coms...

* edit, missing dependant clause I guess was strongly implied, but it's about when we first saw frivolous, vexatious patent suits aiming at the front doors of random web presences condition there might be money and weak legal... I mistakenly imagined that to be spurious, not it would develop into a psedo- legitimate"industry".

A moral thought: Maybe if we sold fewer reinvented wheels, there might be less temptation for parasitic behaviour to organize itself, like patent trolling has done? I can certainly plead the fifth to wheel reinvention, most days I write code ... (edit last) my meaning behind this is that I frequently have found highly objectionable behaviour being justified by the calling out of perceived comparable poor behaviour. Now I don't go sp far to condemn e.g. the js library crowd or any of anything for that matter, it's too young to blame yet. But with the first generation who grew up exposed to computing comparable to modernity, now maturing, its natural the industry will mature also. I see the brake on maturation more as lots of great new tools, than moral or human lacking. But self appointed grown ups trying to bully tax us, might be the natural parasitic compliment to this rich novel ecosystem. We don't need no random adults to appoint to combat this, we just need to question and talk about what is sane to accept. There's too much over reaching paternalism propping up big business assumptions, right now.

You do not lose the right to use Prepack. You lose the right to use whatever patents Facebook may or may not have on the technologies underpinning Prepack, if any.

If you believe Facebook has a lot of strong patents relating to Prepack, the value of the patent grant is high, and the cost of losing it is high. If you do not believe Prepack is encumbered by Facebook patents, then the value of the grant is nil, and the cost of losing it is nil.

> Tangentially related: what would happen if you did sue Facebook for patent infringement, and continued to use this software?

In my view, almost certainly nothing, because I don't think they have any patents on the underlying tech. But if they did, then they'd be added into the ongoing patent fight, and would give Facebook marginally more leverage when negotiating the final settlement.

I rather suspect that the patents Facebook has on other non-Prepack things would be much more decisive.

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.

If you replaced the line with say: `var y = 4;` you'll notice that it has been optimized out.

It makes no sense to use an optimization tool that does the exact opposite in cases it cannot handle. In no world is 1400 lines better than 10.

    (function() {
      for(var i = 0; i < 10000; ++i){
        Date.now();
      }
    })();

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?

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)
   })()

Edit: Looks like this is targeting compiler output, so Flow types would typically be gone by that stage. Integration with Flow could come via a babel plugin that emits `__assumeDataProperty()` when it encounters a convertible Flow type.

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

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.

Prepack reminds me more of a "supercompiler," because it focuses on partial evaluation rather than optimization.

Arguably java has a larger subset even today.

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.

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.

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

No for client javascript. Compilation is a slow and intensive process. You don't have the time to optimize the mountains of code loading on every new page. It makes the page much slower to load. The returns are negative if all the code executed turned out to be a single function to flash a menu, before the user left.

Yes for server javascript. It's long running processes, web servers should take time on startup to perform JIT compilation. It's beneficial in the long run.

vs.

run through JIT compiler -> download js -> execute

Whatever overhead the JIT compiler adds will be latency for the user.

Source: https://twitter.com/dan_abramov/status/859817680857165824

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.

Optimizers are there to help you write maintainable code instead of unmaintainable micro-optimized spaghetti. Use them.

I respectfully disagree :)

I stopped writing excessively terse, 'overly clever', borderline 'minified' code a long time ago when I realised it wasn't worth it - it isn't readable, and it certainly isn't maintainable by my future self, let alone others. Maintainability is generally more important than saving a few cycles. Abstraction does not necessarily === "shitty code" - abstractions help us to build a mental model and reason about what the code is doing.

Having said that, I certainly see where you're coming from - abstraction can be overused, taken to the nth degree such that it's almost impossible to work out how anything actually works, and I do rather loathe such excessively heavy frameworks. But Prepack can help optimise the good frameworks that use just enough abstraction.

On the face of it, Prepack gives us the best of both worlds - developers can write maintainable code, and Prepack can optimise it a bit for us. Others here have menioned it too, but I see it as akin to the same sort of optimisations that compilers generally do.

I'm not sure what you mean by "fancy code." I feel like it's the opposite. We often try to write code that is readable and maintainable, and has as few as possible "fancy" magical constants littered throughout it, but I'm happy if a compiler wants to optimize it.

If I have to specify some variable, e.g. `frameRate = 60` and then I have a whole bunch of other variables throughout the code that depend on it, then I'm going to reference framerate everywhere: `framePeriod = 1/frameRate; frameBufferSize = frameRate * 100` or whatever. This way if we change our specs, I have a single number to change, instead of dozens of numbers that all depends on each other.

Similarly, if I'm calculating the volume of a sphere, you bet I'm going to put `v = 4/3 * Math.PI * Math.pow(r, 3)`, because it's a meaningful statement that everyone will understand, without trying to get "fancy" by optimizing it.

But should a compiler optimize it? Heck yeah.

  (function() {
    function foo() { const bar = 42; for (let i = 0; i <= bar; i++) { if (i  === bar) { return bar; } } };
    console.log(foo());
  })();