Re: =[xhr]

On Wed, Sep 3, 2014 at 8:34 AM, Brendan Eich <brendan@secure.meer.net> wrote:
> David Rajchenbach-Teller wrote:
>> Clearly, it would require big changes, although compiling to return
>> Promise and using Task.js + yield at call sites would probably be much
>> simpler than CPS conversion.
>
> All call sites, every last Java method => JS function call? That means every
> single function becomes a generate, all functions use yield and so become
> generator functions, all calls construct a generator which must have .next()
> called to get it started. The performance is not going to be tolerable.

Actually, nothing so complicated.  The sole reason for these sync
XHRs, if you recall the OP, is to pull in libraries that are only
referenced deep in a call stack, so as to avoid having to include
*all* the libraries in the initial download.  If you can change the
Java=>JS compilation, you can very easily just *track* all the
libraries that might be used, and use that information to include the
correct code in the initial download.

This does mean that if you have conditional code that includes one
library or another based on something that's likely to be static over
a page's lifetime, this approach will include both libraries while the
XHR one will only include the one that's used.  Given what I expect to
be massive performance benefits from avoiding a ton of sync XHRs, I
think the perf loss of a slightly larger download is worthwhile.

The current Java=>JS compiler is simply emulating Java's inclusion
mechanism too directly; as I think you've mentioned before, Brendan,
the costs of a networked file system are far different than a local
one, and require different solutions to be effective.  Including a new
library is milliseconds in Java; doing the same over a sync XHR in JS
can be anywhere from a tenth of a second to several seconds, depending
on network latency, during which your page/app is completely frozen.
It's just a broken design.

~TJ

Received on Wednesday, 3 September 2014 16:03:42 UTC