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
Jason,
I agree with you that there needs to be making rapid progress with the dynamic
module API. I also think, that TC39 need to be full engaged with the design of
that API.
However, I have some issues with the specifics you defined below. My
over-riding concern is that we don't loose from
I think a nice syntax would be allowing you to CALL import as a function
from within function bodies to get contextual dynamic loading that is still
SORT OF analyzable. It would also be nice if these import calls could
SOMEHOW work like async function calls and not require direct interaction
with
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 of the
I'd like to see a general horn-clause style dependency resolution system built
into JavaScript functions and see that applied to dynamic loading. Then the
same system could be used to executing async operations smoothly, logic
programming, etc. Something smart enough to resolve all the
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 this` as
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
The `System.loader.import` feature isn't ready for stabilization yet, and
is blocked on a few other pieces of the Loader design. The concerns you
mention are definitely important and we're working on them in the Loader
spec, but no need to rush something through before it's ready. Over time,
we
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
It seems to me that what is needed is something like what used to be
System.get().
In an async environment this should return nothing if it's not already
loaded but in sync environments it could be treated as the imperative API
for sync module loading and go through the same loader steps as
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
On Mon, Aug 17, 2015 at 9:50 PM, Bradley Meck bradley.m...@gmail.com wrote:
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
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
The timing and extensibility is too complex to easily fit into ECMA-262,
see some things mentioned in https://github.com/whatwg/loader/issues/54 . I
vote no for a few years at least.
On Mon, Aug 17, 2015 at 4:58 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
The ES6 module system is
I agree that it could stand to wait. Also, for what it's worth, the WHATWG
loader spec is still a huge work in progress AFAIK.
On Mon, Aug 17, 2015, 18:02 Bradley Meck bradley.m...@gmail.com wrote:
The timing and extensibility is too complex to easily fit into ECMA-262,
see some things
Having a simple general purpose import seems a good enough goal to me. Use if
or switch for conditional. Use try/catch/finally for error handling. Make
everything load on first call and its lazy enough.
I'd extend it to loading other content-types though. If you want to import
Coffee or JSON
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
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
.
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. The
(There is no spec on System, just rumors that it will be a predefined,
global instance of Loader).
As far I know the only way to use the es6 module loader without exports or
imports is to set values on 'this', the global object. I guess it's not
very different from using IIFE (function() {
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'),
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
31 matches
Mail list logo
