Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Prepack helps make JavaScript code more efficient

prepack.io

Post reply on HN
Print view View original

201–210 of 233 posts

Re: Prepack helps make JavaScript code more efficient

#201

Post by tadeuzagallo »

pcwalton wrote: post #86
GeoffreyPlitt wrote: post #21

Earlier quoted context omitted.

Can you prove that any of the optimizations in your docs aren't already done by V8? I agree with the other commenters in this thread-- V8 likely does these already. You have an extraordinary claim, which requires extraordinary proof.

V8, like all tiered JITs, doesn't do many optimizations unless the code to be optimized is hot. This is the right thing for V8 to do, because most code on the Web is cold and so it's better to just run the code rather than sitting there optimizing it. But it does mean that there are a lot of optimizations that would be profitable to perform in the aggregate that are nevertheless unprofitable to do at runtime, because…

That's not all, there's the cost of (down)loading the dead code, and startup cost for loading the unoptimised cost. Even more critical when you consider environments where you can't JIT, like React Native on iOS for instance, which was one of the many motivations for Prepack AFAIK.

Re: Prepack helps make JavaScript code more efficient

#202

Post by maaaats »

slackingoff2017 wrote: post #193
maaaats wrote: post #104

Earlier quoted context omitted.

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.

This sounds like very wrong reasoning. Yes, Chrome probably does some of this stuff, but that comes at a time cost that we could take at compile time, instead of at run time in the user's browser.

Re: Prepack helps make JavaScript code more efficient

#203

Post by maaaats »

devrandomguy wrote: post #135
maaaats wrote: post #103

Earlier quoted context omitted.

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

The licenses that you are thinking of, are all related to copyright, not patents. Patents are a completely different beast. I personally think that patents have no place in contemporary society, but that's just, like, my opinion, man.

No, I explicitly mentioned Apache because it has patent clauses.

Re: Prepack helps make JavaScript code more efficient

#204

Post by kbutler »

abritinthebay wrote: post #147
andreyf wrote: post #111

Earlier quoted context omitted.

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…

You're asking the wrong question. There is almost no case law that supports implicit patent grants and what little there is requires the patents be ones... " that dominate the product or any uses of the product to which the parties might reasonably contemplate the product will be put " -- HP vs O-Type Stencil (1997) So, again, very limited. Very dangerous. Very very open to being sued and crushed economically. This i…

But isn't it the case that any patents that would affect the use of react/prepack would "dominate the product or any uses of the product..."?

Yes, the grant is better than nothing, but also, the risk if the grant is removed seems minimal.

Re: Prepack helps make JavaScript code more efficient

#205

Post by abritinthebay »

kbutler wrote: post #204
abritinthebay wrote: post #147

Earlier quoted context omitted.

You're asking the wrong question. There is almost no case law that supports implicit patent grants and what little there is requires the patents be ones... " that dominate the product or any uses of the product to which the parties might reasonably contemplate the product will be put " -- HP vs O-Type Stencil (1997) So, again, very limited. Very dangerous. Very very open to being sued and crushed economically. This i…

But isn't it the case that any patents that would affect the use of react/prepack would "dominate the product or any uses of the product..."? Yes, the grant is better than nothing, but also, the risk if the grant is removed seems minimal.

Any patents? Not at all.

It's of course possible that they have (or will have) some that would be covered by an implicit grant - though you'd need to go to court to confirm that.

But it's quite possible that they could have many patents that cover non-substancial parts. Guess what? You're now in violation of those if you haven't already licensed them.

So, again, even in the best case the implicit grant still requires you to go to court to maybe get clear of some liability.

Explicit ones have you covered from the start. More rights for you, broader coverage for you.

Re: Prepack helps make JavaScript code more efficient

#206

Post by jaredklewis »

yladiz wrote: post #184
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…

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…

Let me get this straight.

- Facebook says, "hey you can use this software, no copyright strings attached."

- Facebook says, "also, any patents we have to that software, here's a license. One stipulation, if you sue us for patent infringement, we revoke that license."

- Your hypothetical company, let's call it Acme, seeing the value of getting to use great software, for free, with no copyright or patent royalties, takes Facebook up on their charitable offer.

- Acme then, sues Facebook for patent infringement.

- As per the license, Facebook revokes their free patent license they gave to Acme.

And somehow the victim in this story is Acme? That's pretty rich.

Here's an idea: if part of your strategy as a company is using your patents to sue people, maybe don't expect those other companies to give you their patents for free?

Re: Prepack helps make JavaScript code more efficient

#207

Post by joslin01 »

drumttocs8 wrote: post #127

Coming from a non-CS background, I've always wondered why you can't "convert" code from one framework or paradigm to another. For instance, converting a project from jQuery to React. If you can define the outputs, why can't you redefine the inputs? That's what it seems like this project does... I suppose converting frameworks would be a few orders of magnitudes harder though.

Different design patterns

Re: Prepack helps make JavaScript code more efficient

#208

Post by placeybordeaux »

slackingoff2017 wrote: post #193
maaaats wrote: post #104

Earlier quoted context omitted.

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.

Why guess when you could test it?

Re: Prepack helps make JavaScript code more efficient

#209

Post by cblappert »

maaaats wrote: post #202
slackingoff2017 wrote: post #193

Earlier quoted context omitted.

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.

This sounds like very wrong reasoning. Yes, Chrome probably does some of this stuff, but that comes at a time cost that we could take at compile time, instead of at run time in the user's browser.

Someone on twitter seems to have done an experiment about startup time for a trivial app comparing the clojure compiler with and without Prepack:

https://twitter.com/roman01la/status/859849179149021184

Re: Prepack helps make JavaScript code more efficient

#210

Post by xg15 »

lurker456 wrote: post #197
xg15 wrote: post #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; 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.

I think the remarkable point in the above optimisation was that the non-pure functions define() and require() were also subject of optimisation even though the optimizer had no special knowledge about them. Using symbolic execution, the optimizer nevertheless was able to reason about them.
Post reply on HN