Live data from Hacker News

Prepack helps make JavaScript code more efficient

prepack.io

131–140 of 233 posts

Re: Prepack helps make JavaScript code more efficient

#131

Looks like it's applying the same sort of optimizations a normal optimizing compiler would. With all of these JS "compilers" and transpilers, at some point, it just makes sense to build a client-side language in the browser that compiles down to native and runs sandboxed. I'm excited for WebAssembly, but I realize that, like with all shiny new web things (for example, WebRTC on Safari/iOS), mainstream browsers that m…

How much marketshare do you think that Javascript will lose once WebAssembly gets mainstream? Has it evolved so much that it's now a language you would pick out of free will? With ES6, I'm hearing that it's actually usable and kinda nice, but every time I use JS for something instead of Python, I get hit with things like the weird typing that you just can't change.

"How much marketshare do you think that Javascript will lose once WebAssembly gets mainstream?"

I'm no fortuneteller, but I suspect that people writing the most demanding client applications for web will be very happy when it does.

Browser-desktop convergence wasn't meant to happen through JS, and after the proliferation of the hacks that we have today to get around inherent design flaws in the language, it really shows.

"Has it evolved so much that it's now a language you would pick out of free will?"

"Free will" is a very good way of putting it. I suspect some Node developers were ex-frontend devs that just didn't want to learn another language. Moreover, the realities of project management, human resource allocation, and fast iteration are the forcing function behind using Electron instead of building a real desktop app.

Re: Prepack helps make JavaScript code more efficient

#132

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

Hi! Judging from the comments only this looks to be a great tool. Good job!

I'm a developer currently learning more backend and JS. I hope this question doesn't come out as arrogant. I heard once that "a good compiler should be able to compile itself". Does prepack prepack itself to run faster or can it just for the fun of it? :-)

Re: Prepack helps make JavaScript code more efficient

#133

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.

Webpack handles sourcemaps, and one of us, gajus, has already integrated it. Prepack should be just another stage in the build pipeline.

Having said that, there appears to be a sourceMaps flag in the Prepack source: https://github.com/facebook/prepack/blob/57cc59c07d164e4827c...

I will be attempting to use this as a simple black box, relying on Webpack for features that are only tangentially related to this new optimization stage in my build stack.

Re: Prepack helps make JavaScript code more efficient

#134

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

If I can't trust the justice system to interpret a simple contract plainly, then I don't have a chance of actually understanding the legal implications of a more complex contract.

Re: Prepack helps make JavaScript code more efficient

#135

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.

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.

Re: Prepack helps make JavaScript code more efficient

#136

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?

GCC doesn't crash if you tell it to unroll loops with an infinite while loop in your code, does it?

Re: Prepack helps make JavaScript code more efficient

#137
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…

But should it still unroll the recursive calls and balloon the code out just because a mutatable function call was made, or should it leave it as an actual recursive function call.

Re: Prepack helps make JavaScript code more efficient

#138
post #105

This should have a big impact on the "cost of small modules", as outlined here: https://nolanlawson.com/2016/08/15/the-cost-of-small-modules... Which is to say, one of its most effective use cases will be making up for deficiencies in Webpack, Browserify and RequireJS. Which I'm a little ambivalent about - I wish we could have seen improvements to those tools (it's possible, as shown by Rollup and Closure Compiler) r…

[deleted]

Re: Prepack helps make JavaScript code more efficient

#139

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.

The Apache license has had patent clauses for more than a decade.

http://en.swpat.org/wiki/Patent_clauses_in_software_licences...

Re: Prepack helps make JavaScript code more efficient

#140
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…

> sue Facebook for infringement, and then losing the right to use Prepack as a result.

You do not lose the right to use Prepack. You lose the right to use whatever patents Facebook may or may not have on the technologies underpinning Prepack, if any.

If you believe Facebook has a lot of strong patents relating to Prepack, the value of the patent grant is high, and the cost of losing it is high. If you do not believe Prepack is encumbered by Facebook patents, then the value of the grant is nil, and the cost of losing it is nil.

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

In my view, almost certainly nothing, because I don't think they have any patents on the underlying tech. But if they did, then they'd be added into the ongoing patent fight, and would give Facebook marginally more leverage when negotiating the final settlement.

I rather suspect that the patents Facebook has on other non-Prepack things would be much more decisive.

Post reply on HN