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

91–100 of 233 posts

Re: Prepack helps make JavaScript code more efficient

#91

Post by Kamgunz »

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/babel-plguin changes JavaScript code in a non observable way, no? Just a theory, but that undertone sounds to me like the ability to change/inject into JavaScript code undetectably on the fly in some super easy way.

Just another day at Facebook's office...

Re: Prepack helps make JavaScript code more efficient

#93

Post by abritinthebay »

wereHamster wrote: post #73
gavinpc wrote: post #53

Earlier quoted context omitted.

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 .

Why improve the compilers when we can have yet another tool to layer on top of our ever growing tool stack.

I take it you've never looked at a modern C++ or similar build and execution chain under the hood then?

There's a LOT of parts that do different things. They may be aliased under one command (with tons of flags) but a modern system does a lot of stuff.

For modern JS we appear to have:

- Linters (ESLint, etc)

- Transcompilation to Object Code (Babel, etc, transpile to JS)

- AoT Compilation (this & Closure Compiler, etc, do optimizations on the code ahead of running it)

- Recompilation (AST based compression - like Uglify)

- Compiling (the actual JS VM, V8, etc)

- JIT (in the actual browser)

None of these steps are alien to other build chains.

Re: Prepack helps make JavaScript code more efficient

#94

Post by hzoo »

arota wrote: post #92

This is exciting, and has a lot of potential to significantly improve JS library initialization time. I wonder if this is the same project[0] Sebastian McKenzie previewed at React Europe 2016? [0] https://www.youtube.com/watch?v=xbZzahWakGs

Yep it is! https://twitter.com/dan_abramov/status/859817680857165824

Re: Prepack helps make JavaScript code more efficient

#95

Post by abritinthebay »

yladiz wrote: post #89
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.

Yes, I know; I mentioned that my understanding is that they're more beneficial. The beneficial aspects of the clause don't forgive the broadness of it, however.

It's broad necessarily otherwise it wouldn't cover/protect authors broadly.

Re: Prepack helps make JavaScript code more efficient

#96

Post by andreyf »

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.

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

Re: Prepack helps make JavaScript code more efficient

#97

Post by sergioramos »

arota wrote: post #92

This is exciting, and has a lot of potential to significantly improve JS library initialization time. I wonder if this is the same project[0] Sebastian McKenzie previewed at React Europe 2016? [0] https://www.youtube.com/watch?v=xbZzahWakGs

It is.

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

Re: Prepack helps make JavaScript code more efficient

#99

Post by eridius »

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.

AIUI this issue still hasn't been settled to everybody's satisfaction.

Re: Prepack helps make JavaScript code more efficient

#100

Post by ezekg »

newtonapple wrote: post #60
NTillmann wrote: post #5

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

What will happen if you have bug in your function? Take the fibonacci function for example, what if you have a bug and created an infinite loop? Will Prepack terminate?

I was thinking something similar: how does Prepack determine that a function can't be optimized or hits an infinite loop? Seems like the good ol Halting Problem[0].

[0]: https://en.wikipedia.org/wiki/Halting_problem

Post reply on HN