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

141–150 of 233 posts

Re: Prepack helps make JavaScript code more efficient

#141

Post by bpicolo »

matt4077 wrote: post #88
frik wrote: post #52

How does it compare to Google's closure compiler? It is considered by many best in class. It understands the code (uses Java based Rhino Javascript engine), while most alternatives (UglifyJS & co) just monkey patch things. You can trust the Google's closure compiler output. Edit: @jagthebeetle: have you tried "advanced mode"? (One should read the documentation before using it, it's really a game changer but requires…

Closure compiler optimizes code size, while this optimises code execution.

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.

Re: Prepack helps make JavaScript code more efficient

#142

Post by vmasto »

franciscop wrote: post #124
evv wrote: post #112

Earlier quoted context omitted.

Keep in mind that everything is gzipped nowadays, so it may not make a big difference in network usage. Although it is still likely to cause some memory overhead

No, I have done and pubpished an article about how gzip works with JS and the result will compress pretty well. Not better than the code, but I would guess within the same order of magnitude.

JavaScript parsing is still a huge bottleneck. 1mb of it will still take 1 whole second to parse in V8 (note: just to parse it, not actually evaluate or run it!).

Re: Prepack helps make JavaScript code more efficient

#143

Post by Lazare »

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.

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

Re: Prepack helps make JavaScript code more efficient

#144

Post by phpnode »

phpnode wrote: post #69
NTillmann wrote: post #5

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

Awesome work! Are there plans to incorporate Flow definitions as an alternative to the __assumeDataProperty helpers? 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.

(can't edit my post any more)

I made a plugin to do this here - https://github.com/codemix/flow-runtime/tree/master/packages...

Re: Prepack helps make JavaScript code more efficient

#145

Post by kevindqc »

gavinpc wrote: post #53
iamleppert wrote: post #47

Not a comment about the tool, which looks cool and well done. It's sad that there are developers and projects who write the type of code that causes these sorts of performance trade offs. I stopped writing this kind of fancy code a long time ago when I realized it wasn't worth it. You're just shooting yourself in the foot in the long run. I think static analysis performance optimization tools are great but a certain…

There is some confusion in this thread about the purpose of this tool, which is targeted at generated code—specifically, code generated by other compilers. In order to get language features that don't exist in javascript, code has to be generated in a more or less context-agnostic way. This (as I understand it) brings more context to bear, to reduce the cost of the new abstractions for your specific usage .

Maybe someone can try it on a large AOT compiled Angular2 project?

Re: Prepack helps make JavaScript code more efficient

#146

Post by andreyf »

eropple wrote: post #128
slavik81 wrote: post #119

Earlier quoted context omitted.

I can read and understand the MIT or BSD licenses. That is an extremely valuable property of a contract to me. Both clearly state that I may modify and distribute the software. Adding a huge pile of details about what exactly that means makes me rather nervous. I am not a lawyer, and I worry that somewhere in that huge pile of explicitness that there are consequences that I don't anticipate, and that don't match up w…

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.

Re: Prepack helps make JavaScript code more efficient

#147

Post by abritinthebay »

andreyf wrote: post #111
abritinthebay wrote: post #101

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…

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 is exactly why FB's patent grant provides you more rights that you get without it. There is no ambiguity, no fussing over what patents may or may not apply and be covered by the case law. It's explicit and better for you.

Long story short: in many ways it's less safe to rely on implicit grants.

Re: Prepack helps make JavaScript code more efficient

#148

Post by abritinthebay »

Lazare wrote: post #143
andreyf wrote: post #96

Earlier quoted context omitted.

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

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

Re: Prepack helps make JavaScript code more efficient

#149

Post by abritinthebay »

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.

> I personally think that patents have no place in contemporary society

Amend that to Software Patents and... I'm basically with you. Generally I think they are useful as a concept but I think they've become a bloated mess.

Re: Prepack helps make JavaScript code more efficient

#150

Post by magicalist »

shuzchen wrote: post #123
chime wrote: post #114

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

It's not a useless line, because prepack has no idea what Date.now() does (there are no guarantees in javascript that it hasn't been replaced with another function). It might mutate some global state somewhere, so the resulting code needs to call Date.now() as often as it would've if fib(10) was called. Basically the output is the unrolled version of the recursion, which cuts down on function invocation (comparativel…

> Basically the output is the unrolled version of the recursion, which cuts down on function invocation (comparatively expensive in dynamic languages).

You're right about why it's included, but this is a bug, not a feature. If this is a hot function it'll be optimized. The recursive call is a known, non-dynamic invocation so the function location will be inlined leaving just the fairly low function call overhead itself. There's a reason nobody does arbitrary-length loop unrolls.

I would definitely bet that this is a bug to be fixed :) Right now you can see this if you call fib(20) in that example...the compiler times out while trying to unroll that far. Clearly that behavior won't stick around.

Post reply on HN