Here's a proposal for a new kind of object that will give programmers the ability to take a potentially large amount of source code and ask for it to be compiled asynchronously, in order to have more control over compile times. In particular, it allows an interactive application to provide temporary UI while code is being parsed and possibly compiled.
- a new kind of object called a FunctionFuture, which obeys the upcoming DOMFuture spec 
- the arguments to FunctionFuture are the same as the arguments to Function
- the fulfillment of a FunctionFuture is a Function that's constructed in the same way as `new Function` would have been
- the fulfilling of a FunctionFuture is done off the main thread; when the .then method is invoked, the Function must already be created
- a FunctionFuture can be copied to different workers:
* each worker sees a distinct Function object as the fulfilled result
* but internally, the actual work of compiling the Function can be done in one thread; the various threads can share the resulting internal compiled code (e.g. the results of AOT compiling an asm.js function)
- a FunctionFuture can be stored via IndexedDB:
* the arguments and body source are stored
* if the future is fulfilled, we also store any compiled code, along with cache validation information based on the browser version and cpuid
* when reading back the results, if the compiled code is still valid, the future can come back already fulfilled; otherwise it comes back unfulfilled -- whether the future comes back fulfilled is unspecified and left to the implementation
- It's built off of Function rather than (indirect) eval for several reasons:
* either Function or top-level indirect eval are equally powerful, so there's no loss of expressiveness
* but Function ensures there's no runtime execution required to construct it
* so the only errors are compile-time errors, meaning that there's no need to distinguish compile-time from runtime errors
* and sharing across workers means you want to defer execution to be done separately in each worker that touches the function; a Function makes the semantics of this straightforward
* it also makes it clear that the only actual significant work to do is compilation
- The use of futures allows for a single asynchronous interface for:
* the initial compilation of source
* extracting a function from offline storage, which may or may not require recompilation (and should therefore also be asynchronous)
- The use of futures will also make it possible to chain multiple async steps with the convenient semantics of .then
Two potential implementation challenges with this:
1. Implementing the Future semantics before we have a general-purpose implementation for the DOMFuture spec means we'll need to implement most of the .then semantics here. But in time that can be ripped out and replaced with a call to a general-purpose DOMFuture constructor. We can steal the logic from a popular Promises/A+ library like RSVP.js. 
2. Background compilation means it needs to be possible to always compile a Function on a background thread without it being linked directly to a global, so it can be linked to the global once a particular thread (main thread vs worker) calls .then. I don't know if that poses any problems in the current JS engine.
Nice! On first glance, I like these improvements/refinements of the original (misnamed :) idea; nice ergonomics for the presumably-common case but, IIUC, still full power to create and consume FunctionFutures from workers.
One thing I've being missing in Function constructor is ability to create a named functions. It would be great if ` FunctionFuture` allowed creation of named functions not just anonymous ones.
This would fit in nicely with our plans for caching Shumway bytecode parsing and JIT compilation results.
For what it's worth, we would immediately consume this functionality if it were available. :)
I still think this is a pretty good idea :)
A year later, I still think this is a pretty good idea ;)