W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2014

Re: =[xhr]

From: James M. Greene <james.m.greene@gmail.com>
Date: Thu, 4 Sep 2014 07:58:56 -0500
Message-ID: <CALrbKZjacM4MLhaJu_Qbh3AQ9GQUiWzOBDhC6_8kvU7hKcnOqQ@mail.gmail.com>
To: David Rajchenbach-Teller <dteller@mozilla.com>
Cc: public-webapps <public-webapps@w3.org>, Robert Hanson <hansonr@stolaf.edu>, "Greeves, Nick" <ngreeves@liverpool.ac.uk>, olli@pettay.fi
True that ES6 Modules are not quite ready yet but the existing transpilers
for it also convert to asynchronously loading AMD syntax, a la RequireJS.

Still seems a perfect fit for this use case, and Robert may not be aware
that such functionality is forthcoming to solve his issue (and obviously
hopefully is delivered long before sync XHRs become volatile).

    James Greene
    Sent from my [smart?]phone
On Sep 4, 2014 7:42 AM, "David Rajchenbach-Teller" <dteller@mozilla.com>

> On 04/09/14 14:31, James M. Greene wrote:
> >> 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 that is true, wouldn't it better for him to switch over to ES6 Module
> > imports and an appropriate transpiler, for now?
> >
> > I'm a bit confused as to why it doesn't appear this idea was ever
> mentioned.
> >
> I believe it's simply because ES6 Modules are not fully implemented in
> browsers yet. But yes, with the timescale discussed, I agree that ES6
> Modules are certainly the best long-term choice for this specific use case.
> Cheers,
>  David
> --
> David Rajchenbach-Teller, PhD
>  Performance Team, Mozilla
Received on Thursday, 4 September 2014 12:59:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:26 UTC