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

71–80 of 233 posts

Re: Prepack helps make JavaScript code more efficient

#71

Post by pcwalton »

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…

Every time someone says "optimizers are harmful, just write fast code to begin with" I ask if they've written "x / 3".

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

Re: Prepack helps make JavaScript code more efficient

#72

Post by MaxLeiter »

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…

Seems to not support some implementations of require() - did you have any problems?

Re: Prepack helps make JavaScript code more efficient

#73

Post by wereHamster »

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 .

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

Re: Prepack helps make JavaScript code more efficient

#75

Post by newman314 »

NTillmann wrote: post #18
tyingq wrote: post #14

How "safe" is it? I'm thinking, for example, of Google's closure compiler and the advanced optimizations, which can break some things. Or roughly, if it compiles without errors, is it safe to assume it won't introduce new bugs?

It's not yet ready for production, so there are some bugs and cases where we should reject a program but don't do that yet. 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.

Has this been tried on popular JS packages such as jquery?

Re: Prepack helps make JavaScript code more efficient

#76

Post by sjrd »

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 .

Is that right? The Scala.js compiler emits none of that "run-time metaprogramming" boilerplate that Prepack is good at optimizing away.

In general, I would expect from a compiler to JS not to emit performance killers like that. Any decent compiler to JS should be able to remove its own crap on its own ;)

Re: Prepack helps make JavaScript code more efficient

#78

Post by jorblumesea »

NTillmann wrote: post #5

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

Thoughts on supporting source maps or something like it? It's very common to use source maps on production code when debugging live site issues and it's nice to have that translation capacity.

Re: Prepack helps make JavaScript code more efficient

#79

Post by yladiz »

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 the likelihood of this occurring is small, I can imagine a company holding some valid patents, such as something related to VR, that aren't related to Prepack that Facebook infringes upon, as well as using a software that Facebook produces like Prepack, sue Facebook for infringement, and then losing the right to use Prepack as a result. From my understanding these kinds of clauses are beneficial overall, but the specific one that Facebook uses is too broad.

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

Post reply on HN