On Tue, Aug 18, 2015 at 11:36 AM, Dave Herman dher...@mozilla.com wrote:
https://github.com/whatwg/loader/blob/master/roadmap.md
From a loader/tool perspective, it seems like working out more of the
Stage 1 items before many of the Stage 0 items will lead to higher
leverage payoffs: the dynamic
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of James
Burke
In the spirit of the extensible web, defining these lower level APIs and more
of the loader would make it possible to use custom elements to help
prototype a module tag. The custom element mechanism can be used
and this is why XHTML...
On Friday, August 21, 2015, Domenic Denicola d...@domenic.me wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org javascript:;]
On Behalf Of James Burke
In the spirit of the extensible web, defining these lower level APIs and
more
of the loader would
On Fri, Aug 21, 2015 at 8:12 AM, Domenic Denicola d...@domenic.me wrote:
No, custom elements cannot prototype the module tag, because custom elements
will always be parsed as unknown elements. So e.g.
Ah, thanks for pointing that out. I was thinking more of the script
src style of tag. The
the Node algorithm or any other module loading
algorithm in ECMA-262. That responsibility belongs to the Loader
standard.
agreed
* Change the signature of HostResolveImportedModule to match
`System.import()`, which takes a this-value and two strings (name and
referrer).
HostResovleImportedModule
- this is
the special contextual loading syntax to effectively provide a scoped
System.import call whose referrer is locked to the current module (`import
module from this` as Dave has put in the roadmap, but I'm not sure what the
exact syntax proposal is).
This is the equivalent of the dynamic require
We have discussed the issue somewhat at length with the WHATWG loader spec
with calls. We agree that having diverging async/sync properties is
problematic if a feature is present in both Node and the browser.
* the consensus is `System.import` returns a `Promise`, which means the
execution
in dynamic loading here.
The contextual loader may be worth considering as a focus here - this is the
special contextual loading syntax to effectively provide a scoped
System.import call whose referrer is locked to the current module (`import
module from this` as Dave has put in the roadmap
On Tue, Aug 18, 2015 at 1:36 PM, Dave Herman dher...@mozilla.com wrote:
The `System.loader.import` feature isn't ready for stabilization yet, and is
blocked on a few other pieces of the Loader design.
Well, if it isn't ready, it isn't ready. But can you tell a little bit
more? What sort of
It's great to see more interest in dynamic loading here.
The contextual loader may be worth considering as a focus here - this is
the special contextual loading syntax to effectively provide a scoped
System.import call whose referrer is locked to the current module (`import
module from
There are ways for syncing promises for Node compatibility, although they
all lie in C++ land. Similar has already been done with Node callbacks.
https://www.npmjs.com/package/sync
(You could also spawn a thread, block for a message, and join it with the
promise result from a C++ callback from a
.
There's a planned feature that addresses all these use cases:
`System.import(moduleSpec, referrer)`.
It's possible to make minor changes to HostResolveImportedModule and
then specify `System.import` in terms of that. It could ship in the
existing compilation-plus-polyfill module system
From: Jason Orendorff [mailto:jason.orendo...@gmail.com]
HostResolveImportedModule is widely implemented by compilers, though
not by browsers. People are writing, using, and sharing ES6 modules today.
So what is your proposal then? Just standardize the node module resolution
algorithm, since
as
System.import but perhaps with no async wrappers?
- Matthew Robb
On Tue, Aug 18, 2015 at 1:11 PM, Domenic Denicola d...@domenic.me wrote:
From: Jason Orendorff [mailto:jason.orendo...@gmail.com]
HostResolveImportedModule is widely implemented by compilers, though
not by browsers. People
On Mon, Aug 17, 2015 at 5:02 PM, Domenic Denicola d...@domenic.me wrote:
It's possible to make minor changes to HostResolveImportedModule and
then specify `System.import` in terms of that. [...]
I don't understand. If it's in terms of HostResolveImportedModule, and
HostResolveImportedModule
code
bases.
I'm aware of the considerations. I helped Dave Herman hash out the
Loader design.
The opportunity here is that we can specify System.import() now
*without* having to solve all those considerations overnight.
There is nothing stopping us. We have the primitive. We have standard
syntax
From: Jason Orendorff [mailto:jason.orendo...@gmail.com]
Here's what I had in mind:
I have re-read this a few times and still don't understand how you expect this
to be implemented in a standards-compliant way given that
HostResolveImportedModule is not standardized. It doesn't seem to
The problem is timing; WHATWG uses promises, which Node cannot use due to
existing code bases on npm + potential mixing w/ `require`. This causes
time discrepancies and would mean different actions depending on how
exactly hooks are specced out. Node does not want to prevent async loading
on the
On Tue, Aug 18, 2015 at 12:45 PM, Bradley Meck bradley.m...@gmail.com wrote:
This would assume they can support the transformation hooks to do things
like load coffeescript etc. right now, which is the main contention point.
It is a perfectly ordinary occurrence in software to ship some
, for faster initial load times).
- There is no standard way to conditionally load modules.
- There is no standard way to catch errors when module loading fails.
There's a planned feature that addresses all these use cases:
`System.import(moduleSpec, referrer)`.
It's possible to make minor changes
.
- There is no standard way to catch errors when module loading fails.
There's a planned feature that addresses all these use cases:
`System.import(moduleSpec, referrer)`.
It's possible to make minor changes to HostResolveImportedModule and
then specify `System.import` in terms of that. It could
all these use cases:
`System.import(moduleSpec, referrer)`.
It's possible to make minor changes to HostResolveImportedModule and
then specify `System.import` in terms of that. It could ship in the
existing compilation-plus-polyfill module system implementations (like
webpack) immediately
I think we all want to find a good solution to creating a Loader for ES6
modules. I would follow WHATWG's Loader if you want to participate. There
are a surprising number of considerations, particularly due to existing
code bases.
Node and WHATWG's Loader hook will be different, but are the only
Can someone point me to the spec for `System.import`?
https://github.com/jorendorff/js-loaders/blob/master/browser-loader.js
doesn't seem to include it.
It seems to me that it would be worthwhile to ensure that
`System.import` had good semantics. It would allow a nice migration
path
On 14 February 2014 14:13, C. Scott Ananian ecmascr...@cscott.net wrote:
Can someone point me to the spec for `System.import`?
It's in the ES6 specification draft under Loader.prototype.import -
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-loader.prototype.import
.
https
Thanks. I was missing the relationship between System and Loader somehow.
So System.import is intended to be exactly the same as the import keyword
(except promise-returning). That's good! Is there a way to do without the
export keyword as well (I've heard rumors of anonymous exports but
haven't
On Fri Feb 14 2014 at 2:20:07 PM, C. Scott Ananian ecmascr...@cscott.net
wrote:
Thanks. I was missing the relationship between System and Loader somehow.
So System.import is intended to be exactly the same as the import keyword
(except promise-returning).
There is a big difference here
somehow.
So System.import is intended to be exactly the same as the import keyword
(except promise-returning).
There is a big difference here. The syntax for import normalizes the name
and then resolves the name relative to the current module. System.import
only takes an already normalized name
erik: I'd be interested in learning the outcome of the normalization
discussion. As one of the maintainers of es6-shim I'm particularly
interested in ways to access ES6 features with ES5 syntax. If that
looks like:
```js
this['default'] = Promise.join(System.import('foo'),
System.import('bar
On Feb 14, 2014, at 12:09 PM, John Barton johnjbar...@google.com wrote:
(There is no spec on System, just rumors that it will be a predefined,
global instance of Loader).
Rumors is a bit much. :) The notes do show the discussion but the resolution
for some reason didn't get recorded. IIRC
On Fri, Feb 14, 2014 at 12:59 PM, David Herman dher...@mozilla.com wrote:
https://github.com/rwaldron/tc39-notes/blob/9ac398908394f9e2f8a1ac9b1e0c83952cd2f2fa/es6/2014-01/jan-28.md#spec-status-update
Yeah, I read that, and I thought the absence of a 'Resolution' was a
bit suspicious. I thought
I don't think the details in System will be important, as you suggest there
is not much to say. The critical issue is whether we will have access to an
ES6 specified Loader class. The Loader class and System.fetch is enough I
think to do any custom loader thing one wants. If we only have System
32 matches
Mail list logo
