On Thu, May 29, 2014 at 4:05 PM, Ian Hickson wrote:
> On Thu, 29 May 2014, John Barton wrote:
> > On Thu, May 29, 2014 at 2:31 PM, Ian Hickson wrote:
> > > On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
> > > > >
> > > > > - some people want to predeclare a bunch of scripts and their
> > > > >
On Thu, 29 May 2014, John Barton wrote:
> On Thu, May 29, 2014 at 2:31 PM, Ian Hickson wrote:
> > On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
> > > >
> > > > - some people want to predeclare a bunch of scripts and their
> > > > dependencies, without actually downloading any of them ahead of
On Thursday, May 29, 2014 6:31 PM, Ian Hickson wrote:
>
>
>On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
>> >
>> > - some people want to predeclare a bunch of scripts and their
>> > dependencies, without actually downloading any of them ahead of time,
>> > and then later, when they're n
Here is a working example of dependency tree caching with an ES6 loader
extension -
https://github.com/systemjs/systemjs/blob/master/lib/extension-depCache.js
This allows dependencies to be declared upfront, and then all deep
dependencies are requested in parallel with the module request (removing
On Thu, May 29, 2014 at 2:31 PM, Ian Hickson wrote:
> On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
> > >
> > > - some people want to predeclare a bunch of scripts and their
> > > dependencies, without actually downloading any of them ahead of time,
> > > and then later, when they're needed
On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
> >
> > - some people want to predeclare a bunch of scripts and their
> > dependencies, without actually downloading any of them ahead of time,
> > and then later, when they're needed, have the entire tree downloaded
> > all at once.
>
> At
On Thursday, May 29, 2014 4:34 PM, Ian Hickson wrote:
The contexts in which I am interested about this kind of thing
is:
- some people want to predeclare a bunch of scripts and their
> dependencies, without actually downloading any of them ahead of time,
> and then later, when they're n
On Wed, 28 May 2014, Matthew Robb wrote:
>
> Perhaps it's too cumbersome to use the System loader to specify the
> business logic for the browsers dependency loading/registry etc. Maybe a
> low-level browser spec needs to exist that a light System object could
> eventually defer to. This almost
All I was saying is that you should always do dates operations through UTC
values which has consistent behavior across engines.
On Thu, May 29, 2014 at 10:00 AM, Garrett Smith
wrote:
> On 5/28/14, Andrea Giammarchi wrote:
>
> Hi Andrea -
>
> > While I agree we should expect consistent results,
On Thu, May 29, 2014 at 9:50 AM, Ian Hickson wrote:
[...]
> This suggests that the plan should be to instead make sure that whatever
> ES6 defines can be used by other specs to define the Web's loading model.
> Is extending the ES6 model (not the API, but the underlying model with
> load records
On 5/28/14, Andrea Giammarchi wrote:
Hi Andrea -
> While I agree we should expect consistent results, you might get more
> consistent one via UTC time, i.e.
>
> ```
> var r = new Date(2013, 02, 10),
> r2 = new Date(2013, 02, 10),
> diff = 7;
> r.setUTCHours(2 + diff);
> r2.setUTCHours(3
On Thu, 29 May 2014, Kevin Smith wrote:
> >
> > Ok. I'm not really sure how to extend the ES6 module system in a way
> > that won't stomp on this working group. How do I (at the spec level)
> > tell the ES6 module system that it should not evaluate a particular
> > module until some non-script r
Parallel experiments would be great.
On Thu, May 29, 2014 at 8:59 AM, Kevin Smith wrote:
>
>>> Assuming the requirements of the different hosting environments are
>>> similar enough that it's possible to factor out some sort of common thing
>>> (presumably with hookable bits for the parts where
>
>
>> Assuming the requirements of the different hosting environments are
>> similar enough that it's possible to factor out some sort of common thing
>> (presumably with hookable bits for the parts where hosting environments
>> want different behavior), of course. If the hookable bits start bein
On Thu, May 29, 2014 at 8:20 AM, Boris Zbarsky wrote:
> On 5/29/14, 11:12 AM, Mark S. Miller wrote:
>
>> But if the issue is of general interest across many hosting environments,
>> then it should
>> probably be handled by JS and TC39, rather than duplicating work among
>> the hosting environment
On Thu, May 29, 2014 at 7:45 AM, Anne van Kesteren wrote:
> On Thu, May 29, 2014 at 4:40 PM, John Barton
> wrote:
> > My intuition is that any such plan would be vigorously opposed by the JS
> > community. Or perhaps vigorously ignored: browsers are falling behind
> > current technology and are
On Thu, May 29, 2014 at 5:12 PM, Mark S. Miller wrote:
> That said, I'm not really sure what this argument is about. Should we grow
> the ES6 module loading mechanism so that it can better handle the loading of
> other resources beside JS code that is relevant to JS? Probably. Do we know
> precise
On 5/29/14, 11:12 AM, Mark S. Miller wrote:
But if the issue is of general interest across many hosting environments, then
it should
probably be handled by JS and TC39, rather than duplicating work among
the hosting environment specs.
Assuming the requirements of the different hosting environm
>
>
>On Wednesday, May 28, 2014 7:27 PM, Ian Hickson wrote:
One thing I don't see in the hooks above is anything to do with actually
>processing dependencies. How would I (at the spec level) tell the ES6
>module system that it should not evaluate a particular module until some
>non-script reso
TC39 includes members (e.g., Paypal, Yahoo) that are heavy users of server
side JS. Samsung expressed strong interest in JS for embedded devices.
Microsoft uses JS as a Windows scripting and application development
language. And in any case, TC39 is committed to growing JS as a language
not specifi
On Thu, May 29, 2014 at 4:40 PM, John Barton wrote:
> My intuition is that any such plan would be vigorously opposed by the JS
> community. Or perhaps vigorously ignored: browsers are falling behind
> current technology and are no longer in a position to dictate what JS means.
I don't even know w
My intuition is that any such plan would be vigorously opposed by the JS
community. Or perhaps vigorously ignored: browsers are falling behind
current technology and are no longer in a position to dictate what JS means.
On Wed, May 28, 2014 at 9:06 PM, Kevin Smith wrote:
>
>> Ok. I'm not really
On Thu, May 29, 2014 at 3:09 AM, John Barton wrote:
> Perhaps my explanation was unclear; I have nothing to say about browser
> implementation.
That's the only part Ian is interested in. He helps authoring the
standards for the various features he mentioned in the initial post.
He wants to reconc
23 matches
Mail list logo
