Has anyone used this with webpack + reactjs ?
Prepack helps make JavaScript code more efficient
41–50 of 233 posts
Re: Prepack helps make JavaScript code more efficient
#42Earlier quoted context omitted.
> Webpack is for dead fish. I haven't used webpack but I have used many similar tools, and I've heard a lot of praise for webpack. Can you elaborate on why you dislike webpack so much?
I'm using "dead fish" in the Bret Victor sense.[0] It's a static tool by nature. By the time you're in a live environment, webpack is gone. [0] https://vimeo.com/64895205
Oh. Isn't prepack also a "dead fish" then? Like you said, "It's a static tool by nature. By the time you're in a live environment, [prepack] is gone." There isn't any sort of prepack runtime
Re: Prepack helps make JavaScript code more efficient
#43This looks very good indeed but the lack of initial data model very severely limits the production usability of this tool. You can't use "document" and "window" ... It's the same problem TypeScript have/had that for external libs you need definition files for it to work. Now if we had TypeScript-to-assumeDataProperty generator that would be VERY interesting!
This is a very early release. I'm sure there'll be a "build for the web" mode soon enough.
Re: Prepack helps make JavaScript code more efficient
#44Hi, I am Nikolai Tillmann, a developer on the Prepack project. I am happy to answer any questions!
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.
It's much better to do this earlier. If you're asking v8 to optimise, say, the whole of React on a mobile device before first paint, that's definitely going to be slower than having the same optimisations done before V8 needs to parse/optimise it!
Re: Prepack helps make JavaScript code more efficient
#45Earlier quoted context omitted.
From the guidelines: > Please resist commenting about being downvoted. It never does any good, and it makes boring reading. https://news.ycombinator.com/newsguidelines.html Disclaimer: I do not work at Facebook.
While I appreciate your vigilantism (given you aren't actually a moderator nor do you work at FB), the real elephant in the room is that HN really needs to a better solution for vote collusion. I am already familiar with the guidelines, and I usually follow this rule to a tee, but the optics here are damning. What I'd really like to see is this discussion steered back on topic. It was originally interesting and produ…
Frankly I only downvoted because of the unfounded accusations of Facebook shilling. There's a certain level of pretentiousness in thinking one's comments could only ever be downvoted because somebody was literally paid to do it. And that attitude rubs me the wrong way.
To bring it back to the discussion itself, I'm also a huge fan of web technologies, so I'm always glad to see further optimizations being made.
I'm hesitant to use it now as it's still so early, but would like to see it mature so it can be included as a step in our gulp/grunt build processes.
Re: Prepack helps make JavaScript code more efficient
#46I 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…
Wow. That is pretty impressive. Although as far as the changes you needed to make are considered, my understanding from a brief skim of the page was that `__assumeDataProperty` would be sufficient for supporting use of `window`.
Re: Prepack helps make JavaScript code more efficient
#47Not 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 part of me thinks it just raises the waterline for more shitty code and awful heavy frameworks that sacrifice the user experience for the developer experience.
"Just run it through the optimizer" so we don't actually have to think about what a good design looks like...
Re: Prepack helps make JavaScript code more efficient
#48Earlier quoted context omitted.
I'm using "dead fish" in the Bret Victor sense.[0] It's a static tool by nature. By the time you're in a live environment, webpack is gone. [0] https://vimeo.com/64895205
Oh. Isn't prepack also a "dead fish" then? Like you said, "It's a static tool by nature. By the time you're in a live environment, [prepack] is gone." There isn't any sort of prepack runtime
I was assuming that the intention was to eventually provide runtime support. If that's correct, then I think we'd be in agreement about what "static" means?
Babel and all sorts of other compilers can run in the browser. Whereas webpack is mainly concerned with the text that you transmit and could not "by nature" be made to do its job in the browser (because then it would be too late). That's the difference I had in mind.
Re: Prepack helps make JavaScript code more efficient
#49This reminds me of Morte, an experimental mid-level functional language created by Gabriel Gonzalez. They both seem to be super-optimizing, that is partially executing the program in question. Of course it is a great deal easier to do in a functional language than JavaScript.
http://www.haskellforall.com/2014/09/morte-intermediate-lang...
Re: Prepack helps make JavaScript code more efficient
#50Not 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…
I disagree with the premise a little bit. A tool like this could allow you to write code which is better suited for a human to read/maintain, but then still get the performance optimizations of pre-computed results being sent over the wire.