Re:Asm.js: a strict subset of js for compilers – working draft
by cromwellian on Friday February 15, 2013 @02:40PM
(#5228045)
Java went through a similar issue with their pack200 format. I am not privy to where all the time is spend in mobile JS startup (parsing, etc). It seems like using some kind of special JS precompressor would both benefit entropy coding as well as allow a faster parser, but I've seen it turn out to be a wash in the past. :( However, even if you could reduce network bandwidth, it would be a win for people's data plans and batteries. :)
Re:Asm.js: a strict subset of js for compilers – working draft
by BrendanEich on Friday February 15, 2013 @04:09PM
(#5228695)
Obviously video and similar compression is a counterexample, but I usually lose when betting against gzip.
/be
I'll let dherman elaborate in more detail, but he is working on it. :)
"The spec seems to argue that Browser VMs could recognize asm.js and if I read between the lines, employ snapshoting the app and caching it for later quick startup?"
This is really a problem with any portable code delivery format that wants to run compiled code. You either have to stick to native code, in which case you aren't portable, or you have to compile on the client, which adds startup time. Caching of compiled artifacts is going to be necessary in any portable solution, and I don't see any reason off the top of my head why this would be particularly different for asm.js.
"Seems like it might be worthwhile for Mozilla to also work on efficient representations of asm.js that minimize this overhead. The usual response is minify + gzip, but it's not a panacea."
I agree, and I've talked to Alon about this. I think that it would be an interesting project to develop a format that compresses asm.js down as small as possible. Then you can simply uncompress and eval on the client side to ensure backwards compatibility.