On Thu, May 29, 2014 at 3:09 AM, John Barton johnjbar...@google.com 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
On Thu, May 29, 2014 at 4:40 PM, John Barton johnjbar...@google.com 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.
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
On Wednesday, May 28, 2014 7:27 PM, Ian Hickson i...@hixie.ch 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
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
On Thu, May 29, 2014 at 5:12 PM, Mark S. Miller erig...@google.com 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
On Thu, May 29, 2014 at 7:45 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, May 29, 2014 at 4:40 PM, John Barton johnjbar...@google.com
wrote:
My intuition is that any such plan would be vigorously opposed by the JS
community. Or perhaps vigorously ignored: browsers are falling
On Thu, May 29, 2014 at 8:20 AM, Boris Zbarsky bzbar...@mit.edu 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
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 being the
Parallel experiments would be great.
On Thu, May 29, 2014 at 8:59 AM, Kevin Smith zenpars...@gmail.com 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
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 resource,
On Thursday, May 29, 2014 4:34 PM, Ian Hickson i...@hixie.ch 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,
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 the moment
On Thu, May 29, 2014 at 2:31 PM, Ian Hickson i...@hixie.ch 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
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
On Thursday, May 29, 2014 6:31 PM, Ian Hickson i...@hixie.ch 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
On Thu, 29 May 2014, John Barton wrote:
On Thu, May 29, 2014 at 2:31 PM, Ian Hickson i...@hixie.ch 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 Thu, May 29, 2014 at 4:05 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 29 May 2014, John Barton wrote:
On Thu, May 29, 2014 at 2:31 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 29 May 2014, Juan Ignacio Dopazo wrote:
- some people want to predeclare a bunch of scripts and their
On Wed, May 28, 2014 at 12:29 AM, Kris Kowal kris.ko...@cixar.com wrote:
On Tue, May 27, 2014 at 3:04 PM, Ian Hickson i...@hixie.ch 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
On Tuesday, May 27, 2014 8:51 PM, Ian Hickson i...@hixie.ch 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
On Wed, May 28, 2014 at 3:26 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, John Barton wrote:
On Tue, May 27, 2014 at 4:51 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, John Barton wrote:
Is System something that we are expecting some non-ES spec, e.g.
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
On Wed, May 28, 2014 at 4:20 PM, Ian Hickson i...@hixie.ch 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
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 like
On Fri, May 23, 2014 at 5:04 PM, Ian Hickson i...@hixie.ch 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
On Tue, May 27, 2014 at 8:09 AM, John Barton johnjbar...@google.com wrote:
On Fri, May 23, 2014 at 5:04 PM, Ian Hickson i...@hixie.ch 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
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
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
://esdiscuss.org/topic/integrating-the-webs-dependency-systems#content-5
What would be the best spec to put this in? How should we ensure that all
the specs that are to use this actually do use this? What interfaces
should we have between the specifications to do this?
and how would we hook all
should we do here? Do people agree that the model I described
here is the model that covers everything we need here?:
http://esdiscuss.org/topic/integrating-the-webs-dependency-systems#content-5
What would be the best spec to put this in? How should we ensure that all
the specs that are to use
On Tue, May 27, 2014 at 3:04 PM, Ian Hickson i...@hixie.ch 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
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 script block, or an
HTML video element (the latter in particular would have several URLs,
the
On Tue, May 27, 2014 at 3:04 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 May 2014, John Barton wrote:
On Fri, May 23, 2014 at 5:04 PM, Ian Hickson i...@hixie.ch wrote
...
and how would we hook all the specs together to use it?
Define a System object for ES6 that implements the
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 it
On Tue, May 27, 2014 at 3:57 PM, Ian Hickson i...@hixie.ch 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
On Tue, May 27, 2014 at 4:51 PM, Ian Hickson i...@hixie.ch 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
Right now there appear to be three separate efforts to develop dependency
systems for the Web platform:
- ES6 Modules
- HTML Imports
- script needs= in HTML
At the moment they are mostly not overlapping, but it seems likely that
all will grow over time and that could get messy.
I would
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.
On Fri, 23 May 2014, Ryosuke Niwa wrote:
On May 23, 2014, at 3:14 PM, Ian Hickson i...@hixie.ch wrote:
- script needs= in HTML
Could someone give me a pointer about this? This is the first time I've
heard of this feature.
It's a work in progress, but the last public post from me about
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
On 5/23/14, Ian Hickson i...@hixie.ch wrote:
On Fri, 23 May 2014, Ryosuke Niwa wrote:
On May 23, 2014, at 3:14 PM, Ian Hickson i...@hixie.ch wrote:
Hi guys -
- script needs= in HTML
Could someone give me a pointer about this? This is the first time I've
heard of this feature.
It's a
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,
A script could then tell the system to add this img 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
another
43 matches
Mail list logo
