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
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 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
>
>
> 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 resource, e.g. a style sheet, is available? It seems
On Wed, May 28, 2014 at 4:20 PM, Ian Hickson wrote:
> On Wed, 28 May 2014, John Barton wrote:
> > >
> > > Is the list that Juan described (see below) the list you had in mind?
> >
> > Yes.
>
> Cool, thanks. (It would be great if this list could be more explicitly in
> the spec, for ease of refere
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 seems easier and more straight forward
(requiring less
On Wed, May 28, 2014 at 3:26 PM, Ian Hickson wrote:
> On Tue, 27 May 2014, John Barton wrote:
> > On Tue, May 27, 2014 at 4:51 PM, Ian Hickson wrote:
> > > On Tue, 27 May 2014, John Barton wrote:
> > > > >
> > > > > Is System something that we are expecting some non-ES spec, e.g.
> > > > > Fetch
On Tue, 27 May 2014, John Barton wrote:
> On Tue, May 27, 2014 at 4:51 PM, Ian Hickson wrote:
> > On Tue, 27 May 2014, John Barton wrote:
> > > >
> > > > Is System something that we are expecting some non-ES spec, e.g.
> > > > Fetch or HTML, to define?
> > >
> > > TC39 members have more than once
>
>
>On Tuesday, May 27, 2014 8:51 PM, Ian Hickson wrote:
>
>
>Is there a description of what the non-ES spec should say? That is, what
>is the interface that System exposes that needs to be "implemented" by
>this non-ES spec? What are the spec hooks that this non-ES spec would need
>to invo
On Wed, May 28, 2014 at 12:29 AM, Kris Kowal wrote:
> On Tue, May 27, 2014 at 3:04 PM, Ian Hickson wrote:
>> On Tue, 27 May 2014, Kris Kowal wrote:
>>> It would be lovely if HTML could be trained to resolve URL's through the
>>> module system.
>>
>> By "HTML" here I presume you mean the underlyin
On Tue, May 27, 2014 at 4:51 PM, Ian Hickson wrote:
> On Tue, 27 May 2014, John Barton wrote:
> > >
> > > Is System something that we are expecting some non-ES spec, e.g. Fetch
> > > or HTML, to define?
> >
> > TC39 members have more than once explained that they expect some non-ES
> > spec to de
On Tue, 27 May 2014, John Barton wrote:
> >
> > Is System something that we are expecting some non-ES spec, e.g. Fetch
> > or HTML, to define?
>
> TC39 members have more than once explained that they expect some non-ES
> spec to define System.
Ah, great. (Sorry if I sound dumb here, I'm very ne
On Tue, May 27, 2014 at 3:57 PM, Ian Hickson wrote:
>
> On Tue, 27 May 2014, John Barton wrote:
> >
> > I think the Loader nicely isolates these particular functions: I don't
> > see any urgency in standardizing them. However the delegation of the
> > specification of System leaves us in the weir
On Tue, 27 May 2014, Matthew Robb wrote:
>
> @Ian, It seems like the first real question is, based on what will
> eventually be in the ES6 Spec for the Loader API, what is the System
> Loader as it pertains to the web/browser environment and is there
> potentially a need for a specification of i
On Tue, May 27, 2014 at 3:04 PM, Ian Hickson wrote:
>
>
> On Tue, 27 May 2014, John Barton wrote:
> > On Fri, May 23, 2014 at 5:04 PM, Ian Hickson wrote
>
...
>
> > > and how would we hook all the specs together to use it?
> >
> > Define a "System" object for ES6 that implements the ES6 Loader A
>
>
> I don't think a URL is the right way to identify everything. Many things
> in the Web platform that you could legitimately want to depend on don't
> have a URL. For example, a promise, or an inline
On Tue, May 27, 2014 at 3:04 PM, Ian Hickson wrote:
> On Tue, 27 May 2014, Kris Kowal wrote:
> > It would be lovely if HTML could be trained to resolve URL's through the
> > module system.
> By "HTML" here I presume you mean the underlying Fetch mechanism. Could
> you elaborate on exactly how this
@Ian, It seems like the first real question is, based on what will
eventually be in the ES6 Spec for the Loader API, what is the System Loader
as it pertains to the web/browser environment and is there potentially a
need for a specification of it here (or at least outside of tc39).
- Matthew Robb
On Fri, 23 May 2014, Garrett Smith wrote:
>
> And can we change "needs=" back to "depends="?
I haven't gotten as far as figuring out what the API should look like, so
it's probably too early to bikeshed specific attribute names. :-)
> > The basic theme of
This is a great observation, often shared. I recall a related conversation
about a year ago, that echoed a proposal from Yehuda a year prior yet (to
which I hope Yeuhuda can exhume a link).
https://twitter.com/kriskowal/status/400703578605486080
And James Burke brought up some ideas on the topic.
The most important problem to iron out with HTML Import + ES6 Loader is the
timing confusion. Both systems use a combination of asynchronous and
blocking-for-dependents loading. The issues could be explored with any of
the existing ES6 pre-standard Loader implementations. (If the developer
uses a
On Tue, May 27, 2014 at 8:09 AM, John Barton wrote:
>
>
>
> On Fri, May 23, 2014 at 5:04 PM, Ian Hickson wrote
>
>>
>> What/where would be the best place to define such a system,
>>
>
> Github.
>
>
>> and how would
>> we hook all the specs together to use it?
>
>
> Define a "System" object for E
On Fri, May 23, 2014 at 5:04 PM, Ian Hickson wrote
>
>
> What/where would be the best place to define such a system,
Github.
> and how would
> we hook all the specs together to use it?
Define a "System" object for ES6 that implements the ES6 Loader API and
extends it to dynamically load CSS
>
>
> A script could then tell the system to add this element /
> HTMLImageElement object as one of the dependencies for a script it was
> injecting, so that that script doesn't run until the image is downloaded.
> (Doing this, assuming the script is then told to run immediately, would be
> anothe
On Fri, 23 May 2014, Matthew Robb wrote:
>
> I think this is a great discussion and it would be cool if it could get
> mirrored to the other working groups (specifically esdiscuss).
Assuming you mean this thread, it is. :-) (If you meant the HTML spec
discussion regarding needs="" and company, t
On 5/23/14, Ian Hickson wrote:
> On Fri, 23 May 2014, Ryosuke Niwa wrote:
>> On May 23, 2014, at 3:14 PM, Ian Hickson wrote:
>> >
Hi guys -
>> > -
I think this is a great discussion and it would be cool if it could get
mirrored to the other working groups (specifically esdiscuss).
It would be great if WebComponents used the Loader and thus you could
easily import a component into an es6 module and you could build a
component that is entirely
On Fri, 23 May 2014, Ryosuke Niwa wrote:
> On May 23, 2014, at 3:14 PM, Ian Hickson wrote:
> >
> > -
> I would therefore like to propose that we integrate these so that we end
> up with just one system that manages all three.
>
> What do people think?
Absolutely. I've been meaning to start a similar discussion on the w3c
lists, but I don't think I have quite the breadth of knowledge required.
T
Right now there appear to be three separate efforts to develop dependency
systems for the Web platform:
- ES6 Modules
- HTML Imports
-
48 matches
Mail list logo
