Re: A plan to help TC39 become more open up to community contributions and participations

[John Barton]

Maybe also a factor: JS has changed a huge amount in a short time.
Developers, browsers, tools need to catch up, digest the changes, decide
what real problems remain. We have enough new for now.

On Fri, May 27, 2016 at 7:42 AM, Kevin Smith  wrote:

> Thanks for pointing out some issues with the current state of things.
> While, in general, having more people directly participate in the committee
> is probably a good thing, I don't think that will fix the problem.  I think
> you'll find yourself running into the same troubles that the current
> members face.  Specifically, there is more work to be done than there is
> time to do it.  There are more things to reach consensus on than there is
> time to discuss.  Also, there is also the risk of perpetuating an unhealthy
> "us-vs-them" mentality which seems to underly this plan and this post.
>
> Instead (or perhaps simultaneously while you explore this plan) why don't
> we try to address the community involvement problem?
>
> The big problem, I think, is that community members are directed to
> es-discuss and yet es-discuss has been largely been abandoned by TC39
> committee members.  Why has es-discuss been abandoned?  There are a couple
> of reasons I think:
>
> 1. Github (and their "issues" feature) has turned out to be a much better
> platform for working out design details on particular proposals.  Community
> members have successfully and productively participated in the design
> process in this way.
> 2. The signal-to-noise ratio here is *really* bad these days.  Let's be
> honest: most of the strawman proposals that are brought here are pretty
> terrible.  It takes time to review and comment on even the worst ones, and
> that's time that I (for one) would rather spend doing other things, like
> working on observables, or cancel tokens, or private state, or async
> generators, or drinking eine bier.
>
> The other problem that I've heard mentioned is that certain high-profile
> proposals (like that function-pipe one) aren't getting any traction.
>
> First, there are *very* few proposals that fit into that category.  Claude
> Pache's https://github.com/claudepache/es-optional-chaining is great!  In
> general though, if a proposal isn't getting picked up it's probably because
> either it has significant issues that committee members don't like, or the
> time for it just isn't right.  Time is a limiting factor and we have many
> proposals working through the process already.
>
> I'll spend some time thinking about how we can improve the es-discuss
> involvement problem.  Thanks again for bringing attention to it!
>
>
> On Thu, May 26, 2016 at 8:06 AM G. Kay Lee <
> balancetraveller+es-disc...@gmail.com> wrote:
>
>> (This is a continuation of [a previous discussion](
>> https://esdiscuss.org/topic/tracking-proposals-should-be-standardized-with-issues
>> ))
>>
>> So, to summarize, while rules and platforms currently in place do allow
>> for community contributions, they are hardly friendly ones. A few issues:
>>
>> * The mailing list is a really awkward platform for community
>> participants to collaborate, especially when debates and discussions can
>> span months, even years; threads, reasonings, and important conclusions
>> tend to become buried over time, resulting in a never-ending reincarnation
>> of dead ideas and, more importantly, lose of precious lores and insights.
>>
>> * Self-contradictory rules about the processing of community proposals in
>> official documents, because these rules were [authored by a few different
>> individuals without a definitive source](
>> https://esdiscuss.org/topic/tracking-proposals-should-be-standardized-with-issues#content-17
>> ).
>>
>> * The most widely circulated version of these rules demands community
>> proposals to find "champions", ie. member representatives willing to serve
>> as lobbyists; the real story, however, is that member representatives are
>> very busy and, when they do have time, they will almost always lobby for
>> proposals that their organizations or themselves are interested in. No
>> blaming here because this is just the way human society works, which brings
>> the conclusion that this requirement is simply antihuman.
>>
>> In the previous discussion, Allen mentioned that a lot of efforts have
>> already been put in place to make TC39 as open as possible under the bylaws
>> and rules of Ecma International, for which I am sure every non-member
>> participant of the standardization process is really appreciated. But I
>> think there is still room to do better.
>>
>> For that reason I intend to form a nonprofit organization and apply for
>> Ecma membership to help further opening up the standardization process of
>> ECMAScript to interested participants who currently do not enjoy the
>> privilege of becoming member representatives.
>>
>> I've been in contact with Secretary General Istvan and apparently this is
>> doable as long as the General Assembly vote in favor of my application, so
>> I th

Re: ES6 import directive

[John Barton]

Hi Lorenzo, almost all of your requests are covered by a related imperative
loader API,
http://whatwg.github.io/loader/#loader-import
This work is not quite complete and thus not well described but your goals
will be met with this API.

jjb

On Thu, Jan 7, 2016 at 8:30 AM, Lorenzo Ferrara 
wrote:

> Dear Ecma International, (and Dear readers, as I don't exactely know who
> will read this mail)
>
> first of all, I think you do a great job standardising ECMAScript,
> which I honestly am a great admirer of.
>
> However, there is 1 (only 1) point I can't agree with: the "import"
> statement.
> I want to state my opinion on the ECMAScript "import" statement,
> which is why, as I couldn't find a GitHub issues page, I am writing you
> this letter.
> English is not my primary language, so I hope I can explain you my opinion
> without misconceptions.
>
> Since years there has been a need for a C-style "include" method,
> which enables "importing" external library code into own code.
> Finally, with the ES6 standard, the "import" directive has been developed,
> which is a synchronous and kind of intuitive method for importing external
> library code.
>
> 1) However, I think the ES6 "import" doesn't conform with the general
> ECMAScript-style very well,
> because while ES is a very dynamic scripting language, where you can
> choose almost everything at runtime,
> "import" breaks with this style as "import" requires the name of the
> library to be known at "compile-time",
> what makes things like
> import f from (prompt("use old library, for older
> browsers")?"oldlib.js":"newlib.js");
> impossible, which takes away a bit of dynamism from ES.
> "import" should enable choosing the required libraries at run-time.
>
> 2) imports shouldn't be synchronous, as they require a file to be
> downloaded (probably over network).
> As almost any Ajax tutorial states, synchronous file downloads over
> network are bad practice for various reasons.
> For example, subsequent code in a file importing a library has to pause
> execution until the library file has loaded.
> So, code in a .js file cannot execute until all libraries have loaded,
> which is a great impact.
>
> imports should be asynchronous.
> And, as they can either succeed (when they are successfully downloaded and
> parsed) or fail,
> they should be tied closely to Promises.
> Every import should return a Promise
> that fulfills when the library is ready to use
> and fails when something went wrong while loading the library.
>
> 3) imports shouldn't have their own syntax since this makes polyfilling
> harder.
> there are already some transpilers around, but no recent transpiler can
> successfully transpile the following:
> alert(1);
> eval('import x from "mylib"; alert(x)');
> alert(2);
> In this short piece of code, we can see 2 downsides of current imports:
> * they are synchronous, so alert(2) will not alert 2 until "mylib" has
> loaded.
> * to execute the code, the execution environment (interpreter) has to
> fully support the syntax.
> Instead of inventing a new syntax for imports, I would use the existing
> function-style syntax.
> Like the following:
> alert(1);
> import("mylib").then(function(mylib){
> alert(mylib.x);
> alert(2);
> });
>
> 4) I don't think a library should be a singleton. Rather, libraries should
> be kind of instantiatable classes.
> Further more, one should be able to pass arguments to the library when
> importing a library.
> But 4) is just my personal opinion based on personal experience.
> However, I think 1) to 3) are important and should at least be considered.
>
> So, in general, I think introducing imports on a language level is a great
> idea,
> however, for implementation easement and for other reasons,
> I would prefer asynchronous imports using existing syntax
> instead of synchronous imports with new syntax.
>
> Please correct me if I got something wrong.
> I'm looking forward to your feedback.
>
> Cheers,
> 74h7k3fg
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: treated as a module if ...

[John Barton]

On Sun, Jul 5, 2015 at 8:46 AM, Domenic Denicola  wrote:

> To be explicit: there is no way to look at a string of JavaScript text and
> tell whether it should be treated as a module or a script. In many
> instances the same string can be treated as both.



> The decision is made by the execution environment.
>

I don't think Domenic meant that the standard explicitly states that the
execution environment may choose the parse method.  Rather that the context
of loading the code determines the parsing method.

I believe that the current status is that the standard describes the two
parsing methods but says nothing about when they will be applied. We do
know that 

Re: Promise sub-class: super((resolve, reject) => this) ?

[John Barton]

On Wed, Jun 3, 2015 at 1:27 AM, Benjamin Gruenaum 
wrote:

> Am I missing something obvious in `super((resolve, reject) => this)` ?
>
> First of all, it makes perfect sense for `this` not work work before super
> has been called - and it has not been called yet.
>

Rather than starting off by claiming the restriction on "this" before
"super()" makes perfect sense, let's be honest that lots of normal
developers will be tripped up by this restriction. "this" is used a
reference throughout class code: it makes "perfect sense" to use it in a
constructor.  Passing extended-class-specific values to super() is exactly
what super() does. Thus using "this" in a constructor before calling
super() is entirely natural in light of other experience with the
language.  Our inability to support "this" before super() is unfortunate,
so let's sympathize and encourage people to understand.



> I think that the crux is that the promise constructor runs _synchronously_
> so when you pass it `this` it has not finished running yet.
>
> Of course, the workaround as domenic has pointed is to extract `resolve`
> and `reject` from the `super` call since it is synchronous.
>
> (also I'm assuming you're not really mapping `(resolve, reject)` to
> `this`? `this` is an object and the promise constructor ignores return
> values anyway, you might as well pass a no-op in.)
>
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import ModuleSpecifier

[John Barton]

This same claim could be made about every item in ECMAScript.
Implementation variation in ModuleSpecifiers is no different from variation
in the allowed keywords, character set, or really anything a developer
types.  Failing to specify this aspect of the language makes no sense to
this developer at least.

On Sun, May 31, 2015 at 7:30 PM, Brendan Eich  wrote:

> Browsers in any semi-competitive market will agree on a standard. I don't
> see why that needs to be called into doubt, even as part of a "hypothetical
> future" :-|. (Is there another kind? :-P)
>
> /be
>
> Domenic Denicola wrote:
>
>> Yes, in theory. However, browsers are more likely to wait until there’s a
>> standard for browser module loaders before shipping modules, in order to
>> avoid such divergent behavior.
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

[John Barton]

Sorry, but what I read was not an explanation but rather a hope that HTTP/2
would magically solve this problem.  I'm all for HTTP/2 solving this. But
so far I've not heard or read anything to back up the idea.

Will HTTP/2 make multiple round trips, one for each level of the dependency
tree, competitive with pre-bundling? If not, then we will have to send
dependency info to the client or cache info to the server or bundle. Or
there is some magic as yet unexplained?

jjb

On Thu, Apr 23, 2015 at 7:47 AM, Domenic Denicola  wrote:

>  Indeed, there is no built-in facility for bundling since as explained in
> this thread that will actually slow down your performance, and there’s no
> desire to include an antipattern in the language.
>
>
>
> *From:* es-discuss [mailto:es-discuss-boun...@mozilla.org] *On Behalf Of *Eric
> B
> *Sent:* Thursday, April 23, 2015 10:25
> *To:* Frankie Bagnardi; Matthew Phillips
> *Cc:* es-discuss
> *Subject:* Re: Re: Are ES6 modules in browsers going to get loaded
> level-by-level?
>
>
>
> So just to clarify, when browsers support es6 modules we will still need
> some extra library to bundle the modules?  This would mean es6 modules are
> only a syntactical addition and not something functional?
>
>
>
> On Thu, Apr 23, 2015 at 10:18 AM Frankie Bagnardi 
> wrote:
>
>  Matthew, there are already tools for es6 modules + bundling (e.g. babel
> + webpack), or converting es6 modules to AMD (e.g. babel
> ).
>
>
>
>
>
>
>
> On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips 
> wrote:
>
>
>  Can you clarify what you mean about bundling? Unless I've missed
> something, the ES6 module system does not have a story for bundling at all.
> Of course formats can be invented in userland but I'm not sure that they
> are any easier to implement than say AMD's.  I might have missed something
> though, looking forward to your reply.
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Are ES6 modules in browsers going to get loaded level-by-level?

[John Barton]

Correct, ES6 has no plans for a bundling solution and the whatwg group
working on the loader has not proposed one.

Nevertheless  bundling solution is easier to build and specify. In ES6,
given a root module you can compute the (static) dependency graph as the
basis for creating a bundle.  The bundle will be complete and -- if the
code has no unnecessary imports -- minimal.  Moreover, the unnecessary
imports can be determined by parser analysis alone.

Since bundling includes issues of transport,  compression, and
minification, I suspect that a standard may not emerge any time soon.
Rather I expect a few tools to emerge and these will become de facto
standards for bundling.

jjb


On Wed, Apr 22, 2015 at 7:10 PM, Matthew Phillips 
wrote:

>
> Can you clarify what you mean about bundling? Unless I've missed
> something, the ES6 module system does not have a story for bundling at all.
> Of course formats can be invented in userland but I'm not sure that they
> are any easier to implement than say AMD's.  I might have missed something
> though, looking forward to your reply.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Are ES6 modules in browsers going to get loaded level-by-level?

[John Barton]

On Thu, Apr 16, 2015 at 11:16 PM, medikoo 
wrote:

> Thanks for clarifications,
>
> Still after reading your comments I have a feeling that providing ES6
> modules to browsers (efficient way) will be much more cumbersome and tricky
> than it is to provide CJS ones now.
>

There is no technological reason to have such a feeling. The design of the
ES6 module system makes creating bundles much easier and with much less
chance of error. All of the imports can be computed from a given root
module without relying on the developer build a list or organizing the
bundle inputs into folders.  This is not true for CJS.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Are ES6 modules in browsers going to get loaded level-by-level?

[John Barton]

On Thu, Apr 16, 2015 at 1:22 PM, Domenic Denicola  wrote:

> From: John Barton [mailto:johnjbar...@google.com]
>
> > But the push scenario in your first paragraph would not use the cache
> either.
>
> Yeah, that's what I was alluding to with the "most naïve" comment.
>
> >  one or the other has to send its information at the outset of a import
> request, or
>
> One way of doing this I came up with off the top of my head is to add some
> kind of "dependency graph version" or hash to the query string. I.e.
> . The server can then
> assume that the client has in its cache version 1234 of the dependency
> graph, and can push the incremental updates since then (i.e. added or
> modified files). If parts of the cache were evicted, so that the versioning
> signal is not entirely accurate, then the penalty is not so bad, as you
> just fall back to the normal loading process for the evicted subset.
>
> But I feel pretty silly speculating here as I'm not an expert on HTTP/2
> techniques, and there are probably other methods that are better in various
> ways.
>

Perhaps, but I feel the issue is more fundamental. HTTP/2 shares
statelessness with HTTP/1. It follows that the state of the client must be
sent to the server or vice versa.  HTTP/2 can make that process much faster
but it's not going to know what state to send without instructions from
clients or from servers. We can all make up those instructions one at a
time and in our own unique ways or the module experts can come up with a
good solution for the common cases.  I'm hoping for the latter ;-)

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Are ES6 modules in browsers going to get loaded level-by-level?

[John Barton]

On Thu, Apr 16, 2015 at 12:18 PM, Domenic Denicola  wrote:

> > Is there any mean in sight, that will allow us to serve
> > them as fast as we can serve hundreds of bundled and minimized CJS
> > modules now?
>
> Yes. Any browser which implements the ES6 module loader (none of them
> right now) will also be a browser that implements HTTP/2 (all of them right
> now). HTTP/2 server push would allow you to respond to a single request for
> "entry.js" (e.g. from ``)
> with responses for all modules in the entire dependency graph, prioritized
> according to their level in the graph, all over a single TCP connection.
>
> This is just the most naïve strategy I could think of with HTTP/2. There
> are more interesting ones too.
>
> It's also important to note that bundling is an antipattern in the HTTP/2
> world, as it prevents incremental cache updates by invalidating the entire
> bundle graph when you change a single file, and does not allow relative
> prioritization of individual files.
>

But the push scenario in your first paragraph would not use the cache
either.

As far as I can tell, only the client knows which modules it has loaded;
only the server knows the dependency graph for modules-to-be-loaded. So:
  one or the other has to send its information at the outset of a import
request, or
  the server needs to send the entire bundle, or
  the loading has to be layer by layer.
HTTP/2 does seem to have the magic to avoid considering these issues in
module loading.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Are ES6 modules in browsers going to get loaded level-by-level?

[John Barton]

An async load will call for a module that knows--synchronously--its
imports. The server can respond with the entire tree in one response.

The problem comes in avoiding duplicate transmission of modules shared by
multiple async loads. The client will need to signal the server about the
previously loaded modules.

If you search this list back to posts by Ian Hickson you can read about his
HTTP/2 based discussions.

Broadly this subject is considered by "professional" web developers as just
a moot point.  They consider dynamic loading with decisions made in the
client to be undesirable.  They do support what might be called "optional"
loading, where only part of the JS is loaded initially and more JS is
loaded later. But the dependency decisions are all baked into the server
and thus the tree of layers known only in the client does not arise.

HTH,
jjb

On Thu, Mar 26, 2015 at 12:08 PM, Wizek <123.wi...@gmail.com> wrote:

> *I've been redirected from here:
> https://github.com/tc39/ecma262/issues/27#issuecomment-84474257 . Not
> sure if this is a good place to ask this question. If not, I'm sorry for
> the noise. Could you then point me elsewhere perhaps?*
>
> I've just read this post here:
> http://www.2ality.com/2014/09/es6-modules-final.html
> Which claims that the module system will support both sync and async
> loading. Which I like. But it made me wonder if/how well async loading
> would work for deeper dependency trees. E.g. if I had a project with 20
> level deep dependency tree (at its deepest point) and my server would take
> on average 200ms to respond, then it would take about 4000ms minimum to
> execute any/all of my scripts, right? Or is there something I am missing?
>
> If I interpret the situation correctly, what is the conceptual response to
> this scenario? Try to limit the tree depth? Concat everything just like it
> happens often with ES5? Something else?
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: include 'foo/index.js' or include 'foo'?

[John Barton]

The following solution has worked very well for us:

import './foo/index.js';
means resolve './foo/index.js' relative to the importing file.

All of the rest mean look up 'foo' in the developer's mapping of names,
replacing 'foo' with a path that is then used to resolve the import.

To be sure 'foo' 'foo/index' and 'foo/' would likely fail after lookup
since they don't name files.

(This kind of thing cannot be "up to the host". If TC39 passes on deciding,
then developers will).

jjb

On Thu, Feb 5, 2015 at 5:01 AM, Glen Huang  wrote:

> I believe this is out the scope of ecmascript. It’s up to the host to
> determine how the paths are resolved.
>
> See
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-hostnormalizemodulename
>
> On Feb 5, 2015, at 8:51 PM, monolithed  wrote:
>
> I could not find an answer in the specification regarding the following
> cases:
>
> import './foo/index.js'
> import 'foo/index.js'
> import 'foo/index'
> import 'foo'
> import 'foo/'
>
>
> Is there a difference?
>
> Node.js lets create an 'index.js' file, which indicates the main include
> file for a directory.
> So if you call require('./foo'), both a 'foo.js' file as well as an
> 'foo/index.js' file will be considered, this goes for non-relative includes
> as well.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Any news about the `` element?

[John Barton]

Couldn't the  tag be restricted to be the last tag inside ?
Then we don't need them to be async to avoid blocking rendering and the
declarative order would more closely match the semantics.  Multiple tags
could be loaded in parallel and sequenced on execution.

jjb

On Sat, Dec 20, 2014 at 3:59 PM, Allen Wirfs-Brock 
wrote:

>
> On Dec 20, 2014, at 2:02 PM, Caridy Patino wrote:
>
> John, think of .
>
> For , async is implicit.
>
>
> What if you have a series of modules that need to be evaluated in
> sequential order?  (Remember, that a module with no imports is the module
> worlds  equivalent to a simple  sequential script.).  eg:
>
> <script type="module">
>window.sequence = 10;
>console.log(window.sequence);
> /script>
> script type="module">
>console.log(" should be 11: " + ++window.sequence);
> 
> 
>console.log(" shoud be 12: " + ++window.sequence);
> 
>
> Allen
>
>
>
>
>
>
>
>
>
>
> Sent from my iPhone
>
> On Dec 20, 2014, at 3:01 PM, John Barton  wrote:
>
>
>
> On Sat, Dec 20, 2014 at 10:54 AM, Matthew Robb 
> wrote:
>
>>
>> On Sat, Dec 20, 2014 at 1:50 PM, Caridy Patino  wrote:
>>
>>> what make you think this proposal implies blocking?
>>
>>
>> ​I think he was reading your examples using "require()" and thinking you
>> were suggesting that the semantics would match.​
>>
>
> Indeed that is what I was thinking.
>
> A non-blocking  tag is a poor match to HTML, a declarative
> language where order of tags means order of parsing and rendering. Giving
> up this fundamental characteristic of HTML, in the long-shot effort to
> improve the apparent load time for some amateur Web sites, has become
> dogmatic so I suppose there is no value in discussing it.
>
> A non-blocking  tag would also prevent experienced developers from
> controlling rendering through JS action. That means they will need to use
> 

Re: Any news about the `` element?

[John Barton]

On Sat, Dec 20, 2014 at 10:54 AM, Matthew Robb 
wrote:

>
> On Sat, Dec 20, 2014 at 1:50 PM, Caridy Patino  wrote:
>
>> what make you think this proposal implies blocking?
>
>
> ​I think he was reading your examples using "require()" and thinking you
> were suggesting that the semantics would match.​
>

Indeed that is what I was thinking.

A non-blocking  tag is a poor match to HTML, a declarative language
where order of tags means order of parsing and rendering. Giving up this
fundamental characteristic of HTML, in the long-shot effort to improve the
apparent load time for some amateur Web sites, has become dogmatic so I
suppose there is no value in discussing it.

A non-blocking  tag would also prevent experienced developers from
controlling rendering through JS action. That means they will need to use

Re: Any news about the `` element?

[John Barton]

On Fri, Dec 19, 2014 at 8:55 PM, caridy  wrote:

> inline...
>
> > On Dec 19, 2014, at 3:21 PM, James Burke  wrote:
> >...
> > * How does dynamic loading work in a web worker? In general, how does
> > dynamic loading work when there is no DOM.
>
> think about this as nodejs without NPM and core modules, where we can only
> do `require(‘./path/to/something.js’)` and
> `require(‘/full/path/to/something/else.js’)`, and we can evolve from there.
> The web worker is definitely in our radar, we just don’t have a solution
> for it without the loader implementation (same for realms).
>

This seems to imply that module loading would be a blocking, synchronous
call. Such a change would have huge implications, just as the previous
Loader's async dynamic API did in reverse. Either way I hope there will be
some public debate on that issue so we come away believing the best choice
was made.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: What would a 1JS-friendly strict mode look like?

[John Barton]

1JS strict mode would look like modules.
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules that don't exist

[John Barton]

At least using the older loader spec 'file' and 'line' alone is not enough
information for the loader to determine which file to load. I think the
error message should echo all of the information the developer would need
to recreate the error state and hopefully diagnose the issue.  I agree that
the importing line would be a good addition.

jjb

On Fri, Nov 21, 2014 at 9:18 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> to be honest I think that `.file` and `.line` would cover the "who
> imported what" scenario but those look like a very good/complete `.message`
> for such error, nice job
>
>
>
>
> On Fri, Nov 21, 2014 at 3:37 PM, John Barton 
> wrote:
>
>> Traceur reports such errors like this:
>>
>> // Error: File not found 'feature/Modules/resources/no_such_file.js'
>> // Error: Specified as ./resources/no_such_file.js.
>> // Error: Imported by
>> feature/Modules/Error_InvalidModuleDeclaration.module.js.
>> // Error: Normalizes to feature/Modules/resources/no_such_file.js
>> // Error: locate resolved against base './'
>>
>> import * as b from './resources/no_such_file.js';
>>
>> jjb
>>
>> On Fri, Nov 21, 2014 at 3:49 AM, Marius Gundersen 
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 21, 2014 at 11:49 AM, Andrea Giammarchi <
>>> andrea.giammar...@gmail.com> wrote:
>>>
>>>> a native ImportError seems to me the best option and it's also easy to
>>>> polyfill in a meaningful way with all current module loaders used already
>>>> out there.
>>>>
>>>>
>>> My experience with AMD and require.js is that it is very useful for the
>>> error to include not only the module that couldn't be loaded but also the
>>> module that requested it. These two fields should be on the Error object,
>>> and so a new ImportError with the field `missingModule` and `requestedBy`
>>> (or something similar) sounds like a good solution to me.
>>>
>>> Marius Gundersen
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules that don't exist

[John Barton]

Traceur reports such errors like this:

// Error: File not found 'feature/Modules/resources/no_such_file.js'
// Error: Specified as ./resources/no_such_file.js.
// Error: Imported by
feature/Modules/Error_InvalidModuleDeclaration.module.js.
// Error: Normalizes to feature/Modules/resources/no_such_file.js
// Error: locate resolved against base './'

import * as b from './resources/no_such_file.js';

jjb

On Fri, Nov 21, 2014 at 3:49 AM, Marius Gundersen 
wrote:

>
>
> On Fri, Nov 21, 2014 at 11:49 AM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>
>> a native ImportError seems to me the best option and it's also easy to
>> polyfill in a meaningful way with all current module loaders used already
>> out there.
>>
>>
> My experience with AMD and require.js is that it is very useful for the
> error to include not only the module that couldn't be loaded but also the
> module that requested it. These two fields should be on the Error object,
> and so a new ImportError with the field `missingModule` and `requestedBy`
> (or something similar) sounds like a good solution to me.
>
> Marius Gundersen
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: A new ES6 draft, Rev28

[John Barton]

On Tue, Oct 14, 2014 at 11:04 PM, Allen Wirfs-Brock 
wrote:

> This includes the major work items from the September TD39 meeting.
>>
>> Changes include:
>>
>>- Removed loader pipeline and Reflect.Loader API (functionality being
>>transfered to sperate specification)
>>
>> Any discussion about will author this separate spec - TC39?
>
> yes, same folks driving the work.  Just decoupled the specs and schedules.
>

I just tried to lookup some thing about modules on
http://people.mozilla.org/~jorendorff/es6-draft.html.  The Loader related
stuff is now either unrecognizable or completely different.  Why were such
drastic changes made and where is the discussion about the path forward?

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: what makes a file a module?

[John Barton]

On Sun, Oct 19, 2014 at 2:23 PM, Allen Wirfs-Brock 
wrote:
>
>
> It is implementation dependent how it is determined whether an individual
> file will be parsed as a Script or as a Module.
>
> Axel alluded to a possible HTML extension that could be used to
> distinguish modules from scripts.  But, exactly how modules will be
> integrated into HTML is still under development.
>
> You can imagine various ways that modules might be identified in a command
> line environment. for example
>
> js script1.js -m mod1.js -m mod2.js script2.js
>
> so of us have argued that a module file extension might be useful in such
> environments:
>
> js script1.js mod1.js mod2.js script2.js
>

FWIW, traceur has to use --script vs --module on the command line and
.module.js among files otherwise parsed as script.

You may recall that Yehuda Katz suggested on this group that a prefix might
be used, script:file.js. To avoid long arguments about What Is a URL, I
suggest a postfix string, file.js,script. Of course a file extension would
be better. Many build tools use filenames and this issue puts practical
work with ES6 at a disadvantage.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: dynamic synchronous import

[John Barton]

What is wrong with Loader.get()?
---
Reflect.Loader.prototype.get ( name )If this Loader's module registry
contains a Module with the given normalized name, return it. Otherwise,
return undefined. If the module is in the registry but has never been
evaluated, first synchronously evaluate the bodies of the module and any
dependencies that have not evaluated yet.
But more important perhaps, what is wrong with asynchronous loads? The
System.import() promises a module after loading all of its dependencies;
previously imported modules are not reloaded.  This code can be used in
development, then in production the bundled modules can be prefixed to load
the registry and the same call executes the same app. If this scheme is not
going to work now is the time to sort it out.

jjb


On Sat, Sep 27, 2014 at 10:01 PM, John Lenz  wrote:

> I would like to see some way to preload everything, and be able to
> retrieve them synchronously, something like:
>
>   System.loader.addNoAsync('...');  // throw if all imports aren't
> available already
>
> So that the script could be used during initial render. I understand that
> this would mean that the module would need to be parsed and executed
> synchronously. Forcing folks to never use any module for code that needs to
> be inline seems like a bad turn.
>
> On Fri, Sep 26, 2014 at 1:44 PM, John Barton 
> wrote:
>
>> Theoretically you can use System.normalize() and System.get() to lookup a
>> module by name synchronously. The normalize feature requires a referrer or
>> address.
>>
>> Since browsers are determined to eliminate synchronous scripts, you may
>> as well deal with the asynchronous System.import() and obnoxious promises
>> stuff now and save yourself some pain later.
>>
>> jjb
>>
>> On Fri, Sep 26, 2014 at 9:40 AM, Konstantin Ikonnikov <
>> ikokos...@gmail.com> wrote:
>>
>>> I don't want load module using http request. In my case module already
>>> defined and I want import it later when I get its name:
>>>
>>> ```js
>>> var moduleName = getModuleName();
>>> import { foo } from moduleName;
>>>
>>> // use foo
>>> ```
>>>
>>>
>>>
>>> 2014-09-26 20:00 GMT+04:00 Marius Gundersen :
>>>
>>>> And the reason you cannot import a module synchronously is that it
>>>> would freeze the entire browser until the http request completes, which
>>>> could be several seconds on a slow internet connection.
>>>>
>>>> If you want to import something dynamically you can do it using the API
>>>> (to be finalized, I believe):
>>>>
>>>> ```js
>>>> var moduleName = 'foo';
>>>> Loader.import(moduleName).then(function(foo){
>>>>   //use foo here
>>>> });
>>>> ```
>>>>
>>>> Marius Gundersen
>>>>
>>>> On Fri, Sep 26, 2014 at 5:29 PM, John Barton 
>>>> wrote:
>>>>
>>>>> no.
>>>>>
>>>>> On Fri, Sep 26, 2014 at 8:12 AM, Konstantin Ikonnikov <
>>>>> ikokos...@gmail.com> wrote:
>>>>>
>>>>>> Can I import module dynamically, but synchronously? Example for
>>>>>> common js
>>>>>>
>>>>>> ```js
>>>>>> var moduleName = 'foo';
>>>>>> var foo = require(moduleName);
>>>>>> ```
>>>>>>
>>>>>> In es6 draft I found that ModuleSpecifier must be a StringLiteral
>>>>>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-imports
>>>>>>
>>>>>> ___
>>>>>> es-discuss mailing list
>>>>>> es-discuss@mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>>>
>>>>>
>>>>> ___
>>>>> es-discuss mailing list
>>>>> es-discuss@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: dynamic synchronous import

[John Barton]

Theoretically you can use System.normalize() and System.get() to lookup a
module by name synchronously. The normalize feature requires a referrer or
address.

Since browsers are determined to eliminate synchronous scripts, you may as
well deal with the asynchronous System.import() and obnoxious promises
stuff now and save yourself some pain later.

jjb

On Fri, Sep 26, 2014 at 9:40 AM, Konstantin Ikonnikov 
wrote:

> I don't want load module using http request. In my case module already
> defined and I want import it later when I get its name:
>
> ```js
> var moduleName = getModuleName();
> import { foo } from moduleName;
>
> // use foo
> ```
>
>
>
> 2014-09-26 20:00 GMT+04:00 Marius Gundersen :
>
>> And the reason you cannot import a module synchronously is that it would
>> freeze the entire browser until the http request completes, which could be
>> several seconds on a slow internet connection.
>>
>> If you want to import something dynamically you can do it using the API
>> (to be finalized, I believe):
>>
>> ```js
>> var moduleName = 'foo';
>> Loader.import(moduleName).then(function(foo){
>>   //use foo here
>> });
>> ```
>>
>> Marius Gundersen
>>
>> On Fri, Sep 26, 2014 at 5:29 PM, John Barton 
>> wrote:
>>
>>> no.
>>>
>>> On Fri, Sep 26, 2014 at 8:12 AM, Konstantin Ikonnikov <
>>> ikokos...@gmail.com> wrote:
>>>
>>>> Can I import module dynamically, but synchronously? Example for common
>>>> js
>>>>
>>>> ```js
>>>> var moduleName = 'foo';
>>>> var foo = require(moduleName);
>>>> ```
>>>>
>>>> In es6 draft I found that ModuleSpecifier must be a StringLiteral
>>>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-imports
>>>>
>>>> ___
>>>> es-discuss mailing list
>>>> es-discuss@mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: dynamic synchronous import

[John Barton]

no.

On Fri, Sep 26, 2014 at 8:12 AM, Konstantin Ikonnikov 
wrote:

> Can I import module dynamically, but synchronously? Example for common js
>
> ```js
> var moduleName = 'foo';
> var foo = require(moduleName);
> ```
>
> In es6 draft I found that ModuleSpecifier must be a StringLiteral
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-imports
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Idea for Strawman: separate the core standard library itself into modules

[John Barton]

A way to start would add new built-ins only in modules.
jjb

On Mon, Sep 22, 2014 at 12:15 PM, Isiah Meadows  wrote:

> Transitioning the native API to modules is more of a proposed long term
> goal of this proposal. It'll take years to fully realize.
> On Sep 22, 2014 3:10 PM, "Isiah Meadows"  wrote:
>
>> @Brendan I'm aware of that pattern. For now, I'm more concerned about the
>> option of modules. It would be nice to import the standard library features
>> you need, and if, for some reason, one of the API natives get overwritten,
>> you have a fallback.
>> On Sep 22, 2014 1:18 PM, "Brendan Eich"  wrote:
>>
>>> Tab Atkins Jr. wrote:
>>>
 OnMon, Sep 22, 2014  at 9:04 AM,  Domenic Denicola
   wrote:

> >  From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf
> Of Isiah Meadows
>
>> >>  I know this would break a lot of backwards compatibility
>> completely, so this is purely hypothetical, and I expect this to not 
>> have a
>> realistic chance anytime soon.
>>
> >
> >  Anything that breaks backward compatibility will not have a chance,
> realistic or otherwise,*ever*.
>

 To square this with Matthew's response, the original idea was to
 *also*  expose the core functionality as modules, to give you the
 ability to grab "clean" versions of any standard functions you wanted,
 while the preexisting global versions would still be there.

>>>
>>> Right!
>>>
>>> Isaih, this is good news: you can't insist on removing stuff, but if you
>>> put the cleanups and better organization in new clothes, the old drab ones
>>> will fade into disuse (even if they don't ever go away).
>>>
>>> This is kind of a "law of the Web." It turns out compat does break, and
>>> no one notices (much), over very long timeframes. At least, we saw this
>>> going from the early Web to the modern days, with a few things (corner
>>> cases in JS and CSS table layout). But these were never predictable, or
>>> major.
>>>
>>> With strict-by-default modules, we can hope for 'with' to whither away
>>> over a decade. I wouldn't bet on it, since strict mode is still opt-in and
>>> will be for 

Re: Idea for Strawman: separate the core standard library itself into modules

[John Barton]

Is __proto__ deprecated by TC39? The spec says otherwise.

On Mon, Sep 22, 2014 at 12:30 PM, Benjamin Grurnbaum 
wrote:

> With libraries like Knockout utilizing 'with', I'm not sure it'll go away
> anytime soon.
>
> Also, withering works in two directions - we now have '__proto__'
> everywhere.
>
>
> On 22 בספט׳ 2014, at 20:17, Brendan Eich  wrote:
>
> Tab Atkins Jr. wrote:
>
> OnMon, Sep 22, 2014  at 9:04 AM,  Domenic Denicola
>
>   wrote:
>
> >  From: es-discuss [mailto:es-discuss-boun...@mozilla.org
> ] On Behalf Of Isiah Meadows
>
> >>  I know this would break a lot of backwards compatibility completely,
> so this is purely hypothetical, and I expect this to not have a realistic
> chance anytime soon.
>
> >
>
> >  Anything that breaks backward compatibility will not have a chance,
> realistic or otherwise,*ever*.
>
>
> To square this with Matthew's response, the original idea was to
>
> *also*  expose the core functionality as modules, to give you the
>
> ability to grab "clean" versions of any standard functions you wanted,
>
> while the preexisting global versions would still be there.
>
>
> Right!
>
> Isaih, this is good news: you can't insist on removing stuff, but if you
> put the cleanups and better organization in new clothes, the old drab ones
> will fade into disuse (even if they don't ever go away).
>
> This is kind of a "law of the Web." It turns out compat does break, and no
> one notices (much), over very long timeframes. At least, we saw this going
> from the early Web to the modern days, with a few things (corner cases in
> JS and CSS table layout). But these were never predictable, or major.
>
> With strict-by-default modules, we can hope for 'with' to whither away
> over a decade. I wouldn't bet on it, since strict mode is still opt-in and
> will be for 

Re: import script --> .esm

[John Barton]

I work on Traceur's loader and participate in the loader discussions on
es-discuss. I find the lack of engagement by the developers of the loader
disheartening. The long, painful, sometimes contentious discussions about
classes yielded an outstanding design that works well. Is the loader on
track for similar success? We have no idea.

jjb


On Wed, Sep 10, 2014 at 9:27 PM, Yehuda Katz  wrote:

> There's a difference between "ZOMG WORKING IN SECRET" and talking to
> people and working on something privately that is still being fleshed out.
>
> Not every document on my laptop (or yours) is sufficiently ready for
> public consumption for me to put it on Github, even though I put many
> documents, in various levels of completion, on Github. Using a term like
> "secret" to refer to in-progress work is unnecessary inflammatory.
>
> Yehuda Katz
> (ph) 718.877.1325
>
> On Wed, Sep 10, 2014 at 11:20 AM, Anne van Kesteren 
> wrote:
>
>> On Wed, Sep 10, 2014 at 6:14 PM, Brendan Eich 
>> wrote:
>> > RFC4329 rightly favors application/ -- but this is all beyond the scope
>> of
>> > ECMA-262. Do Not Want TC39 deciding suffixes. Let developers develop
>> > conventions. (Just so long as they do not sound like skin diseases.)
>>
>> Well the default browser loader which is still secret(?) purportedly
>> standardizes on a "js" suffix. That is probably why this came up.
>>
>> (I think text/javascript is just fine btw. text/* works great for HTML
>> and CSS too. In any event, for the purposes of the browser JavaScript
>> does not really have a MIME type. We parse anything we get...)
>>
>>
>> --
>> http://annevankesteren.nl/
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import script --> .esm

[John Barton]

On Wed, Sep 10, 2014 at 11:28 AM, Guy Bedford  wrote:

> But within that you would also need a distinction of CommonJS or global as
> well?
>
> One way might be to set up configuration to know which module names are of
> which format:
>
> ```
> System.metadata['test/*'] = {
>   format: 'global'
> };
>
> System.metadata['src/node/*'] = {
>   format: 'cjs'
> }
> ```
>

The property of "which parser is appropriate" applies to a file, rather
than a directory. Thus I could imagine:
```
System.metadata['\.js$'] = {
  format: 'module'
};
System.metadata['\.jsm$'] = {
  format: 'global'
};
```
This strategy would allow module loaders to paper over the differences
created by not having a standard extension.


> Of course this mechanism doesn't exist by default - but you can create it
> easily with the loader hooks in just a few lines.
>

This is equally true for many features added to ES6.

jjb


>
> On 10 September 2014 20:14, John Barton  wrote:
>
>>
>>
>>
>> On Wed, Sep 10, 2014 at 11:02 AM, Guy Bedford 
>> wrote:
>>
>>> On 10 September 2014 19:18, John Barton  wrote:
>>>>
>>>>
>>>>> In NodeJS, this can be through `package.json` properties which inform
>>>>> what module format the package is. In the browser, this could be a header,
>>>>> or part of package configuration.
>>>>>
>>>>> John, in your case specifically, it would be good to get more
>>>>> background to understand what type of meta process is most suitable.
>>>>>
>>>>
>>>> What more can I say? Some files need to be parsed as Script and some as
>>>> Module.   Sometimes they are in the same project and sometimes in the same
>>>> directory.  They work on browser and node.
>>>>
>>>
>>> For Traceur, the default interpretation is as Module, so it sounds like
>>> you want a way to indicate files which break this rule and need to be
>>> interpreted as Script?
>>>
>>> Can you give an example of a type of file this would apply to?
>>>
>>
>> Every file in test/ that does not end in module.js (and by extrapolation
>> every file in every existing test suite based on mocha, jasmine etc).
>> Every file in src/node/ (and by extrapolation every pre-es6 node file).
>>
>>
>>>
>>>
>>>>
>>>> jjb
>>>>
>>>
>>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import script --> .esm

[John Barton]

On Wed, Sep 10, 2014 at 10:33 AM, Brendan Eich  wrote:

> Matthew Robb wrote:
>
>> I don't see why they have to? Traceur should be used as a build time tool
>> that ultimately runs in legacy mode. Only REAL modern ES6 module
>> implementations would run in this other world. Basically .es files today
>> would be transpiled into .js files.
>>
>
> I doubt people will do any such thing. We can have more suffixes (I was
> against .js2 in particular -- that particularly confusing proposal was why
> I unleashed the Nope-topus), but if people can adapt their existing
> practices with AMD/Require/CommonJS modules and use just .js, I bet they
> will.
>

I was reporting on the problems in practice. I don't believe any of the
problems with module vs script are specific to Traceur.  This is not
equivalent to the AMD/CommonJS problem. The AMD community agreed on a
format and a function call; similarly commonjs. In the ES case, we have one
syntax, import, with two meanings depending on an non-standard string
interpretation.


>
> Tools will have to read metadata, tea-leaves, and etheric winds to keep
> up. Same as ever.


This discussion is about the import statement and Loader.import(), not
tools.

Ultimately TC39 needs to draw a line: what is ES and what belongs
elsewhere. Overall Loader does a good job of drawing that line. But one
area I think it has missed is related to module specifiers, given the
reality that input source comes from individually named locations.  Leaving
this detail of module specifiers undefined just makes ES6 harder to adopt,
its not very hard to fix compared to many complex problems solved already
and I don't see how it has a big downside to fix.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import script --> .esm

[John Barton]

On Wed, Sep 10, 2014 at 11:02 AM, Guy Bedford  wrote:

> On 10 September 2014 19:18, John Barton  wrote:
>>
>>
>>> In NodeJS, this can be through `package.json` properties which inform
>>> what module format the package is. In the browser, this could be a header,
>>> or part of package configuration.
>>>
>>> John, in your case specifically, it would be good to get more background
>>> to understand what type of meta process is most suitable.
>>>
>>
>> What more can I say? Some files need to be parsed as Script and some as
>> Module.   Sometimes they are in the same project and sometimes in the same
>> directory.  They work on browser and node.
>>
>
> For Traceur, the default interpretation is as Module, so it sounds like
> you want a way to indicate files which break this rule and need to be
> interpreted as Script?
>
> Can you give an example of a type of file this would apply to?
>

Every file in test/ that does not end in module.js (and by extrapolation
every file in every existing test suite based on mocha, jasmine etc).
Every file in src/node/ (and by extrapolation every pre-es6 node file).


>
>
>>
>> jjb
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import script --> .esm

[John Barton]

On Wed, Sep 10, 2014 at 10:07 AM, Guy Bedford  wrote:

> The question of whether a file is a module or script is the same problem
> as to whether a module is ES6 or AMD or CommonJS.
>
> Moving it to the extension makes as much sense as having every CommonJS
> module written as `script.cjs`.
>

I don't think these are the same problem. Existing JS, AMD and CommonJS can
be parsed by the same parser, the ES6 Script parser. They can't be parsed
by the ES6 Module parser.  It is a problem, just not the same as this one.


>
> We know that we need outside metadata to work out how to interpret
> modules, and that the loader will have meta-configuration injection at some
> level, not determined by TC39.
>

One of the purposes of having modules in ES was to unify the module work in
mode and browser. Having two or more incompatible meta-data solutions to
this simple problem will defeat that goal.


>
> In NodeJS, this can be through `package.json` properties which inform what
> module format the package is. In the browser, this could be a header, or
> part of package configuration.
>
> John, in your case specifically, it would be good to get more background
> to understand what type of meta process is most suitable.
>

What more can I say? Some files need to be parsed as Script and some as
Module.   Sometimes they are in the same project and sometimes in the same
directory.  They work on browser and node.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: import script --> .esm

[John Barton]

On Wed, Sep 10, 2014 at 9:35 AM, Allen Wirfs-Brock 
wrote:

>
> On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:
>
> As soon as the language decided it would have a differentiation for
> modules vs scripts then it seems only natural that it should also specify
> at least some generic means of entry into one mode or another. Then it's up
> to browsers or who ever to determine what external signifiers would trigger
> module instead of script. Or the language parsing logic could say that in
> the presence of module syntax it will always be treated as module. I don't
> know if that's feasible or not *shrug*
>
>
> Modules and scripts can not always be identified by inspection.  Consider:
>
> foo.js ---
> const answer = 42;
> ---
>
> The semantics of this are quite different depending upon whether foo.js is
> evaluated as a script or loaded as a module.
>

This case is clearly as script, as a module it has no effect right?  Isn't
the only ambiguous case would be explicit global manipulation, where we
could decide module is used and (most of the time ;-) win.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

import script --> .esm

[John Barton]

A couple of months ago I tried out the suggestion by Yehuda Katz to use
import syntax with special module specifiers to mean parse-as-script, do
evaluate but do not produce a module.  The implementation worked well and
now I want to put a version of this idea into Traceur.

As soon as I started I ran it issues with the name. Obviously "legacy:" is
ambiguous. "script:" looks like a URL, which I suppose was intended, but
then we get into URLs in URLs.  Furthermore, the URL scheme is very
cumbersome with a filesystem, you have to have some side-table or algorithm
to match URLs to directories or filenames.

I implemented postfix ",script", but that sure looks like an extension.
Which is exactly what the semantics are: a file with a different datatype
needing different processing. So it seems to me that the most honest naming
would be some thing like ".ess".

I would just implement that solution but I proposed a similar idea a while
back to Traceur team I got a lot of pushback along the lines of "JS is one
language".  Since then several Traceur users have asked for support to a
non ".js" extension for loading modules, to be able to separate existing JS
code in .js files from new module code in files marked with a different
extension. Within Traceur's (mostly es6) code we have resorted to implicit
marking-by-directory ("All code in src/node is script, not module") or with
the wonderful extension of ".module.js" to mean "all the other files are
script, but this one is module".  So it's JS-is-one-language with two
incompatible, unmentionable dialects ;-).

Finally, naming modules as .js and ES6 Scripts as .ess has the weird result
that ES5 scripts (in .js files) would be processed as ES6 modules. That
seems dumb. So naming the new things, modules, with a new extension makes
more sense.  ".esm" seems like a obvious choice.

I know this may not seem to be the most exalted of topics for
standardization but the current choice of post-pending '.js' has real
consequences for developers. Please consider this issue.

jjb



On Mon, Jul 14, 2014 at 9:57 PM, Yehuda Katz  wrote:

> You could imagine a loader plugin that enabled:
>
> import "legacy:foo";
>
> Which would evaluate the module in a script context.
>
> Yehuda Katz
> (ph) 718.877.1325
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ... A community is writing the spec...

[John Barton]

You can find lots of information about design discussions by reading the
ecmascript wiki, for example:
http://wiki.ecmascript.org/doku.php?id=harmony:proxies.  The other good
resource is the past posts to this list and the meeting minutes,
http://esdiscuss.org/.

In general, the content that is painstakingly written down in the ES6
specification has been designed and discussed in great detail. The
appropriate level of comments on those features needs to be equally
detailed and thoughtful.
Random comments about how you personally don't like some aspects of the
design are better directed to your followers on twitter or perhaps a blog
post. And of course you are free not to use any new features you dislike. I
believe that is what Alex was attempting to communicate.

jjb


On Tue, Sep 9, 2014 at 3:25 PM, L2L 2L  wrote:

> Anyone care to justify the use case for the proxy object?
>
> Yes I understand it'll let us defined the behavior of an object. But
> couldn't that be a method for the Object constructor?
>
> E-S4L
> N-S4L
>
> On Sep 9, 2014, at 5:55 PM, "L2L 2L"  wrote:
>
> Huh? ... Should I be doing so? ... Huh?
>
> E-S4L
> N-S4L
>
> On Sep 9, 2014, at 5:54 PM, "Alex Russell"  wrote:
>
> Is there seriously going to be no attempt whatsoever to moderate this list?
>
>
> On Tue, Sep 9, 2014 at 3:42 AM, L2L 2L  wrote:
>
>> ... This language is turning note in an application than a programming
>> language.
>>
>> It could of been a commonjs thing... Long live ES5+.
>>
>> I like the let, and const syntax add on. Foo feature and fits into the
>> language.
>>
>> Yes ai agree they should release as CSS is releasing.
>>
>> E-S4L
>> N-S4L
>>
>> > On Sep 9, 2014, at 6:36 AM, "Herby Vojčík"  wrote:
>> >
>> >
>> >
>> > L2L 2L wrote:
>> >> It worry me... That a community is writing the spec... That a community
>> >
>> > Well, not the community is writing the spec. AWB is. :-)
>> > And he can be pretty tough, I more or less stopped reading this list
>> thoroughly after his letting one of the issues I saw as important left
>> ignored.
>> >
>> > Nevertheless:
>> >
>> >> is writing the spec Look like W3C... That everyone is striving to
>> >> get what they want in the language.
>> >>
>> >> Most of us are ES5 developers Meaning we don't delve into ES6 and
>> >> what else to come.
>> >>
>> >> let, const, and a couple of others spec implantation is okay. These
>> help
>> >> better the language... But your adding feature and no trying to better
>> >> what's already there.
>> >>
>> >> You might as well call yourself W3C equivalent.E
>> >>
>> >> As long as one can write compliant ES5.
>> >>
>> >> A new more stricture spec/style is being made. It's call ES5+ meaning
>> >> that all compliant code is to be writing in ES5 and additional add on
>> as
>> >> the let and const statement plus other +.
>> >>
>> >> What I see is more functionality of the browser api then an actually
>> >> language. A lot of us hope this spec die, as did ES4.
>> >>
>> >> Most of what you're adding could have been another add on spec... Like
>> >> commonjs add on.
>> >
>> > I liked the idea of ES6 pretty much. The commitee was pretty strict in
>> not adding too much, mostly paving cowpaths, had some roadmap, according to
>> which ES6 should be approved in end of 2013.
>> >
>> > Now is second half of 2014, and lots of issues are not closed yet, from
>> what I see.
>> >
>> > I got delusioned as well.
>> >
>> > Isn't the model of big new editions of spec over; in the times we live
>> now, with two-week frequent releases? I think ES6 will never see the light
>> when taken from this approach. That's why, shouldn't the release policy be
>> changed so that:
>> >
>> > - More frequent, albeit smaller, releases are embraced as a rule;
>> > - ES5.5 will be scheduled (and delivered) as a Christmas present in
>> 2014, selecting only small subset of less controversial items (let, const,
>> Reflect global object with all API applicable to ES5.5, possibly block
>> scope; no modules, no classes (unless there is consensus they are already
>> near to perfect, though my issue was about new/super inconsistency), no
>> symbols, no proxies, no for-of, iterators, generators, comprehensions, no
>> promises);
>> >  - schedule ES5.6 (and deliver it) for July 2015 with, for example,
>> for-of, iterators, generators, comprehensions (it's all related, so in a
>> single set) and if possible, classes and/or promises;
>> >  ... etc.
>> >  Possibly switching to 6 when something big gets in (symbols, classes,
>> proxies).
>> >
>> > This would be nice. Really nice. To all of us who want to get ES.next
>> and actually start developing in it.
>> >
>> > Thanks, Herby
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> 

Re: `this` inside modules

[John Barton]

Was this decision reversed? I don't see Reflect.global in the new spec.
online.
jjb


On Mon, Jun 9, 2014 at 10:08 AM, Caridy Patino  wrote:

> My point: if 'this' is not global in modules, then ES6 must have an
>> alternative way to name the global object.
>>
>
> Yes, we covered that last week. `Reflect.global` seems like the right
> place for it considering that it will be defined per realm.
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bundling vs sending serialized dependency graph

[John Barton]

On Thu, Aug 21, 2014 at 1:55 PM, Ian Hickson  wrote:

> On Thu, 21 Aug 2014, John Barton wrote:
> ... more misunderstanding about bundles skipped...
>

Let's give upon discussing bundles and pursue your dependency list scheme.


>
>
> > > I don't think it should be particularly complex. It only requires some
> > > minor changes. One is that we need to be able to declare dependencies
> > > ahead of the "instantiate" hook.
> >
> > By the way I recently discovered that the deplist returned by the
> > instantiate hook does not enter the dependency graph analysis. These
> > aren't dependencies in a list rather a list of things needed to be
> > loaded.
>
> I'm not sure what you mean here. The list returned from "instantiate" is
> treated the exact same way as the list auto-discovered from "import"
> statements when "instantiate" returns undefined: it's passed to
> ProcessLoadDependencies(), which calls RequestLoad() and
> AddDependencyLoad(), which, if necessary, updates [[Dependencies]].
>

I'll defer to Guy Bedford's expertise:
https://github.com/ModuleLoader/es6-module-loader/pull/204


>
> That's all I'm talking about. I want to be able to update [[Dependencies]]
> earlier than "instantiate", and I want to be able to mutate
> [[Dependencies]] to remove nodes that are no longer dependencies before
> the load is complete.
>
>
> > > Another (a subset, really) is that we need to be able to declare
> > > dependencies for ES6 modules as well as letting the ES6 infrastructure
> > > discover them automatically.
> >
> > In theory this should be straight-forward. In practice, well good luck.
>
> Good luck with what?
>

The JS module space has had so many rounds of discussions that many
participants are no longer willing to consider alternatives to their
current point of view.


>
>
> > > Finally, it would be ideal if we could also adjust those dependencies
> > > on the fly, since if we're reflecting dependencies described in the
> > > mutable DOM structure, it might be mutated.
> >
> > I think this one is technically difficult.
>
> I don't think anyone here is going to shy away from technically difficult
> problems, it's kind of our bailiwick. :-)
>

Sometimes it is better to have a simpler and less powerful tool which can
be well understood than a tool with many difficult-to-master features.
Mutating dependencies opens the door to many new kinds of bugs, not only in
the implementation of the Loader but, more important, in the use of the
Loader by developers.


>
> The idea is, in fact, to move as many of the technically difficult
> problems from things authors have to keep reinventing to things that
> browsers just support natively.
>
>
> > > > I guess you're proposing the send the dependency graph to the
> > > > browser, then when a new root is needed, the stored graph is
> > > > compared with the currently-loaded modules. The additional modules
> > > > needed are then requested as a group. Up to this point we can just
> > > > use build tools and browsers.
> > >
> > > Actually, modulo the changes described above, the ES6 loader already
> > > does all this.
> >
> > Huh? How do you plan to parse the modules to obtain dependencies without
> > sending them to the browser?
>
> You send them to the browser, just not in the module itself.
>

Where do you get them from?  For ES6 it has to be from a build tool or from
the server because no one is going to type these in twice.

Such a build tool is just not very difficult and it can be built in to dev
servers so it has no impact on developers work flow.


>
>
> > > It just doesn't quite handle it at the level of pre-emptive
> > > declaration of dependencies. But suppose you had two modules A, B, and
> > > C. A and B depend on C. With ES6 today, when A is loaded, it loads C.
> > > If late you load B, B doesn't reload C; it just links into it. So this
> > > is all already supported. All that's needed is a way to tell the ES6
> > > system to get C before it has even received A.
> >
> > You've really lost me now. I thought your goal was to avoid sending C
> > over the network. Now you want to send it without even seeing A?
>
> Not sending C over the network at all wouldn't work, since it would mean A
> doesn't have its dependencies available. I don't follow.
>
> The idea is that authors be able to predeclare (relevant parts of) the
> dependency tree such that when a node in that tree is neede

Re: Bundling vs sending serialized dependency graph

[John Barton]

On Thu, Aug 21, 2014 at 8:37 AM, C. Scott Ananian 
wrote:

> On Thu, Aug 21, 2014 at 11:00 AM, John Barton 
> wrote:
> >> Finally,
> >> it would be ideal if we could also adjust those dependencies on the
> >> fly, since if we're reflecting dependencies described in the mutable
> >> DOM structure, it might be mutated.
> >
> > I think this one is technically difficult.
>
> I don't think this is actually all that hard.  We have a dependency
> graph,


Where? The Load Request records imply a dependency graph. Are these
maintained though out the life of the page? I don't see any existing reason
to expect these are maintained.


> along with a list of things that are (a) required, (b) already
> loaded, and (optionally) (c) in-flight.  We mutate the graph
> arbitrarily, recompute the list of things that we need to load given
> the new (a), compare that to (b) and (c), and then start new/cancel
> old loads as necessary.  I don't think it's worthwhile to specify
> incremental algorithms here, just specify the stop-the-world
> computation over the complete graph.  Optimization left to the
> implementation, if needed.
>
> > Huh? How do you plan to parse the modules to obtain dependencies without
> > sending them to the browser?
> [...]
> > You've really lost me now. I thought your goal was to avoid sending C
> over
> > the network. Now you want to send it without even seeing A?
>
> I think Ian has explained this multiple times already.  The HTML file
> contains a declarative specification of all resource dependencies, via
> attributes on script tags or some such.  This is either generated
> manually or via some future authoring tool.
>

You deleted the context of my comment. I asserted that a build tool was
needed. Ian claimed the Loader could do it. Now you are claiming I'm wrong
because a build tool is used.


>
> This doesn't seem so crazy to me.


That's because you left out the crazy part ;-)


> And, since presumably we can
> already deal with mutation of the dependency graph (see above), we can
> always adjust those declarations to match "reality" after we parse the
> module file (although probably only to add new edges, not remove any
> declared dependencies).  Thus the base case with no explicit
> declarations in the HTML matches the on-demand behavior given by
> current ES6.
>
> Ian, FWIW, I've been staying out of this thread mostly because you
> seem to be on top of it -- and because frankly I've already been
> exhausted by the module wars.  But IMO you're doing excellent work.
>

I agree that the part of Ian's story about sending over the deps list is
beginning to sound very attractive. In fact I think it is a stronger story
than the current spec altogether.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

instantiate() deps list

[John Barton]

The Loader instantiate() function is described:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-reflect.loader.prototype.instantiate

Based on that description I assume that the 'deps' property returned by
instantiate() meant "dependencies" that would be loaded by the loader. That
is, one can leverage the dependency traversal from a custom loader. But
it's not possible to do this.

Specifically:
---
Otherwise, the instantiate hook must return an eventual
instantiationRequest object. An instantiateRequest object has two required
properties. The value of the deps property is an array of strings. Each
string is the name of a module upon which the module identified by
loadRequest has dependencies. The value of the execute property is a
function which the loader will use to create the module and link it with
its clients and dependencies. The function should expect to receive the
same number of arguments as the size of the deps array and must return an
eventual Module object. The arguments are Module objects and have a
one-to-one correspondence with elements of the deps array.

The module is evaluated during the linking process. First all of the
modules it depends upon are linked and evaluated , and then passed to the
execute function. Then the resulting module is linked with the downstream
dependencies.
---
However it turns out that the names in 'deps' are simply fetched and passed
back to instantiate(). They do not enter the dependency analysis.

To give a concrete example, if A depends on B depends on C and
instantiate() is called with A, it can't simply return a deps list with
"b". It has to perform the entire dependency analysis of A and ensure the
tree is loaded. Simply returning 'b' as a deps value will result in an
execution sequence like A, B, and then C, not the order C, B, A one would
expect from a dependency analysis.

I'm sure there is a good reason for this behavior but it should be clearly
called out in the spec.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Bundling vs sending serialized dependency graph

[John Barton]

On Wed, Aug 20, 2014 at 4:53 PM, Ian Hickson  wrote:

> On Wed, Aug 20, 2014 at 4:06 PM, John Barton 
> wrote:
> > On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson  wrote:
> >>
> >> This just doens't work.
> >>
> >> Suppose the dependency graph looks like this:
> >>
> >>  Feature A --> Dependency A1 \__\ Dependency\
> >>  Feature B --> Dependency B1 /  /AB  >--> Dependency D
> >>  Feature C --> Dependency C1 ---> Dependency C2 /
> >>
> >> All of A, B, and C are to be fetched on-demand-only, to avoid using up
> >> too much bandwidth. All the files here are non-trivial in size.
> >>
> >> How do you package this?
> >>
> >> If you make a package for A, a package for B, and a package for C, then
> >> you'll have redundant content in the packages, and when the client asks
> >> for B after already having asked for A, the amount of content sent back
> >> will be greater than necessary and therefore it'll be slower than
> >> necessary. If you create multiple packages such that you group as much
> as
> >> possible into each package as possible without overlap, then you still
> end
> >> up with multiple resources to download when you need any of A, B, or C.
> >> Basically, it boils down to:
> >>
> >>  Package A \__\ Package\
> >>  Package B /  /AB   >--> Package D
> >>  Package C ->  /
> >>
> >> ...and then you're back to the problem I asked about. If you don't have
> >> server-side support, then to avoid round-trips the client needs to know
> >> about the dependencies before it makes the first request. It can't wait
> >> til it receives the packages to discover the dependencies because if you
> >> do that then you're serialising your RTTs instead of pipelining them.
> >
> > I assume you are imagining a densely connected graph with random access
> to
> > any of the roots.
>
> I'm not quite sure what that means.
>

It means that the graph of all possible modules for a page cannot be
partitioned into packages without sending much of the shared graph over the
wire multiple times.

>
> I mean a world where different otherwise unrelated leaf modules or
> resources depend on common shared dependencies.
>

Leaf modules don't depend on anything. That's what a leaf means.


>
>
> > I expect that real life pages have well partitioned graphs
> > (widgets) that share some dense parts (utilities) and simple access
> patterns
> > -- main page, utilities, a set of widgets.
>
> I doubt that the Web is that convenient. On some well-designed sites
> it might work out that way.
>
> Consider a site like Google+, though. However well-designed it is, it
> fundamentally has a lot of common files used by lots of intermediate
> shared files used by lots of leaf modules (and a lot more depth while
> we're at it).


I think your graph is upside down from mine ;-) As I learned it, leaf nodes
were the ones at the ends of branches and hence were not dependent on any
other nodes; no node depended on a root node.


> What exactly is needed depends on what posts are
> displayed, the user's preferences with respect to features like
> Hangouts, etc. It's a complicated graph.
>

The only issue that matters for the efficiency of bundle loading is how
many nodes are shared between commonly used dynamically loaded root
modules. If the module is needed always it will be loaded always. If the
module is only used by a single dynamically loaded feature, then there is
 no penalty for bundle loading. Even in the case where two or more dynamic
loads use the same large number of modules we can simply put those modules
in a shared bundle. So the case where bundles lose is very rare.

Here is an attempt and a graph:

  A   B  C  D   E
  | /  \ | / \ /
  R  XY

R is always loaded so its bundle loads A and B.
Optional feature X loads C and D but not B its already loaded.
Optional feature Y loads E and possibly DE if X did not already load.

Only D is extra work and thus this scenario is relatively rare.  Typically
optional modules will share dependencies with the default loaded page
modules or have unique modules.



>
> > But sure, it would be great to have a complete solution if it's not a lot
> > more complex.
>
> I don't think it should be particularly complex. It only requires some
> minor changes. One is that we need to be able to declare dependencies
> ahead of the "instantiate" hook.


By the way I recently discovered that the deplist returned by the

Re: Changing dependencies during the load process.

[John Barton]

On Wed, Aug 20, 2014 at 3:23 PM, Ian Hickson  wrote:

> On Wed, 20 Aug 2014, John Barton wrote:
> > > >
> > > > The reverse case, where a img depends on a script, is not a use
> > > > case.
> > >
> > > Why not? What if the image has an onmouseover handler that calls an
> > > API function defined in a module, for instance?
> >
> > Then the page depends on the onmouseover handler code and it has a
> > dependency on the module. Images are leaf nodes in the dependency tree.
>
> Can you show me the markup for how you would like this to work? I'm not
> sure I follow what your vision is here.
>


System.import('jquery').then(() => {
  $(document).ready(() => {
$("img.a").hover(() => {
  $(this).stop().animate({"opacity": "0"}, "slow");
}, () => {
  $(this).stop().animate({"opacity": "1"}, "slow");
});
  });
});


Here the page depends upon a mouseover handler which depends upon jquery.
The handler and the page depend upon the image.


>
> ...
> >
> > If you don't want multiple round trips, import from a "bundle".
>
> That doesn't work; see the discussion in this e-mail:
>https://mail.mozilla.org/pipermail/es-discuss/2014-August/038853.html


So I answered on another thread.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Bundling vs sending serialized dependency graph

[John Barton]

On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson  wrote:

>
> 
> > That's why in my opinion 'bundles' or 'packages' make sense: they
> > combine the related dependencies and allow them to be loaded in one
> > trip.
> >...
>
> This just doens't work.
>
> Suppose the dependency graph looks like this:
>
>  Feature A --> Dependency A1 \__\ Dependency\
>  Feature B --> Dependency B1 /  /AB  >--> Dependency D
>  Feature C --> Dependency C1 ---> Dependency C2 /
>
> All of A, B, and C are to be fetched on-demand-only, to avoid using up
> too much bandwidth. All the files here are non-trivial in size.
>
> How do you package this?
>
> If you make a package for A, a package for B, and a package for C, then
> you'll have redundant content in the packages, and when the client asks
> for B after already having asked for A, the amount of content sent back
> will be greater than necessary and therefore it'll be slower than
> necessary. If you create multiple packages such that you group as much as
> possible into each package as possible without overlap, then you still end
> up with multiple resources to download when you need any of A, B, or C.
> Basically, it boils down to:
>
>  Package A \__\ Package\
>  Package B /  /AB   >--> Package D
>  Package C ->  /
>
> ...and then you're back to the problem I asked about. If you don't have
> server-side support, then to avoid round-trips the client needs to know
> about the dependencies before it makes the first request. It can't wait
> til it receives the packages to discover the dependencies because if you
> do that then you're serialising your RTTs instead of pipelining them.
>
>
I assume you are imagining a densely connected graph with random access to
any of the roots. I expect that real life pages have well partitioned
graphs (widgets) that share some dense parts (utilities) and simple access
patterns -- main page, utilities, a set of widgets.

But sure, it would be great to have a complete solution if it's not a lot
more complex.

I guess you're proposing the send the dependency graph to the browser, then
when a new root is needed, the stored graph is compared with the
currently-loaded modules. The additional modules needed are then requested
as a group. Up to this point we can just use build tools and browsers. How
will we tell the server "send me this list of files all in one response?"

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Changing dependencies during the load process.

[John Barton]

On Tue, Aug 19, 2014 at 4:25 PM, Ian Hickson  wrote:

> On Mon, 18 Aug 2014, John Barton wrote:
> > >
> > > (For example, a graphical game might need some sprite assets to be
> > > loaded before it can start up. So its  might be marked as
> > > depending on an <img> element that loads that image. Or the script
> > > contents might have an import statement that refers to that image.)
> >
> > Supporting this case seems straight-forward and can be done entirely by
> > the browser Loader implementation using hooks.
>
> That is my hope, yes.
>
>
> > The reverse case, where a img depends on a script, is not a use case.
>
> Why not? What if the image has an onmouseover handler that calls an API
> function defined in a module, for instance?
>

Then the page depends on the onmouseover handler code and it has a
dependency on the module. Images are leaf nodes in the dependency tree.


>
> > > > > Or indeed even when scripting is enabled, how would you use it to
> > > > > mark one non-loaded script as dependent on another non-loaded
> > > > > script such that when you later ask for the former, the latter
> > > > > loads automatically?
> > > >
> > > > import './latter';
> > > >
> > > > It's a solved problem for scripts.
> > >
> > > The key part of my question was "non-loaded". The "import" bit is in
> > > the script. The script isn't loaded yet, so we can't rely on it.
> >
> > <script>
> > System.import('./former').then((former) => {
> >   // do stuff with former, knowing './former' imported './latter'.
> > });
> > 
>
> This results in multiple RTTs.


If you don't want multiple round trips, import from a "bundle". Then the
first fetch gets all of the modules needed by ./former.

Also, this doesn't wait until former is
> needed before loading it.
>

But the mechanisms for knowing "need" are not available to any one at this
point. The problem is we don't know when to trigger the load, not what is
in the load.

I think you are imagining a magical trigger that does not exist. This
magical trigger would know "we are moving below the fold now".   If we had
that trigger we could delay the load of all of the modules below the fold.
 But we don't have that trigger, so there is no reason to delay sending all
of the modules for the page.

This is a critical issue. Excluding JS what means do we have for expressing
"needed"? As far as I know the list is ["Parsed"]. That is, if the resource
is needed by the page we  know that when the page is parsed. When we parse
a tag that specifies a resource load, we can block or not, but we have to
load it because there is no other future trigger to cause the load at
another time. If we had such a trigger then we could make use of it to
improve loading.

There are JS events that we can handle to control loading. JS can load a
bundle of modules given the root request. We might be able to express some
of these declaratively and that might lead to new requirements on the JS
Loader. This approach gives us the context we need to judge tradeoffs.  But
we are a long way from such need at this point: we don't have the triggers
nor a standard for bundling.


>
> > Here we are expressing the dependency of the HTML file on the non-loaded
> > file './former' and it depends on the non-loaded file './latter'.
>
> But you don't know that it depends on ./latter until you've fetched
> ./former, by which time it's too late.
>

Maybe I mis-interpreted your scenario. Sounds like you want 'bundle' or
package loading. That subject should be part of the ES spec in my opinion
but so far we can only do ad-hoc implementations.  I'm unsure why you seem
to be against this solution to your use case.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Referencing modules loaded by HTML Imports.

[John Barton]

On Tue, Aug 19, 2014 at 4:22 PM, Ian Hickson  wrote:

> On Mon, 18 Aug 2014, John Barton wrote:
> > I think we could also imagine that such an import declaration could be
> > used without the HTML Import declaration. The fetch() call will ask for
> > "/foo/b.js" and the server will say "hey that's in an HMTL
> > Import" and serve text/html. The fetch() hook will have to detect this
> > and process the HTML Import, then continue with the loading process.
>
> That's basically what everything I've been e-mailing the list about is
> intended to support.


While I think this topic -- triggering an HTML Import from a JS import --
is interesting and potentially useful, there is no new syntax or I see no
Loader implementation changes needed for this to work.

Composing HTML Imports with System.import() has issues because the import
is async, see
https://groups.google.com/forum/#!topic/polymer-dev/gbWgeLNnMrE


jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Referencing modules loaded by HTML Imports.

[John Barton]

I think that only makes sense if 'this.import()' worked for
script-tags-marked-as-modules in general. If the general case supported it,
then it should just work for HTML imports.

OTOH, I think System.import() is clearer.

jjb


On Mon, Aug 18, 2014 at 6:23 PM, Matthew Robb 
wrote:

> Would there be any problems treating the html import as a virtual module
> itself. Giving all scripts inside the sub document the module context
> object as its this binding? Then to do any additional loading you'd need to
> do this.import().
> On Aug 18, 2014 6:56 PM, "John Barton"  wrote:
>
>>
>>
>>
>> On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson  wrote:
>>
>>>
>>>
>>> > > > > Now, in the main page, you reference the HTML import:
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > Now how would you refer to the modules? We can't have #b refer to
>>> > > > > it, since the scope of IDs is per-document, and the import has a
>>> > > > > separate document.
>>>
>>
>>
>> ...
>>> HTML imports and regular documents share a Window object, but have
>>> separate Documents objects. You can find out more about them here:
>>>
>>>http://w3c.github.io/webcomponents/spec/imports/
>>
>>
>> If they share a Window object then they should share a Loader, but they
>> may have different baseURLs. So for you example above we write eg.
>>
>> import {b} from "./b";
>>
>> because the scripts in the HTML import will have names relative to the
>> same default baseURL as the main document. So I guess URL space is like
>>
>>   http://example.com/index.html
>>   http://example.com/foo.html
>>   http://example.com/b.js
>>
>> I suppose it would be more common for the component to be in a
>> subdirectory, eg
>>
>>   http://example.com/index.html
>>http://example.com/foo/theFoo.html
>>   http://example.com/foo/b.js
>>
>> so the import would be
>>
>> import {b} from "./foo/b";
>>
>> I think we could also imagine that such an import declaration could be
>> used without the HTML Import declaration. The fetch() call will ask for
>> "/foo/b.js" and the server will say "hey that's in an HMTL Import"
>> and serve text/html. The fetch() hook will have to detect this and process
>> the HTML Import, then continue with the loading process.  This much I'm
>> just making up.
>>
>> jjb
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Changing dependencies during the load process.

[John Barton]

On Mon, Aug 18, 2014 at 5:32 PM, Ian Hickson  wrote:

> On Mon, 18 Aug 2014, John Barton wrote:
>
...


>  > But in the case of image tags we already know exactly which image the
> > HTML depends upon.
>
> But other elements might depends on the , and that we don't know.


> (For example, a graphical game might need some sprite assets to be loaded
> before it can start up. So its  might be marked as depending on an
> <img> element that loads that image. Or the script contents might have an
> import statement that refers to that image.)
>

Supporting this case seems straight-forward and can be done entirely by the
browser Loader implementation using hooks.

The reverse case, where a img depends on a script, is not a use case.


>
> > > Or indeed even when scripting is enabled, how would you use it to mark
> > > one non-loaded script as dependent on another non-loaded script such
> > > that when you later ask for the former, the latter loads
> > > automatically?
> >
> > import './latter';
> >
> > It's a solved problem for scripts.
>
> The key part of my question was "non-loaded". The "import" bit is in the
> script. The script isn't loaded yet, so we can't rely on it.
>

<script>
System.import('./former').then((former) => {
  // do stuff with former, knowing './former' imported './latter'.
});


Here we are expressing the dependency of the HTML file on the non-loaded
file './former' and it depends on the non-loaded file './loaded'.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Referencing modules loaded by HTML Imports.

[John Barton]

On Mon, Aug 18, 2014 at 2:06 PM, Ian Hickson  wrote:

>
>
> > > > > Now, in the main page, you reference the HTML import:
> > > > >
> > > > >
> > > > >
> > > > > Now how would you refer to the modules? We can't have #b refer to
> > > > > it, since the scope of IDs is per-document, and the import has a
> > > > > separate document.
>


...
> HTML imports and regular documents share a Window object, but have
> separate Documents objects. You can find out more about them here:
>
>http://w3c.github.io/webcomponents/spec/imports/


If they share a Window object then they should share a Loader, but they may
have different baseURLs. So for you example above we write eg.

import {b} from "./b";

because the scripts in the HTML import will have names relative to the same
default baseURL as the main document. So I guess URL space is like

  http://example.com/index.html
  http://example.com/foo.html
  http://example.com/b.js

I suppose it would be more common for the component to be in a
subdirectory, eg

  http://example.com/index.html
  http://example.com/foo/theFoo.html
  http://example.com/foo/b.js

so the import would be

import {b} from "./foo/b";

I think we could also imagine that such an import declaration could be used
without the HTML Import declaration. The fetch() call will ask for
"/foo/b.js" and the server will say "hey that's in an HMTL Import"
and serve text/html. The fetch() hook will have to detect this and process
the HTML Import, then continue with the loading process.  This much I'm
just making up.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Changing dependencies during the load process.

[John Barton]

On Mon, Aug 18, 2014 at 2:00 PM, Ian Hickson  wrote:

> On Mon, 18 Aug 2014, John Barton wrote:
> > On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson  wrote:
> > > On Fri, 15 Aug 2014, John Barton wrote:
> > > > On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson  wrote:
> > > > > On Fri, 15 Aug 2014, John Barton wrote:
> > > > > >
> > > > > > The ES Loader does not maintain a dependency tree. It maintains
> > > > > > a table of names->modules.
> > > > >
> > > > > Maybe I'm misunderstanding the ES6 loader spec. What's the Load
> > > > > Record [[Dependencies]] list?
> > > >
> > > > The dependencies for the Load. Once the load is complete the record
> > > > is not needed.
> > >
> > > How about if the dependencies are changed during the load? For
> > > example:
> > >
> > >
> >
> > This seems like an unfortunate design choice
>
> Can you elaborate? What would a better design be?


The current System.import + Loader mechanism.


> I'm certainly not
> married to this approach. Fundamentally, though, if the problem is how to
> mark HTML elements as "load on demand" with a dependency tree, I don't see
> many options beyond putting things in HTML attributes or elements. (I use
> scripts in the example above, but the problem applies equally to images or
> other non-script features, and the use cases for them apply even with
> scripting disabled.


The problems are not equal but rather have significant unique aspects.


> For example, marking images as "load on demand" so
> that they don't load until the user scrolls down, with some images needing
> particular style sheets that are also to not load until you scroll down to
> the relevant image.)
>

Why should I have to mark images? The page should load the images needed
for the visible area. (But I'm unsure if this is even technically feasible
since images below the fold could affect layout above the fold).



>
>
> > >
> > > ... 
> > >
> > > // at this point, the script with id=c is blocked waiting for a.js
> to
> > > // load. Let's change its dependencies:
> > > document.scripts.c.needs = 'b';
> >
> > ...which leads to exotic quirks like this.
>
> Well, the DOM is mutable. If we hook something into the DOM, we have to
> define what happens when it mutates.
>

There is no reason to make this case work great. It's much more important
to make the simple cases work well.


>
> > > // now the script needs to trigger b.js to load
> > > // a.js' load can be deprioritised (or canceled, if network is at a
> > > // premium), and no longer blocks the script from loading
> > >
> >
> > System.import already supports dynamic loading with runtime dependency
> > selection. If you have a problem with it let's discuss that before
> > redesigning it.
>
> I'm not sure I follow. Can you elaborate?


Your examples use script. I just don't think now that we should use the
same solution for HTML.  We should analyze the HTML requirements and design
a solution. If the result is similar to script then we can reuse.

If we do want to follow the pattern of the script loader, we would extract
'static' dependencies by parsing and use script for dynamic dependencies.
We would not mix them.

In parsing for static dependencies we need not start from the assumption of
extra declarations. These extra declarations added to ES6 are really about
convenient abbreviations. For example,

import {Foo} from 'src/baz/Foo';
var  foo = new Foo();

is just a much nicer syntax than

var foo = new {src/baz/Foo}.Foo();  // illegal

or whatever. But in the case of image tags we already know exactly which
image the HTML depends upon. All we have to do is not load it until we need
it to render the page. (Again I'm assuming a magical solution to the
rendering part, which is needed in any dependency loading solution).


> How would you use
> System.import() to mark e.g. an image as dependent on a style sheet when
> scripting is disabled?


Once we understand how these dependencies arise we can look for ways to
extract the dependency information and determine whether explicit
dependency declaration is needed.



> Or indeed even when scripting is enabled, how would
> you use it to mark one non-loaded script as dependent on another
> non-loaded script such that when you later ask for the former, the latter
> loads automatically?
>

import './latter';

It's a solved problem for scripts.

If you ask about images, then you will have to explain what it means for an
image to be dependent upon an image. Surely there are legitimate non-script
dependencies but we can't just treat everything like script and vice versa.

Discussing HTML dependency loading and ES dependency loading together makes
a lot of sense -- up to a point. But requiring specs and implementations to
converge does not seem good to me now.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modules and dependencies found during the load (before instantiation)

[John Barton]

On Mon, Aug 18, 2014 at 10:55 AM, Ian Hickson  wrote:

> On Wed, 13 Aug 2014, Ian Hickson wrote:
> >
> > One of the problems I'm running into when it comes to trying to
> > integrate ES6 modules with HTML and new HTML-based dependency features
> > is the way that I can't tell ES about dependencies I know about before
> > the data is actually fetched and instantiated.
>
> Another example of where we have something like this is HTML imports. The
> "fetch" hook for HTML imports needs to actually be the hook that does all
> the parsing, since HTML loads incrementally. (For HTML imports, the
> "translate" and "instantiate" hooks are essentially no-ops.) This means
> that the in-band dependencies for HTML imports are found during the
> "fetch" hook, and need to be set up right away. For example, if an HTML
> import contains a 

Re: Importing modules inside HTML imports

[John Barton]

Sounds promising, but the key use case cited by Brendan is ease-of-use so
it's important that all of this happens by default as far as Web devs are
concerned.


On Mon, Aug 18, 2014 at 11:23 AM, caridy  wrote:

> John, you can also use SPDY/HTTP2.0 PUSH to send sticky code alongside
> with the original HTML that will mimic the use of inline scripts but
> behaves like an external script. Essentially, you will have: ` src="/my-sticky-data-and-initialization-per-page.js">`, while that
> script is actually sent thru the SPDY multi-plex, which means no roundtrip
> is issued, no perf penalty, and it complies with CSP restrictions, the best
> of both worlds!
>
> /caridy
>
> On Aug 18, 2014, at 11:35 AM, John Barton  wrote:
>
>
>
>
> On Mon, Aug 18, 2014 at 8:02 AM, Anne van Kesteren 
> wrote:
>
>> On Mon, Aug 18, 2014 at 4:57 PM, John Barton 
>> wrote:
>> > So you are claiming that CSP no longer restricts inline scripts and
>> that the
>> > various online docs are incorrect?  Or only that the server  set the
>> > "unsafe-inline" value to opt out of the restriction?
>>
>> Neither. See
>> https://w3c.github.io/webappsec/specs/content-security-policy/
>> for the new nonce-source and hash-source features. (Don't read TR/,
>> it's kind of equivalent to reading the previous version of ES, but
>> worse.)
>>
>
> Excellent thanks!  Hope those new features are adopted and servers
> routinely implement the hash-source feature.
>
> jjb
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Changing dependencies during the load process.

[John Barton]

On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson  wrote:
>
>
> On Fri, 15 Aug 2014, John Barton wrote:
> > On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson  wrote:
> > > On Fri, 15 Aug 2014, John Barton wrote:
> > > >
> > > > The ES Loader does not maintain a dependency tree. It maintains a
> > > > table of names->modules.
> > >
> > > Maybe I'm misunderstanding the ES6 loader spec. What's the Load Record
> > > [[Dependencies]] list?
> >
> > The dependencies for the Load. Once the load is complete the record is
> > not needed.
>
> How about if the dependencies are changed during the load? For example:
>
>
>

This seems like an unfortunate design choice


>
> ... 
>
> // at this point, the script with id=c is blocked waiting for a.js to
> // load. Let's change its dependencies:
> document.scripts.c.needs = 'b';
>

...which leads to exotic quirks like this.


> // now the script needs to trigger b.js to load
> // a.js' load can be deprioritised (or canceled, if network is at a
> // premium), and no longer blocks the script from loading
>
>

System.import already supports dynamic loading with runtime dependency
selection. If you have a problem with it let's discuss that before
redesigning it.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Referencing modules loaded by HTML Imports.

[John Barton]

On Mon, Aug 18, 2014 at 10:43 AM, Ian Hickson  wrote:

> To avoid overly spamming the list I've coallesced my responses to various
> threads over the weekend into this one e-mail.
>

I really think this makes the discussion more difficult to follow and
certainly more difficult to participate in.


>
> > > Now, in the main page, you reference the HTML import:
> > >
> > >
> > >
> > > Now how would you refer to the modules? We can't have #b refer to it,
> > > since the scope of IDs is per-document, and the import has a separate
> > > document.
> >
> > Separate document implies separate JS global: each needs its own Loader.
> > So the rest of the questions aren't needed.
>
> HTML imports definitely need to expose modules across documents. Are you
> saying this requires changes to ES6 to support? What changes would we need?
>

You need to give more details about such requirements. What is the runtime
relationship between Imports and other documents? I assume the Import is
providing some state that ends up in the importer but then you are saying
these are different documents.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[John Barton]

On Mon, Aug 18, 2014 at 8:02 AM, Anne van Kesteren  wrote:

> On Mon, Aug 18, 2014 at 4:57 PM, John Barton 
> wrote:
> > So you are claiming that CSP no longer restricts inline scripts and that
> the
> > various online docs are incorrect?  Or only that the server  set the
> > "unsafe-inline" value to opt out of the restriction?
>
> Neither. See
> https://w3c.github.io/webappsec/specs/content-security-policy/
> for the new nonce-source and hash-source features. (Don't read TR/,
> it's kind of equivalent to reading the previous version of ES, but
> worse.)
>

Excellent thanks!  Hope those new features are adopted and servers
routinely implement the hash-source feature.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[John Barton]

On Mon, Aug 18, 2014 at 12:57 AM, Anne van Kesteren 
wrote:

> On Sun, Aug 17, 2014 at 8:52 PM, John Barton 
> wrote:
> > The argument goes like this: we all want secure Web pages, we can't
> secure
> > Web pages that allow inline scripts, therefore we have to ban inline
> > scripts.
> >
> > If the argument is wrong, ignore my advice, CSP will die.  I personally
> > think that would be great.
>
> It seems you did not read what I wrote. CSP does support inline
> scripts these days.
>

So you are claiming that CSP no longer restricts inline scripts and that
the various online docs are incorrect?  Or only that the server  set the
"unsafe-inline" value to opt out of the restriction?

Some of the sites that make me think this has not changed:

http://www.w3.org/TR/CSP/
In either case, authors should not include 'unsafe-inline' in their CSP
policies if they wish to protect themselves against XSS.

https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives
*Note:* Both 'unsafe-inline' and 'unsafe-eval' are unsafe and can open your
web site up to cross-site scripting vulnerabilities.

http://content-security-policy.com/

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[John Barton]

On Sun, Aug 17, 2014 at 11:14 AM, Rick Waldron 
wrote:

>
>
> On Sunday, August 17, 2014, John Barton  wrote:
>
>>
>>
>>
>> On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich 
>> wrote:
>>
>>> John Barton wrote:
>>>
>>>  On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich >>> <mailto:bren...@mozilla.org>> wrote:
>>>>
>>>> Yes -- inline scripts, like document.write, the drive-in, disco,
>>>> and Fortran, will never die.
>>>>
>>>>
>>>> More things I don't suggest investing effort in.
>>>>
>>>
>>> Seriously, inline scripts were and are important, both for avoiding
>>> extra requests (even with HTTP++ these cost) and, more important, for
>>> easiest and smoothest beginner/first-script on ramp.
>>>
>>> I have no idea why anyone would seriously contend otherwise. Latency
>>> still matters; tools didn't replace hand-authoring. These are not
>>> subjective matters.
>>
>>
>> I agree, but the forces behind CSP control the servers.  You'll have to
>> convince them.
>>
>
> Forgive me, but I don't follow this—could you elaborate? It would be
> appreciated.
>

The argument goes like this: we all want secure Web pages, we can't secure
Web pages that allow inline scripts, therefore we have to ban inline
scripts.

If the argument is wrong, ignore my advice, CSP will die.  I personally
think that would be great.

If the argument is correct, then people who run servers and thus are liable
for security failures will have to choose between security and "easiest and
smoothest beginner/first-script on ramp". In my opinion, security will win
this contest every time.  Server operators are under a lot of pressure to
improve security so they are likely to adopt CSP requirements.

Of course I could be wrong, that's the thing about advice.

HTH,
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[John Barton]

On Sun, Aug 17, 2014 at 10:08 AM, Brendan Eich  wrote:

> John Barton wrote:
>
>  On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich > <mailto:bren...@mozilla.org>> wrote:
>>
>> Yes -- inline scripts, like document.write, the drive-in, disco,
>> and Fortran, will never die.
>>
>>
>> More things I don't suggest investing effort in.
>>
>
> Seriously, inline scripts were and are important, both for avoiding extra
> requests (even with HTTP++ these cost) and, more important, for easiest and
> smoothest beginner/first-script on ramp.
>
> I have no idea why anyone would seriously contend otherwise. Latency still
> matters; tools didn't replace hand-authoring. These are not subjective
> matters.


I agree, but the forces behind CSP control the servers.  You'll have to
convince them.


>
>
> /be
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[John Barton]

On Sat, Aug 16, 2014 at 10:22 AM, Brendan Eich  wrote:

> Yes -- inline scripts, like document.write, the drive-in, disco, and
> Fortran, will never die.


More things I don't suggest investing effort in.


>
>
> /be
>
>
> Anne van Kesteren wrote:
>
>> On Sat, Aug 16, 2014 at 2:46 AM, John Barton
>> wrote:
>>
>>> >  As we noted in another thread, Web devs no longer control servers. And
>>> >  servers no longer allow inline script (for the most part going
>>> forward). So
>>> >  I don't see this feature as worth investing effort in. (I don't like
>>> it
>>> >  either, but it is what it is).
>>>
>>
>> That doesn't ring true. CSP didn't, but does now based on feedback
>> that not having inline scripts was too painful. I very much doubt they
>> will go away anytime soon.
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Importing modules inside HTML imports

[John Barton]

On Fri, Aug 15, 2014 at 3:06 PM, Ian Hickson  wrote:

>
> Suppose you have an HTML import foo.html that declares two modules:
>
> ... 
> ... 
>

As we noted in another thread, Web devs no longer control servers. And
servers no longer allow inline script (for the most part going forward). So
I don't see this feature as worth investing effort in. (I don't like it
either, but it is what it is).


>
> How should they refer to each other? For example, if module id=b wants to
> import module id=a? I suppose the logical way is like this:
>
>import "#a";
>

import './a';


>
> Now, in the main page, you reference the HTML import:
>
>
>
> Now how would you refer to the modules? We can't have #b refer to it,
> since the scope of IDs is per-document, and the import has a separate
> document.


Separate document implies separate JS global: each needs its own Loader. So
the rest of the questions aren't needed.



> The logical way to do it would be:
>
>import "foo.html#a";
>
> ...but that means that "#a" and "foo.html#a" should resolve to the same
> canonical string in the "normalize" hook. Presumably then, that's the full
> absolute URL? And we look up the document in the import list? But what if
> the import hasn't been instantiated yet? Should "normalize" just wait
> until it has been? (Otherwise, the module registry won't have the module
> and so "locate" will be called and "locate" won't have any idea what to do
> with that URL.)
>
> None of this is very compelling. Is there some expected way to do this
> that I haven't thought of?
>
> (Similar questions apply to referencing other things in imports, e.g.
> style sheets, images, etc.)
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Changing dependencies

[John Barton]

On Fri, Aug 15, 2014 at 3:41 PM, Ian Hickson  wrote:

> On Fri, 15 Aug 2014, John Barton wrote:
> >
> > The ES Loader does not maintain a dependency tree. It maintains a table
> of
> > names->modules.
>
> Maybe I'm misunderstanding the ES6 loader spec. What's the Load Record
> [[Dependencies]] list?
>

The dependencies for the Load. Once the load is complete the record is not
needed.

To be sure this is based on my old implementation experience. But as you
say the modules are static so the dependency info is not useful after the
load.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Changing dependencies

[John Barton]

The ES Loader does not maintain a dependency tree. It maintains a table of
names->modules. So when the @import rules mutate, just load the new names.
 Any new modules will be traversed for dependents and new name->modules
entries will be created. Well, assuming you figure out how to integrate CSS
parsing for dependents.

jjb


On Fri, Aug 15, 2014 at 3:24 PM, Ian Hickson  wrote:

>
> ES6 modules are immutable, but some things on the Web platform that might
> have dependencies can have those dependencies change over time. For
> example, CSS style sheets have a mutable object model, and one of the
> things in that object model is their list of @imports, so you can
> dynamically change a style sheet's dependencies.
>
> Assuming we are implementing all CSS loads through the ES6 module loader
> system, what's the appropriate way in which I should spec reactions to
> changes to a CSS object's @import rules?
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modules and dependencies known before the load

[John Barton]

On Fri, Aug 15, 2014 at 2:43 PM, Ian Hickson  wrote:

> On Fri, 15 Aug 2014, John Barton wrote:
> > On Fri, Aug 15, 2014 at 9:43 AM, Ian Hickson  wrote:
> > > On Thu, 14 Aug 2014, John Barton wrote:
> > > >
> > > > But since the only way the client can know that it needs a.js and
> > > > jquery.js is if the server tells it [...]
> > >
> > > There's at least four ways this can happen:
> > >
> > >  - the server tells the browser that it needs file a.js when the
> server is
> > >sending index.html, then tells the browser that it needs query.js
> when
> > >it is sending a.js, and the server doesn't preemptively send
> anything.
> > >
> > >  - the server sends the browser all three files at once, preemptively.
> > >
> > >  - the server tells the browser that it needs file a.js when sending
> > >index.html, then when a.js is requested, it preemptively sends
> > >jquery.js at the same time as telling the browser that it'l need it.
> > >
> > >  - the server tells the browser that it needs files a.js and jquery.js
> at
> > >the same time as when it is sending index.html, and the server
> doesn't
> > >preemptively send anything.
> > >
> > > The first is too slow, since it requires one RTT per file. It's what we
> > > have now, and what ES6 modules describe in the absence of server
> support.
> > >
> > > The second is too slow, because it implies sending resources that
> aren't
> > > needed, possibly using up bandwidth that could be used for other
> purposes.
> > > It's something that can be supported by packaging and other solutions
> > > already being developed, if people want it.
> >
> > The second method is faster than your method. It results in the same
> > three file transfer in one less round trip.
> >
> > The second method does not imply sending any more or less resources than
> > any other method listed.
>
> The second is too slow because there's lots of other files involved in
> practice, for example the default style sheet, the scripts that are needed
> straight away, the Web components that are needed straight away, all the
> default images, etc. The whole point of the discussion in this thread is
> that we're talking about files that are not needed straight away, and how
> to obtain them promptly once they are needed.
>

Loading all of the files in a web page in the order they are needed is
great goal and one that I think would make a great improvement in the Web.

It is certainly true that data for pages is "chunky": we need a mechanism
for loading a group of related files at the right time.

Within each chunk we need all of the files if we need the root of the
chunk. But that is exactly the ES6 case: if we need the root of the
dependency tree, then we need all of the tree, that is the declarative
design.

Having a design where the browser gets all the names, sends all the names
back to the server, and gets the tree is just wasting a trip. Simply send
the tree when the browser asks for the tree.

That's why in my opinion 'bundles' or 'packages' make sense: they combine
the related dependencies and allow them to be loaded in one trip.

Divide this problem in to small pieces: ES6 bundles, HTML Imports, and some
bundle/package loading solution.  Don't use the same fine-grained solution
for all layers.


>
>
> > > The second and third require server-side support beyond what many
> > > authors will be able to do. HTTP2 can provide this if people want it,
> > > I believe.
> > >
> > > The fourth is what I'm looking at.
> > >
> > > The fourth consists of the server having no built-in knowledge except
> > > what is in-band in the HTML file, namely, predeclared dependency
> > > trees.
> >
> > By humans writing markup? That's not happening, at least not for more
> > than trivial programs.
>
> It turns out that on the Web, there are lots of "trivial" programs. When
> you have trillions of Web pages, even the smallest of fractions ends up
> being significant numbers of pages.
>

Such programs don't need the kind of features we are discussing.


>
>
> > No one is going to write hundreds of lines of dependency declaration
> > already specified in their JS files.
>
> Maybe not hundreds, but maybe dozens. Also, not all these dependencies are
> written in their JS files. Also, it turns out that people will do lots of
> things to make their pages quicker, and it's a lot easier, in many case

Re: Modules and dependencies known before the load

[John Barton]

On Fri, Aug 15, 2014 at 9:43 AM, Ian Hickson  wrote:

> On Thu, 14 Aug 2014, John Barton wrote:
> >
> > But since the only way the client can know that it needs a.js and
> > jquery.js is if the server tells it [...]
>
> There's at least four ways this can happen:
>
>  - the server tells the browser that it needs file a.js when the server is
>sending index.html, then tells the browser that it needs query.js when
>it is sending a.js, and the server doesn't preemptively send anything.
>
>  - the server sends the browser all three files at once, preemptively.
>
>  - the server tells the browser that it needs file a.js when sending
>index.html, then when a.js is requested, it preemptively sends
>jquery.js at the same time as telling the browser that it'l need it.
>
>  - the server tells the browser that it needs files a.js and jquery.js at
>the same time as when it is sending index.html, and the server doesn't
>preemptively send anything.
>
> The first is too slow, since it requires one RTT per file. It's what we
> have now, and what ES6 modules describe in the absence of server support.
>
> The second is too slow, because it implies sending resources that aren't
> needed, possibly using up bandwidth that could be used for other purposes.
> It's something that can be supported by packaging and other solutions
> already being developed, if people want it.
>

The second method is faster than your method. It results in the same three
file transfer in one less round trip.

The second method does not imply sending any more or less resources than
any other method listed.


>
> The second and third require server-side support beyond what many authors
> will be able to do. HTTP2 can provide this if people want it, I believe.
>
> The fourth is what I'm looking at.
>
> The fourth consists of the server having no built-in knowledge except
> what is in-band in the HTML file, namely, predeclared dependency trees.
>

By humans writing markup? That's not happening, at least not for more than
trivial programs. No one is going to write hundreds of lines of dependency
declaration already specified in their JS files.

And if you allow a tool running on the server (eg a build) then its the
same as bundling with an extra unnecessary round trip.

> ...
>
> > If you meant "suppose we had magic file on the server which listed
> > dependencies and a Loader that read that file, then we can succeed by
> > building the magic file and don't need server code changes".
>
> Well, the file wouldn't be magic. It'd just be a predeclared dependencies
> in the HTML file, something that authors have long asked for, at least on
> the WHATWG list.
>

You mean devs re-writing the same declarations they used in JS in HTML? Do
these authors write modular JS? I am very skeptical.


>
>
> > That's what "bundling" does: builds a magic file and ships all of the
> > required modules in dependency order to the server. It even skips the
> > step where the list it built and just sends the all the dependencies.
> >
> > Could we have better tools that allowed finer grained control over the
> > bundle size vs trips? Sure.
>
> Ok, great. That's all I'm asking for. Actually I'm asking for less than
> that, I'm asking if the ES6 module system could be slightly adjusted so
> that this finer-grained control could be implemented on top of it without
> duplicating the dependency management (which is what you have to do now
> if you manually call LoadModule() on the dependencies early).
>

You can specify dependencies in `instantiate()` returns.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modules and dependencies known before the load

[John Barton]

On Thu, Aug 14, 2014 at 2:20 PM, Ian Hickson  wrote:

> On Wed, 13 Aug 2014, John Barton wrote:
> > On Wed, Aug 13, 2014 at 3:52 PM, Ian Hickson  wrote:
> > > On Wed, 13 Aug 2014, John Barton wrote:
> > > > On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson  wrote:
> > > > >
> > > > > Suppose a page has this markup:
> > > > >
> > > > > whenneeded>
> > > > > whenneeded>
> > > > >
> > > > > import "a";
> > > > > // ...
> > > > >
> > > >
> > > > Your example will just work if you just use
> > > >
> > > >
> > > > import "a";
> > > > // ...
> > > >
> > > >
> > > > When this module is compiled the other two will be loaded and
> > > > compiled.
> > >
> > > That assumes that you have some sort of server-side support so that
> > > the server knows that when you request "a", it should send "a.js" and
> > > "jquery.js", which is an assumption that will work for some people but
> > > not [...]
> >
> > No, the loader just requests each of these when it needs them.
>
> Right. What I'm trying to do is have the loader load them _before_ it
> needs them.
>
> Without server-side support, on-demand loading looks like this:
>
>   Client   Server
> ||
>   0ms   |-_  | Client finds it needs a.js
> |  -_|
> |-_  |
> |  -_| Server sends back a.js
> | _- |
> |   _-   |
> | _- |
> 200ms   |-_  | Client finds it needs jquery.js
> |  -_|
> |-_  |
> |  -_| Server sends back jquery.js
> | _- |
> |   _-   |
> | _- |
> 400ms   |-   | Client runs the scripts
>
> ...whereas if the client is aware of the dependencies early, it can do:
>
>   Client   Server
> ||
>   0ms   |-_  | Client finds it needs a.js and jquery.js
> |  -_|
> |-_  |
> |  -_| Server sends back a.js and jquery.js
> | _- |
> |   _-   |
> | _- |
> 200ms   |-   | Client runs the scripts
>
> ...which is a lot faster.
>

But since the only way the client can know that it needs a.js and jquery.js
is if the server tells it, then:

  Client   Server sends  a.js and jquery.js
||
  0ms   |-_  | Client finds it has a.js and jquery.js
 0ms   |-   | Client runs the scripts

which is even faster.


>
> > > everyone. One of the big pieces of feedback I am dealing with on the
> > > HTML side is a request for a way to predeclare the dependency graph to
> > > avoid this problem (so that the browser knows to request a.js and
> > > jquery.js at
> >
> > Actually I guess you mean "avoid multi-pass requests for the entire
> > dependency graph".
>
> I'm not sure what that means. But if that means the same thing, then sure.
>

Yes, your example just happens to be one layer deep and thus requires just
one extra trip.


> The key is just that the client can request all the files it's going to
> need at one time, so that, even without server support, the client doesn't
> wait more than one total RTT.
>

Wait, you claimed earlier that without server support it's extra round
trips. Now without server support it's no extra round trips.  Which one ;-)

If you meant "suppose we had magic file on the server which listed
dependencies and a Loader that read that file, then we can succeed by
building the magic file and don't need server code changes".

That's what "bundling" does: builds a magic file and ships all of the
required modules in dependency order to the server. It even skips the step
where the list it built and just sends the all the dependencies.

Could we have better tools that allowed finer grained control over the
bundle size vs trips? Sure.


>
>
> > > (If you don't have either server-side support or client-side
> > > dependency predeclaration, you end up having to discover the
> > > dependency chart at runtime, which is a huge latency loss.)
> >
> > Well, as they said back when I worked on a dairy, "you've step in it".
> >
> > This issue is at the root of the split between commonjs (modules for
> > node, synchronous loading) and requirejs (modules for browser, prebuilt
> > into bundles to avoid latency). The ES module system atte

Re: Modules and dependencies known before the load

[John Barton]

On Wed, Aug 13, 2014 at 3:52 PM, Ian Hickson  wrote:

> On Wed, 13 Aug 2014, John Barton wrote:
> > On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson  wrote:
> > >
> > > Suppose a page has this markup:
> > >
> > >
> > > whenneeded>
> > >
> > > import "a";
> > > // ...
> > >
> >
> > Your example will just work if you just use
> >
> >
> > import "a";
> > // ...
> >
> >
> > When this module is compiled the other two will be loaded and compiled.
>
> That assumes that you have some sort of server-side support so that the
> server knows that when you request "a", it should send "a.js" and
> "jquery.js", which is an assumption that will work for some people but not
>

No, the loader just requests each of these when it needs them.


> everyone. One of the big pieces of feedback I am dealing with on the HTML
> side is a request for a way to predeclare the dependency graph to avoid
> this problem (so that the browser knows to request a.js and jquery.js at
>

Actually I guess you mean "avoid multi-pass requests for the entire
dependency graph".


> the same time). People apparently have huge difficulties even getting
> their servers configured to send the right MIME types, let alone getting
> the servers to know about dependencies.
>

Yup.


>
> (If you don't have either server-side support or client-side dependency
> predeclaration, you end up having to discover the dependency chart at
> runtime, which is a huge latency loss.)
>

Well, as they said back when I worked on a dairy, "you've step in it".

This issue is at the root of the split between commonjs (modules for node,
synchronous loading) and requirejs (modules for browser, prebuilt into
bundles to avoid latency). The ES module system attempts to solve this by
providing an asynchronous API (eg System.import()) and a proposal, to
support server side dependency bundling in HTTP++.

The workaround we have now is to pre-build bundles and use the locate()
function to map module ids into bundles.  That is basically the requirejs
solution (with a much better programmer API).  I predict node will extend
their System to include a synchronous API. Then the circle will be complete.

To be sure this is a difficult or even fundamental problem. I respect all
efforts to solve this problem; don't believe anyone who says the solution
is simple.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Modules and dependencies known before the load

[John Barton]

Your example will just work if you just use
   
import "a";
// ...
   
When this module is compiled the other two will be loaded and compiled.
jjb


On Wed, Aug 13, 2014 at 2:59 PM, Ian Hickson  wrote:

>
> One of the problems I'm running into when it comes to trying to integrate
> ES6 modules with HTML and new HTML-based dependency features is the way
> that I can't tell ES about dependencies I know about before the data is
> actually fetched and instantiated. The problem can essentially be
> summarised by this line from the definition of ProcessLoadDependencies():
>
> # The ProcessLoadDependencies abstract operation is called after one
> # module has nearly finished loading. It starts new loads as needed to
> # load the module's dependencies.
>
> Suppose a page has this markup:
>
>
>
>
> import "a";
> // ...
>
>
> ...where "uses" is some hypothetical markup for telling the browser about
> dependencies ahead of time (the assumption being that anims.js contains
> a line like 'import "jquery";'), and where "whenneeded" is some attribute
> that tells the browser to not bother starting the whole loading process
> until the resource is needed.
>
> In this example, the first two 

Re: Understanding the 'normalize' Loader hook

[John Barton]

On Tue, Aug 12, 2014 at 3:26 PM, Ian Hickson  wrote:

> On Tue, 12 Aug 2014, John Barton wrote:...
> > > (only if the last segment is part of the "path" part of the URL and
> > > doesn't contain a "."?).
> >
> > No such restriction is applied in our code.
>
> Sure. What do we want for the default Web loader though?
>

Be consistent with URLs.which.allow.dots


>
>
> > > Is that more or less right? (There's also the loader.paths stuff. Why
> > > is that in "locate" rather than "normalize"?)
> >
> > Because the paths processing can produce arbitrary addresses (to cache,
> > CDN, I guess)
>
> Sure but presumably if someone explicitly puts in the long URL, they still
> don't want it to cause a second load, right?
>
> I mean, if you do:
>
>loader.paths = {
>  'foo': 'scripts/foo',
>};
>
>// in a different module
>
>import "foo";
>
>// in a different module
>
>import "scripts/foo";
>
> ...surely you want just one module loaded. No?
>

One module, but my point was more that the right hand side can be an
absolute path.


>
> Come to think of it, maybe you actually just want one loaded even if
> someone does:
>
>import "scripts/foo.js";
>

In my opinion this should be an error. Either we have .js or we don't, not
half-baked.


>
> ...or even:
>
>// assuming the base URL the whole time has been
>// http://www.example.com/
>import "http://www.example.com/scripts/foo.js";;
>

Also an error.


>
> Is there any time we'd want all those imports to result in separate module
> loads?
>

FWIW, most of the time I expect to write relative paths in imports:
  import "./foo/bar";

If I see
  import "foo/bar";
I expect foo to be remapped to a package.

Or to put it another way, we need a story for packages.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Understanding the 'normalize' Loader hook

[John Barton]

On Tue, Aug 12, 2014 at 2:45 PM, Ian Hickson  wrote:

> On Tue, 12 Aug 2014, John Barton wrote:
> >
> > See the implemention in es6-module-loader:
> >
> https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/system.js#L117
>
> Ah, fascinating. So basically:
>
>  - "normalize" does relative URL logic based on the current base URL and
>the referrer (i.e. the URL of the script doing the importing).
>

I would expect that normalized names to be platform independent.


>
>  - "locate" resolves that URL and adds ".js"


This step is platform dependent, it produces an address from a name.


> (only if the last segment
>is part of the "path" part of the URL and doesn't contain a "."?).
>

No such restriction is applied in our code.


>
> Is that more or less right? (There's also the loader.paths stuff. Why is
> that in "locate" rather than "normalize"?)
>

Because the paths processing can produce arbitrary addresses (to cache,
CDN, I guess)


>
> (BTW, I noticed that both in that code above and in the spec, "referrer"
> is consistently misspelt as "referer", the HTTP way.)
>

I've already reported this bug.


>
> I'm exploring some ways that the module system could be extended on the
> Web platform.


 You might look at Guy Bedford's experiment on loader plugins
https://github.com/systemjs/systemjs
 that follow the path laid down by Jame Burke in requirejs
http://requirejs.org/docs/api.html#plugins

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Understanding the 'normalize' Loader hook

[John Barton]

See the implemention in es6-module-loader:
https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/system.js#L117

In traceur we have different code that passes the same tests.

The tests:
https://github.com/google/traceur-compiler/blob/master/test/unit/runtime/System.js

We would map your examples to:

On Tue, Aug 12, 2014 at 2:05 PM, Ian Hickson  wrote:

>
> Assume my script is http://example.com/test.js, and assume that there is
> no extra information (nobody has registered any module names or anything
> like that). If I do:
>
>import "a";
>
 http://example.com/a.js

>import "./a";
>
  http://example.com/a.js

>import "/a";
>
 /a.js

>import "//example.com/a";
>
http://example.com/a.js
>
>import "http://example.com/a";
>
http://example.com/a.js
>
>
> ...am I supposed to end up with the same normalized name for all five?
>
> How many entries in [[Modules]] should this result in?
>
> (I understand that the answer depends on the default loader; what I'm
> asking is, what should the default loader's behaviour be.)
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader vs ES6 Classes

[John Barton]

Related issue that had come up in discussions I've had off this list: is it
likely that the spec will constrain the constructor arguments of custom
Loader classes to match the arguments of Reflect.Loader?

For my part I was surprised that this might be a possibility.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader vs ES6 Classes

[John Barton]

f you read the Loader source carefully you can see that Jason fixed the
Loader to support inheritance. But his fix does not allow classes to
inherit the platform's loading behavior.  That behavior is given in options
properties passed to instances. By defining the system loader as an
instance of a SystemLoader extending Loader, the platform behavior would be
extendable and the Loader would be ES6 not merely class-friendly.


On Mon, Aug 4, 2014 at 6:40 PM, Kevin Smith  wrote:

>
>> On Mon, Aug 4, 2014 at 6:33 PM, Kevin Smith  wrote:
>>
>>> If I understand correctly, John was wanting to use a state-carrying
>>> options as the options argument when specifying hook overrides.
>>>
>>
>> What part of this has anything to do with ES6 classes?
>>
>
> As far as I can tell, nothing.  Looks like good work was done to make
> Loader class-friendly.
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader vs ES6 Classes

[John Barton]

The System object is global, so "depends" is the answer to all such
questions.


On Mon, Aug 4, 2014 at 2:24 PM, Calvin Metcalf 
wrote:

> Would the System object for a module loaded with a sub classed System be
> the sub classed one or the original one?
> IMO a better design would have each platform subclass Loader, eg
> SystemLoader extends Loader and System (or 'system' if we decide to
> suddenly come to our senses) would be an instance of SystemLoader.
> SystemLoader would define the hook functions and custom Loader classes
> would extend SystemLoader to add features.  Custom loaders probably don't
> want to re-implement the hooks so much as augment them. The SystemLoader
> would support this naturally.
>
>
>
>
> On Mon, Aug 4, 2014 at 12:52 PM, Guy Bedford  wrote:
>
>> I suppose the point is whether System can be subclassed itself, since
>> that is usually the starting point for a new loader as it is common
>> to share the base environment normalization, locate and fetch functions.
>>
>> Currently, if System is set via the options hooks this isn't possible.
>>
>> Note also that things like baseURL and the mapping table being created
>> through the constructor would also make sharing these easier.
>>
>> If System were defined to be based on a class found at System.constructor
>> like this, things get a lot easier for that starting point.
>>
>>
>> On Monday, August 4, 2014, Jason Orendorff 
>> wrote:
>>
>>> On Sun, Aug 3, 2014 at 2:31 PM, Kevin Smith 
>>> wrote:
>>> > I've often wondered why we aren't using inheritance to customize
>>> Loaders.
>>> > I'd be interested in the rationale.
>>>
>>> When I was working on Loaders, I modified the design so that inheritance
>>> works.
>>>
>>> That is, you can just subclass Loader and declare the methods you want
>>> to override, and the Loader will call those methods. It all works, as
>>> far as I can tell.
>>>
>>> I don't remember why we kept the options argument after that. I'm in
>>> favor of dropping it.
>>>
>>> -j
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader vs ES6 Classes

[John Barton]

On Mon, Aug 4, 2014 at 1:50 PM, Jason Orendorff 
wrote:
>
> The design as it stands doesn't specify the system loader or its
> class. It's a platform-specific detail.
>

Yes, but ES should say a couple of things to get everyone on the same page,
eg that the system loader instance will have the interface and semantics of
Loader and be available on Reflect.global (or whatever).

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader vs ES6 Classes

[John Barton]

IMO a better design would have each platform subclass Loader, eg
SystemLoader extends Loader and System (or 'system' if we decide to
suddenly come to our senses) would be an instance of SystemLoader.
SystemLoader would define the hook functions and custom Loader classes
would extend SystemLoader to add features.  Custom loaders probably don't
want to re-implement the hooks so much as augment them. The SystemLoader
would support this naturally.




On Mon, Aug 4, 2014 at 12:52 PM, Guy Bedford  wrote:

> I suppose the point is whether System can be subclassed itself, since that
> is usually the starting point for a new loader as it is common to share the
> base environment normalization, locate and fetch functions.
>
> Currently, if System is set via the options hooks this isn't possible.
>
> Note also that things like baseURL and the mapping table being created
> through the constructor would also make sharing these easier.
>
> If System were defined to be based on a class found at System.constructor
> like this, things get a lot easier for that starting point.
>
>
> On Monday, August 4, 2014, Jason Orendorff 
> wrote:
>
>> On Sun, Aug 3, 2014 at 2:31 PM, Kevin Smith  wrote:
>> > I've often wondered why we aren't using inheritance to customize
>> Loaders.
>> > I'd be interested in the rationale.
>>
>> When I was working on Loaders, I modified the design so that inheritance
>> works.
>>
>> That is, you can just subclass Loader and declare the methods you want
>> to override, and the Loader will call those methods. It all works, as
>> far as I can tell.
>>
>> I don't remember why we kept the options argument after that. I'm in
>> favor of dropping it.
>>
>> -j
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader vs ES6 Classes

[John Barton]

Neither example binds 'this' assuming the current Loader implementation, so
no object state.  Although maybe you are saying your example ought to work,
then we agree ;-)


On Mon, Aug 4, 2014 at 7:47 AM, Axel Rauschmayer  wrote:

> On Aug 4, 2014, at 16:33 , John Barton  wrote:
>
> As far as I can tell you are basically arguing that simple Loader hooks
> don't need object state. Of course that is true.
>
>
> No, I’m arguing that Juan’s code is basically “subclassing” a loader,
> overriding a method and calling that method. ES6 classes seem like a more
> elegant way of doing this. You’d get as much object state in the subclass
> as you want.
>
> And sure we can write code that carefully and cleverly avoids using
> 'this'. Why? ES6 added classes because this is often the clearest way to
> structure more complex systems.
>
> In my case the LoaderHooks.normalize() function needs to mark names as
> originating from 'script' rather than 'module' based on the name (eg
> 'script:' or in my case trailing ',script'.  The marking table needs to be
> on 'this'.
>
> I extend LoaderHooks to InterceptOuputLoaderHooks which calls
> this.onTranscoded() to copy the transcoded results from load to listeners.
>  But my real point is why should I have to think about 'this' binding in
> 2015?
>
> We don't need to use an old school API now, we have ES6.
>
> jjb
>
> On Mon, Aug 4, 2014 at 6:29 AM, Axel Rauschmayer  wrote:
>
>> On Aug 4, 2014, at 15:16 , Juan Ignacio Dopazo 
>> wrote:
>>
>> In practice we've found that we rarely use the "new Loader(hooks)` option
>> and instead this is more common:
>>
>> var loader = new Loader();
>> var loaderFetch = loader.fetch.bind(loader);
>>
>> loader.fetch = function (loadRecord) {
>>   // do something
>>   return loaderFetch(loadRecord);
>> };
>>
>>
>>
>> Why not like this then? You’d need (a compiler for) ES6, though.
>>
>> ```js
>> class MyLoader extends Loader {
>> fetch(loadRecord) {
>> // do something
>> return super(loadRecord);
>> }
>> }
>> let loader = new MyLoader();
>> ```
>>
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader vs ES6 Classes

[John Barton]

As far as I can tell you are basically arguing that simple Loader hooks
don't need object state. Of course that is true.

And sure we can write code that carefully and cleverly avoids using 'this'.
Why? ES6 added classes because this is often the clearest way to structure
more complex systems.

In my case the LoaderHooks.normalize() function needs to mark names as
originating from 'script' rather than 'module' based on the name (eg
'script:' or in my case trailing ',script'.  The marking table needs to be
on 'this'.

I extend LoaderHooks to InterceptOuputLoaderHooks which calls
this.onTranscoded() to copy the transcoded results from load to listeners.
 But my real point is why should I have to think about 'this' binding in
2015?

We don't need to use an old school API now, we have ES6.

jjb



On Mon, Aug 4, 2014 at 6:29 AM, Axel Rauschmayer  wrote:

> On Aug 4, 2014, at 15:16 , Juan Ignacio Dopazo 
> wrote:
>
> In practice we've found that we rarely use the "new Loader(hooks)` option
> and instead this is more common:
>
> var loader = new Loader();
> var loaderFetch = loader.fetch.bind(loader);
>
> loader.fetch = function (loadRecord) {
>   // do something
>   return loaderFetch(loadRecord);
> };
>
>
>
> Why not like this then? You’d need (a compiler for) ES6, though.
>
> ```js
> class MyLoader extends Loader {
> fetch(loadRecord) {
> // do something
> return super(loadRecord);
> }
> }
> let loader = new MyLoader();
> ```
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Loader vs ES6 Classes

[John Barton]

Since I guess not too many developers work with ES6 and the Loader object,
here is some feedback: the Loader callback design does not play well with
ES6 classes.

The Loader takes 'options', an object with function properties like
normalize, locate, and fetch. If you pass a literal object with function
properties, it works fine.

If you pass an instance of a class, then you discover that the Loader calls
these functions with 'this' bound to the Loader, not the 'options' object.

There isn't a simple way around this as far as I know. The options
functions don't have access to the options object, only module-state and
global. So you're stuck with the awkward:
   var loader = new Loader({
  normalize: options.normalize.bind(options),
  locate: options.locate.bind(locate),
  etc,
   };
I guess you can give up on ES6 inheritance and create the hook instances by
old-school JS, but that is even more annoying.  Or maybe there is something
else I've not thought of?

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader locate/fetch/translate/instantiate API

[John Barton]

The spec seems inconsistent about the metadata property. The define()
function of Loader accepts options.metadata:
---
26.3.3.2Reflect.Loader.prototype.define ( name, source [ , options ] )

...

8. Let metadata be GetOption(options, "metadata").
9. ReturnIfAbrupt(metadata).
10. If metadata is undefined then let metadata be
ObjectCreate(%ObjectPrototype%).
---
But the import() function does not:
Reflect.Loader.prototype.import ( name [ , options ]
...
4. Let p be the result of calling LoadModule(loaderRecord, name, options).
...
15.2.4.1LoadModule(loader, name, options) Abstract Operation
...
8 Let metadata be ObjectCreate(%ObjectPrototype%).


That means I can pass .metadata to define() but not import(). I think the
metadata should be passed on both.

jjb


On Wed, Jul 30, 2014 at 7:20 AM, Juan Ignacio Dopazo 
wrote:

> I don't have an answer, but the "metadata" property of the loadRecord
> object was designed to be the place where you put your own custom metadata
> so that it's persisted across hooks. And it works in es6-module-loader:
> http://jsbin.com/kutey/2/edit?js,output.
>
> Juan
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader locate/fetch/translate/instantiate API

[John Barton]

Ok thanks, I see that this was added and I did not notice. (I think this
kind of creeping overspecification annoying but inevitable I suppose).

jjb


On Wed, Jul 30, 2014 at 7:20 AM, Juan Ignacio Dopazo 
wrote:

> I don't have an answer, but the "metadata" property of the loadRecord
> object was designed to be the place where you put your own custom metadata
> so that it's persisted across hooks. And it works in es6-module-loader:
> http://jsbin.com/kutey/2/edit?js,output.
>
> Juan
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Loader locate/fetch/translate/instantiate API

[John Barton]

The Loader hook callbacks all have an API defined like:

  Reflect.Loader.prototype.locate ( loadRequest )

My interpretation of this description was that the callback provider should
expect the same loadRequest object in to reappear during the load pipeline
and furthermore, this being JavaScript, I could add any properties I need
to this object as long as they don't collide with the documented properties
used by the Loader.

es6-module-loader interpreters the spec to mean each loadRequest parameter
is bound to a new object with only the documented properties provided.

Which interpretation we can count on?

Thanks,
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Quantifying Default Exports

[John Barton]

There are two issues here:
  1) Is 'default' essential?
  2) Should the spec. explicitly define commonjs loading?

Brian is claiming 1) no and 2) no.  More important for me: does 2) require
1). Evidently not.

jjb


On Mon, Jul 21, 2014 at 1:34 PM, Brian Di Palma  wrote:

> It doesn't seem an issue that requires the ES6 module spec to have
> something like default imports though.
>
> The compiler could output
>
> `
> newModule({
>   default: require('minimist')
> })
> `
>
> and importers could do
>
> `import {default as minimist} from 'minimist';`
>
> Or you could have
>
> `
> newModule({
>   minimist: require('minimist');
> })
> `
>
> and
>
> `import {minimist} from 'minimist';`
>
> depending on how the compiler is configured/written.
>
> This is implementation detail of compilers and loaders of legacy
> systems as opposed to spec concerns.
>
> On Mon, Jul 21, 2014 at 6:50 PM, Guy Bedford  wrote:
> > Yes this is a bug that can be fixed at the compiler level. As you say we
> can
> > generate a wrapper when loading a non-ES6 module in ES6:
> >
> > newModule({
> >   default: require('minimist')
> > })
> >
> > We then conditionally add this wrapper based on detecting if the import
> is
> > an ES6 module. This is the same method we have for AMD compilations at
> the
> > moment, which seems to have been working well.
> >
> >
> > On 21 July 2014 10:17, John Barton  wrote:
> >>
> >>
> >>
> >>
> >> On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford 
> >> wrote:
> >>>
> >>> In Brian's case we actually need default exports. This is because the
> >>> dynamic loader can't pick up the code he has written right now in ES6.
> >>>
> >>> This is how he is loading a NodeJS module in ES6:
> >>>
> >>> module minimist from 'minimist';
> >>>
> >>> In ES6 this means "give me the Module object with getters to the
> >>> exports".
> >>>
> >>> But unfortunately in Traceur this is compiling into:
> >>>
> >>> var minimist = require('minimist');
> >>>
> >>> As a result the `module` syntax can possibly return him a 'function' or
> >>> other non-Module object.
> >>
> >>
> >> You seem to be saying "The traceur implementation of 'module' fails in
> >> this case".  It seems to me that Traceur could generate code which would
> >> wrap functions in Module objects.  That is, this is not a fundamental
> limit,
> >> just an unreported bug.
> >>
> >>>
> >>> Thus we have broken the ability to parse his code in the ES6 dynamic
> >>> loader, as it is not capable of returning a non-Module object for a
> module
> >>> import, which is pretty critical.
> >>>
> >>> Thus default export properties are critical to enabling this support
> >>> path.
> >>
> >>
> >> I believe that Caridy's point is: "fine, use dynamic linking".
> >>
> >>>
> >>>
> >>>
> >>> On 21 July 2014 09:51, Caridy Patino  wrote:
> >>>>
> >>>> Interoperability should not be a decisive factor here, we have fallen
> >>>> into that trap before, the conclusion was to let Loader to handle
> those
> >>>> cases rather than trying to drive it from the perspective of the
> module
> >>>> syntax. Let's focus on what is best and what makes sense for the ES
> Modules,
> >>>> and keep the dynamic module systems out of the picture since we know
> we have
> >>>> a lot of flexibility with the loader to deal with those dynamic
> modules.
> >>>>
> >>>> /caridy
> >>>>
> >>>>
> >>>> On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma 
> >>>> wrote:
> >>>>>
> >>>>> Yep, that makes sense. Highly unlikely but still possible and could
> >>>>> cause issues.
> >>>>> No doubt you could complicate your compiler to deal with these edge
> >>>>> cases but why force that?
> >>>>>
> >>>>> Yet more problems with default imports/exports. This feature doesn't
> >>>>> seem worth its cost.
> >>>>>
> >>>>>
> >>>>

Re: Re: Quantifying Default Exports

[John Barton]

On Mon, Jul 21, 2014 at 10:06 AM, Guy Bedford  wrote:

> In Brian's case we actually need default exports. This is because the
> dynamic loader can't pick up the code he has written right now in ES6.
>
> This is how he is loading a NodeJS module in ES6:
>
> module minimist from 'minimist';
>
> In ES6 this means "give me the Module object with getters to the exports".
>
> But unfortunately in Traceur this is compiling into:
>
> var minimist = require('minimist');
>
> As a result the `module` syntax can possibly return him a 'function' or
> other non-Module object.
>

You seem to be saying "The traceur implementation of 'module' fails in this
case".  It seems to me that Traceur could generate code which would wrap
functions in Module objects.  That is, this is not a fundamental limit,
just an unreported bug.


> Thus we have broken the ability to parse his code in the ES6 dynamic
> loader, as it is not capable of returning a non-Module object for a module
> import, which is pretty critical.
>
> Thus default export properties are critical to enabling this support path.
>

I believe that Caridy's point is: "fine, use dynamic linking".


>
>
> On 21 July 2014 09:51, Caridy Patino  wrote:
>
>> Interoperability should not be a decisive factor here, we have fallen
>> into that trap before, the conclusion was to let Loader to handle those
>> cases rather than trying to drive it from the perspective of the module
>> syntax. Let's focus on what is best and what makes sense for the ES
>> Modules, and keep the dynamic module systems out of the picture since we
>> know we have a lot of flexibility with the loader to deal with those
>> dynamic modules.
>>
>> /caridy
>>
>>
>> On Mon, Jul 21, 2014 at 12:37 PM, Brian Di Palma 
>> wrote:
>>
>>> Yep, that makes sense. Highly unlikely but still possible and could
>>> cause issues.
>>> No doubt you could complicate your compiler to deal with these edge
>>> cases but why force that?
>>>
>>> Yet more problems with default imports/exports. This feature doesn't
>>> seem worth its cost.
>>>
>>>
>>> On Mon, Jul 21, 2014 at 5:21 PM, Calvin Metcalf
>>>  wrote:
>>> > (woops hit reply instead of reply all)
>>> >
>>> > Because the `function mainThing(){}` might already have a method named
>>> > helper or, more likely, the named export is something like call or
>>> bind.
>>> >
>>> >
>>> >
>>> >
>>> > On Mon, Jul 21, 2014 at 12:06 PM, Brian Di Palma 
>>> wrote:
>>> >>
>>> >> On Mon, Jul 21, 2014 at 4:16 PM, Calvin Metcalf
>>> >>  wrote:
>>> >> > I have a CommonJS module which exports a single function
>>> >> > ```js
>>> >> > //cj.js
>>> >> > module.exports = function (){}
>>> >> > ```
>>> >> >
>>> >> > If I was to transform it into an ES6 module the best way to do so
>>> >> > currently
>>> >> > it so use a default export
>>> >> >
>>> >> > ```js
>>> >> > //cj2es6.js
>>> >> > export default function () {}
>>> >> > ```
>>> >> >
>>> >> > now say I want to import those from another commonjs module,
>>> importing
>>> >> > the
>>> >> > first one is easy, but when importing the second one slightly less
>>> so,
>>> >> > how
>>> >> > should the loader treat that default export, a easy solution for
>>> this
>>> >> > case
>>> >> > is to simply have default exports act the same as a module.exports
>>> >> >
>>> >> > But then what would you do about es6 modules that use default and
>>> named
>>> >> > exports like the example at http://jsmodules.io/ which can be
>>> sumerized
>>> >> > as
>>> >> >
>>> >> > ```js
>>> >> >
>>> >> > export default function mainThing(){}
>>> >> > export function helper (){};
>>> >> >
>>> >> > , if we return a default export if it exists then there is no way to
>>> >> > access
>>> >> > the named exports.
>>> >>
>>> >> As mentioned in the GitHub issue I don't see why you couldn't compile
>>> to
>>> >>
>>> >> `
>>> >> module.export = function mainThing(){};
>>> >>
>>> >> module.export.helper = function(){};
>>> >> `
>>> >>
>>> >> Allowing access to the default and named.
>>> >>
>>> >> >
>>> >> > So in that case it would make more sense to treat default as just
>>> >> > another
>>> >> > export name.  But if we do that then that means that if we go back
>>> to
>>> >> > our
>>> >> > second example
>>> >> >
>>> >> > ```js
>>> >> > //cj2es6.js
>>> >> > export default function () {}
>>> >> > ```
>>> >> >
>>> >> > if that was to be treated that way then importing it from another
>>> >> > commonjs
>>> >> > module would be make it be equivalent to
>>> >> >
>>> >> > ```js
>>> >> > //cj2es62cj.js
>>> >> > exports.default = function (){}
>>> >> > ```
>>> >> >
>>> >> > In other words treating default as a regular name prevents you from
>>> >> > losslessly converting commonjs in a backwards compatible way.
>>> >> >
>>> >> > Making named and default exports be mutually exclusive would mean
>>> that
>>> >> > you
>>> >> > could treat default export like module.exports.
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Mon, Jul 21, 2014 at 10:45 AM, Brian Di Palma 
>>> >> > wrote:
>>> >> >>
>>> >> >> On Mon, 

Re: include

[John Barton]

Sorry, I was imagining a specific scenario without giving the specifics:
  include 'foo';  // foo is conventional JS, not a module

I have written on global in a module, it works ok, but the goal was
specifically to mutate global with code written in a module.

Here I have given code, designed to be loaded with a 

include

[John Barton]

In the module system we issue
   import {foo} from 'foo';
and the Loader computes an address, say foo.js, fetches the resource and
compiles it. If the content of foo.js has no dependencies, it is evaluated,
then the importer is evaluated. Yay!

Now suppose that foo.js defines a global value. Oh bad sure, but sometimes
you have to play cards you are dealt. We still depend upon foo.js, bad or
not bad.

In the current module system we have to abandon ship. In our importer we
need to:
  // WARNING pre-load foo.js somehow!

Now imagine if we could issue
   include 'foo';
and the Loader computes an address, say foo.js,fetches the resource and
compiles it. Since the content has no dependencies, it is evaluated, then
the importer is evaluated. Yay!

On now back to preloading somehow,
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: System as a SystemLoader class

[John Barton]

On Mon, Jul 14, 2014 at 11:11 AM, Matthew Robb 
wrote:

> Because it seems likely that people will want to use the System Loader but
> also augment it with their own customizations.
>

Yes, that is what I did below.


> STILL benefiting from the environment specific implementation details.
>

Yes, we need ways for custom loaders to define which implementation they
extend.  Some may choose to extend "whatever random System was loaded
last"; the rest of us would like to choose to extend definite testable
Loader instance.

I suppose we can have LoadMeFirst code and all that but really this is ES6:
can't we do better?

jjb


>
>
> - Matthew Robb
>
>
> On Mon, Jul 14, 2014 at 1:53 PM, John Barton 
> wrote:
>
>> Why not something more like:
>>
>> class RemappingLoader extends Reflect.Loader {
>>   constructor(hooks, baseURL, paths) {
>> super(hooks);
>>   //...
>>   }
>>   fetch(load) {
>>   // ..
>>   }
>> }
>> Reflect.global.System = new RemappingLoader(Reflect.global.System,
>>process.cwd() + '/', {'*': '*.js' });
>>
>> The main differences here are:
>>   1) This already works,
>>   2) Use std Loader not System.constructor,
>>   3) Don't attach baseURL to loaderConfig, since the loaderConfig is
>> documented in the std.
>>
>> (System is already an instance of Reflect.Loader so I'm unclear on why we
>> need the change you suggest).
>>
>> The biggest hole I see in my example is the use of Reflect.global.System
>> as the value for the loader hooks. What I want to say here is "This
>> platform's built in loader hooks", not "The loader hooks some random other
>> package wrote onto System".
>>
>> jjb
>>
>>
>>
>>
>> On Mon, Jul 14, 2014 at 10:39 AM, Guy Bedford 
>> wrote:
>>
>>> Currently if I want to subclass the System loader I need to do something
>>> like -
>>>
>>> var newLoader = new Loader(System);
>>> newLoader.fetch = function() {
>>>   // ...
>>> }
>>>
>>> Effectively we're monkey-patching, which isn't pretty.
>>>
>>> It would be nice to be able to do:
>>>
>>> class newLoader extends System.constructor {
>>>   constructor(loaderConfig) {
>>> this.baseURL = loaderConfig.baseURL;
>>> // ...
>>>   }
>>>   fetch: function() {
>>> super.fetch
>>>   }
>>> }
>>>
>>>  In order to allow this, we would need to first define a SystemLoader
>>> class, and make System an instance of it.
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: System as a SystemLoader class

[John Barton]

Why not something more like:

class RemappingLoader extends Reflect.Loader {
  constructor(hooks, baseURL, paths) {
super(hooks);
  //...
  }
  fetch(load) {
  // ..
  }
}
Reflect.global.System = new RemappingLoader(Reflect.global.System,
   process.cwd() + '/', {'*': '*.js' });

The main differences here are:
  1) This already works,
  2) Use std Loader not System.constructor,
  3) Don't attach baseURL to loaderConfig, since the loaderConfig is
documented in the std.

(System is already an instance of Reflect.Loader so I'm unclear on why we
need the change you suggest).

The biggest hole I see in my example is the use of Reflect.global.System as
the value for the loader hooks. What I want to say here is "This platform's
built in loader hooks", not "The loader hooks some random other package
wrote onto System".

jjb




On Mon, Jul 14, 2014 at 10:39 AM, Guy Bedford  wrote:

> Currently if I want to subclass the System loader I need to do something
> like -
>
> var newLoader = new Loader(System);
> newLoader.fetch = function() {
>   // ...
> }
>
> Effectively we're monkey-patching, which isn't pretty.
>
> It would be nice to be able to do:
>
> class newLoader extends System.constructor {
>   constructor(loaderConfig) {
> this.baseURL = loaderConfig.baseURL;
> // ...
>   }
>   fetch: function() {
> super.fetch
>   }
> }
>
>  In order to allow this, we would need to first define a SystemLoader
> class, and make System an instance of it.
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Asynchronous Module Initialize

[John Barton]

On Wed, Jul 9, 2014 at 1:57 PM, Jussi Kalliokoski <
jussi.kallioko...@gmail.com> wrote:
...

>  I proposed (it was less of a proposal though, more an idea or an example
> to spur better ideas) that we had a single dynamic exportable per each
> module, and that could be an object, function, undefined for side effects
> or anything. But, the important part was that it could also be a Promise of
> what you want to export, allowing asynchronous module initialization.
>
> The use cases addressed include:
>
> * Optional dependencies (required for porting large amounts of existing
> code to use ES6 modules).
> * Async feature detection.
> * Dependencies on things other than JS, such as stylesheets, images,
> templates or configuration (e.g. a default language pack).
> * Waiting on something to be ready, for example something like jQuery
> could wait for DOM ready so that the API consumer doesn't have to.
>
> All of these can be done with the current design, however you cannot defer
> the module being ready to be imported. So if you depend on these use cases,
> you have to provide async APIs for things that are possibly synchronous
> otherwise, not only imposing a performance penalty, but also a convenience
> downer on the consumers of your API.
>
...

If I understand your question here, I think the current solution as
adequate support for these cases.

The current module loading solution mixes imperative and declarative
specification of the JS execution order. It's a bit of a layer cake:
imperative layer trigger declarative layers trigger imperative layers.

The top imperative layer (eg System.import()) loads the root of the first
dependency tree and parses it, entering a declarative specification layer,
the import declarations. These declarations are then processed with Loader
callbacks, in effect more imperative code, that can result in parsing and
more declarative analysis.

By design the declarative layers prevent all of the things you seek. This
layer is synchronous, unconditional, wired to JS exclusively.

The imperative layers support all of the use cases you outline, though to
be sure some of this is more by benign neglect than design.

By providing a custom Loader one can configure the module registry to
contain optional, feature-detected modules or non-JS code. The Loader can
also delay loading modules until some condition is fulfilled.   I expect
that multiple custom loaders will emerge optimized for different use cases,
with their own configuration settings to make the process simpler for devs.
 Guy Bedford's systemjs already supports bundling for example.

This approach concentrates the configuration activity in the code preceding
the load of a dependency tree (and hopefully immediately before it). This
seems like a better design than say commonjs where any module at any level
can manipulate the configuration.

The only unfortunate issue in this result is the decision to embed the
custom loader in the global environment. This means that a tree of
interdependent modules can issue Loader calls expecting a particular Loader
to be in System so a custom loader will have to set/unset the global while
loading the tree. Maybe we can experiment with modular loaders some time.


jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Loader.parse ?

[John Barton]

In
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-instantiatesucceeded-instantiateresult-functions
,

15.2.4.5.3 InstantiateSucceeded(instantiateResult) Functions

The step number 4 reads:
-
If instantiateResult is undefined, then

Let body be the result of parsing load.[[Source]], interpreted as UTF-16
encoded Unicode text as described in 10.1.1, using Module as the goal
symbol. Throw a SyntaxError exception if the parse fails or if any static
semantics errors are detected.
Set load.[[Body]] to body.
Set load.[[Kind]] to declarative.
Let depsList be the ModuleRequests of body.


While trying to use es6-module-loader,
https://github.com/ModuleLoader/es6-module-loader/, as the Loader in
Traceur, https://github.com/google/traceur-compiler/, rather than our
current TraceurLoader, it became clear that the above step 4 would be
architecturally clearer if it were a hook comparable to
normalize/locate/fetch...  For example:
parse(load) -> depsList
nicely fulfills the requirements of step 4.  The loader.js file in
https://github.com/ModuleLoader/es6-module-loader/pull/174 shows the
consequences in source that follows the spec.

Adding `parse` as a Loader hook allows customization of the declarative
path of the Loader.   This mechanism is a good fit for Traceur, providing
evidence that this API would prove useful.

Please consider adding a `parse()` hook to the Loader.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: ModuleImport

[John Barton]

On Thu, Jul 3, 2014 at 2:31 AM, Jussi Kalliokoski <
jussi.kallioko...@gmail.com> wrote:

>  Tools like Traceur can support it for an easier migration path since they
> already have diverged from ES.next anyway with all the annotations (for
> which, off topic, I haven't seen even a proposal here yet) and stuff.
>

Jussi, I would appreciate a bug report on the Traceur github project
pointing to information that makes you think this statement is correct. We
consider divergence from ES.next to be a bug and do not support any feature
outside of the proposal from TC39.   Our project does provides great
technology that has been used to develop migration tools, annotation
experiments, and "stuff". All of that comes on other projects or under
opt-in flags on traceur.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[John Barton]

This seems like a bit too many issues, so let me just correct one
(important) one.


On Wed, Jul 2, 2014 at 2:09 PM, Jussi Kalliokoski <
jussi.kallioko...@gmail.com> wrote:

> On Wed, Jul 2, 2014 at 7:09 PM, John Barton 
> wrote:
>
>>
>>>
>
>>
>>> Now, I know there are people that think that this isn't not good, but it
>>> is. It gives you a lot of power when debugging things or playing around
>>> with new things (something I haven't seen discussed re:modules on this
>>> list). One of the greatest things in JS is that instead of reading the
>>> usually poor documentation, let alone the code, of something you want to
>>> use you can just load it up in node or the developer tools and play around
>>> with it. With node, you require() something in the repl and you see
>>> immediately what it exports.
>>>
>>
>> Loader.get() provides the module.
>>
>
> Hmm, my bad, I actually thought that Loader.get() works only when the
> module has already been fetched.
>

Your thought was correct: Loader.get() only works if the module is fetched.
 It was my impression that you were describing a debugging scenario where
the module would be loaded and where you are likely to want to avoid
module-loading since your goal is to debug the live image.



> Well that improves things a lot but that still leaves the disparity
> between what you'd write in actual code and the repl and thus fails to be
> better (in this case) than for example CommonJS.
>

I expect devtools to support declarative import in their REPL, so the code
you would write is the same.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[John Barton]

On Wed, Jul 2, 2014 at 1:09 AM, Jussi Kalliokoski <
jussi.kallioko...@gmail.com> wrote:

> On Tue, Jul 1, 2014 at 10:28 PM, Kevin Smith  wrote:
>
>>
>>  As such, we are balancing the marginal user experience gains of
>>> "export-overwriting" against the better support for circular dependencies
>>> of "real" modules.
>>>
>>
>> Another way of looking at it:
>>
>> Being in control of the language, you can always invent new sugar to
>> optimize user experience (within limits) when real usage data proves its
>> worth.  But the core model can't be changed.
>>
>> As such, it seems like it would be better to err on the side of making
>> the core model simple and solid, leaving minor UX optimizations to future
>> syntax.
>>
>
> But it's neither simple nor solid. It's overtly complicated to support
> features that shouldn't be there.
>

Actually I think you have missed important features that the current
proposal supports and are needed for your use cases.


>
> Sorry in advance for the tone of this message, it is quite negative. But
> the intent is constructive. To me modules are the most anticipated feature
> in ES6 and I've been closely following the discussion and the proposal's
> evolution and I've been extremely thrilled. Finally we could have a chance
> of alleviating the situation of having a ton of non-intercompatible
> different module loaders. I haven't contributed much to the discussion
> since I liked the overall direction. However, now that I've been actually
> using the modules for a while with a couple of different transpilers, it's
> become obvious that the design is inherently broken (not the fault of the
> transpilers, they are actually probably better in some aspects than the
> real thing), and in order for ES modules to help the situation instead of
> making it worse, it needs to be better than the existing solutions.
>
> The core unique selling points of ES6 modules as opposed to the other
> module loading systems:
>
> * Language built-in: the strongest point. This makes sure that most
> tooling should support the feature out of the box and that module authors
> are more inclined to provide their modules in this format. But the design
> can be whatever and this point will still hold true, so no points to the
> design here.
> * (Reliably) statically analyzable syntax. This is my favourite feature
> and really awesome. Allows engine to fetch next modules while the current
> one is still being parsed,
>

This isn't true -- all module designs in play require parsing (include of
course CJS and AMD).


> and tooling to better understand what the code does. However, this would
> hold true even if all we standardized was syntactic sugar on top of
> requirejs.
>

I don't believe that anyone expects such an outcome.


> * Cyclic dependencies: First of all, this is not a feature you want to
> necessarily encourage. It looks good in academia, but in my career I've yet
> to see real world code that would benefit more from cyclic dependencies
> more than refactoring. Not to mention that having cyclic dependencies have
> been possible in global scope modules since LiveScript, and is possible in
> CommonJS as well if you do a little DI:
> https://gist.github.com/jussi-kalliokoski/50cc79951a59945c17a2 (I had
> such a hard time coming up with an example that could use cyclic
> dependencies that I had to dig the example from modules examples wiki). And
> honestly I don't think it's a feature that deserves to be easier to do than
> my example, and especially not worth making other design compromises for.
>

The arguments for and against supporting cyclic dependencies seem to be
academic. I'm yet to see any evidence of their importance in practice nor
proof they they are fundamental ... or not.


> * Mutable bindings: This will make a good chapter in a future edition of
> JavaScript: The bad parts, along with being able to redefine undefined. You
> can have mutable bindings in other module systems as well, just reassign
> something in your exports and then your consumer uses the exports property
> directly. A lot of WTFs avoided and even doing it like that will ring alarm
> bells in code review.
> * Compile-time errors: This not a feature, it's a bug. Try finding a
> website that doesn't somewhere in its code check for whether you have a
> feature / module available, i.e. optional dependencies. Some examples:
> Angular has jQuery as an optional dependency; spritesheet generator modules
> for node that have multiple engines as optional dependencies because some
> of them may be native modules that don't compile on all platforms. Also
> things get worse if platform features are implemented as modules. Let's say
> things like localStorage, IndexedDB and friends were provided as modules
> and as a result, things like localforage would either not exist or would be
> infinitely more complex. Just look at github search for keywords `try` and
> `require`
> https://github.com/search?l=javascript&q=try+require&ref=cmdform&ty

Re: ModuleImport

[John Barton]

On Mon, Jun 30, 2014 at 12:00 PM, Kevin Smith  wrote:

>
>> What's not clear is the advantage of module bindings form for modules.
>>  When the world of possibilities opens up, what specific things will I see
>> there?
>>
>
> I think I'm following you now.  So let's pose the question like this:
>
> Let's posit that there are no default export or import forms, otherwise
> the current *syntax* is the same.  Now, we have two semantic options that
> we can attach to that syntax:
>
> 1.  Modules are just regular objects with getters.  The import
> declarations just get properties from those objects at runtime.
> 2.  Modules are a collection of named bindings.  Those bindings are
> resolved at compile-time.
>
> Now, since the syntax is the same, our ability to do offline static
> analysis is the same.  So what are the differences between these two
> semantics?
>

Thanks! This is the kind of information I was hoping for.


>
> (All of this has been gone over before, of course...)
>

Perhaps, but clear explanation of complex topics is difficult.  Isolating
the issues and getting to specifics helps. In that spirit I'll ask for more
details.


>
> Advantages of 1:
>
> - None?
>
> Advantages of 2:
>
> - Good support for circular dependencies
> - Mutable bindings
>

As far as I know, this is not something JS developers understand. What is
it and what makes it an advantage?


> - Compile-time optimizations for "module.member" expressions
>

Is this known to be significant and fundamental? As in there is no way to
achieve this optimization with the other format? Seems to me that the
compiler introduces the getters and thus can inline them.


> The advantage of 1 only appears if we allow module object overwriting.
>

Concretely you mean monkey patching module objects in the importing code?
Or?


> Those advantages are:
>
> - Auto-renaming the import (questionable)
> - Smoother interoperability with CommonJS modules.
>
> On the other hand, module object overwriting disables our ability to do
> offline static analysis.
>
> So I think the only forceful argument if favor of option 1 (i.e. modules
> are regular objects with getters) is interoperability, and only if we allow
> export overwriting.
>
> The interoperability question is therefore of central importance.
>

Based on other discussion on this point, it seems like
module-as-named-bindings can interoperate with CJS and AMD except perhaps
in some unusual cases. Clarifying these cases would help.

To me, these two lists are pretty darn small compared with the overall
advantages of modules.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[John Barton]

Let me try to restate my request for clear information on the advantages of
module bindings vs module object architectures.

The import syntax already allows pre-execution tools to collect every
module that will be accessed by a root dependent module (including some
that may not be used).  This advantage is clear and it can be weighed
against the disadvantages, including more syntax restrictions to learn and
the need for a separate dynamic API.  On balance I think it's a win,
because I understand the advantage.

What's not clear is the advantage of module bindings form for modules.
 When the world of possibilities opens up, what specific things will I see
there?


On Sun, Jun 29, 2014 at 7:46 PM, Kevin Smith  wrote:

> Bruno and John's arguments are classic examples of the straw man fallacy.
>  In my concrete examples I made no reference to static type systems (or any
> type systems at all, for that matter).  I merely pointed out that by
> allowing the programmer to provide compile-time information in the form of
> exports and declarative forms, a world of possibilities opens up.
>
> Of course, static information can always be *inferred* from dynamic.
>  That's basically how JS engines work, but raising that up to some ideal
> principle is foolish dogmatism.
>
> They accuse me of advocating decades-old technology, but it is purely
> dynamic JS that is decades old.  "Evolve or die" is the way.  The "we don't
> need no stinkin' classes" argument is counter-productive, counter-intuitive
> reactionary garbage, and quite frankly it bores me.
>
> : P
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[John Barton]

On Sat, Jun 28, 2014 at 3:58 PM, Kevin Smith  wrote:

> Static checking will be limited anyway. If you want to go this way you
>> should use typescript.
>>
>>
> That's the point that I'm trying to make, shops will choose other
> languages that provide more static information.  We should be thinking
> about expanding the user base and ensuring that JS is a viable option years
> down the road.
>

JavaScript's enormous user base is the strongest possible evidence that
static analysis provides no advantage to programming language viability.
Static analysis may encourage some new users; overall complexity may
discourage as many.  (I recently started using a typed version of JS;  I am
not impressed.)

Any survey of the top languages in actual use clear demonstrates that the
runtime platform and app goals dominate language choice. Even within a
platform it is clear static checks are way down the list of valued
features.

Rather than point towards type-checking, I think we should focus on the
actual checks offered by the module design. It seems that these would come
with a small cost quite unlike type-checking.


>
>> CommonJS falls a bit short on the import side because static analysis of
>> require calls is brittle. A special language syntax would enable a robust
>> static analysis of dependencies.
>>
>
> If you don't have static exports, then how are you going to know if what
> you import is valid?  You can't, without executing the program.
>

If you don't execute the program, how do you know if the code you are
checking is even called? Oh, you do plan to execute the program. Well there
you go.

(I just think it is so weird that JavaScript's huge advantage of rapid
dynamic feedback for developers receives so little attention while so much
is lavished on static technologies developed decades ago for a computing
environment vastly inferior to our current world.)

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[John Barton]

Thanks Kevin. I'm going to challenge your list below, but I hope you don't
take it negatively.  I want the case for the module system to be as strong
as possible.


On Sat, Jun 28, 2014 at 11:51 AM, Kevin Smith  wrote:

>
>>> Static checking of imports and exports has well-known advantages and
>>> would help the long-term viability of the language.
>>>
>>
>> Enumerating these specific advantages would inform this discussion.
>>  These advantages are not well-known. Many developers have experienced the
>> disadvantages of complex systems of rules and thus favor simple solutions
>> over ones with theoretical advantages. Explaining the benefits concretely
>> would help them balance the well-known costs.
>>
>
> So pretty much everything in Javascript is dynamic, which is one reason
> why IDE support for Javascript has always lagged behind.  You simply can't
> know what anything is until you actually run the program.  Statically
> verifiable exports gives us the ability to inspect and analyze code without
> having to run it.  There are two big benefits that this affords us:
>
> ## Early Errors and Warnings ##
>
> Let's say that you want to deprecate and remove an exported member from a
> module within a large JS code base.  With static imports, the system will
> generate an error at compile time if something on the other side of that
> codebase is importing it.
>

It seems to me that the compiler can verify these two statements with equal
success:
  import {foo} from './foo';
  var foo = require('./foo.js').foo;
I agree that as a practical matter compilers may be more likely to
implement checks on the first form simply because it is standard.  And I
agree that the language-defined module syntax will lead to better quality
tools simply because more developers have formal training in compiler
technology than have training in dynamic analysis.  These are important
pragmatic issues.

Or am I wrong and these are not equivalent? Or there are examples which
show the issue more clearly?


> For exported function declarations that use default parameters to indicate
> optional parameters, we can generate build-time warnings when such an
> function is imported and called with too few arguments.
>

A good argument for default parameters.


>
> For exported classes, we have even more static information at our hands.
>  Without having to run the program, we know the number of arguments for the
> constructor and we know the list of methods for class instances.  We can
> generate warnings when we see an instance using a misspelled method name,
> for instance.
>

A good argument for standard rather than ad-hoc class class syntax.


>
> ## Computer Aided Coding ##
>
> The information used above to generate lint-like warnings can also be used
> to give the developer in-editor feedback.  Reliable code-completion for
> imported function and class declarations becomes possible.  Again, for
> exported classes we can also do code completion for instance methods.
>
> These advantages may not seem like a big deal now, but imagine writing JS
> in a large team five years from now.  Do you want the power of static
> analysis at your team's fingertips, or do you want to be stuck with
> "anything goes so anything can break" CommonJS modules?
>
> Does that do it?
>

These are arguments for statically computable import module names -- so the
compiler can determine the imports without executing source code -- and for
top-level or hoisted (static) import statements -- so every import in a
module is a dependency of the module without runtime conditionals. I
believe that both of these limitations would be acceptable to almost all
developers interested in using modules.

Unfortunately I think we need more specific and detailed examples to
understand the advantages of the static form.
Thanks,
jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[John Barton]

On Sat, Jun 28, 2014 at 9:03 AM, Kevin Smith  wrote:

>
>> Static checking on exported members feels odd.
>>
>
> Static checking of imports and exports has well-known advantages and would
> help the long-term viability of the language.
>

Enumerating these specific advantages would inform this discussion.  These
advantages are not well-known. Many developers have experienced the
disadvantages of complex systems of rules and thus favor simple solutions
over ones with theoretical advantages. Explaining the benefits concretely
would help them balance the well-known costs.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[John Barton]

+1


On Fri, Jun 27, 2014 at 6:39 AM, Matthew Robb 
wrote:

> My opinion is that CommonJS and AMD work today and will continue to work
> into the future so we should optimize for the ideal "looking forward, not
> backward" case when adding to the language. Loader will still be
> overload-able and since both CommonJS and AMD require a library today it
> seems completely reasonable that they will continue to do that and can hook
> into es6 through loader extension.
>
> Conclusions:
> - Drop default exports
> - export function readFile(){}
> - import fs from "es6-fs"; // fs.readfile();
> - import { readFile } from "es6-fs"; // readFile();
> - Done.
>
>
> - Matthew Robb
>
>
> On Fri, Jun 27, 2014 at 6:32 AM, Kevin Smith  wrote:
>
>>
>>>   - Either we think "real" modules are an improvement, and checking is
>>> important. Then the model and the syntax should be consistent about
>>> that. Moreover, checking needs to consistently apply, no matter how a
>>> module and its components are defined or accessed.
>>>
>>>   - Or we come to the conclusion that supporting the legacy singleton
>>> export model as a primary use case is a mandatory matter. Then we
>>> should drop attempts of building something in/semi-compatible, and
>>> limit innovation to making export and import declarative, and
>>> designing a loader API.
>>>
>>
>> Since "real" modules are at the core of the current design, I think the
>> first option is feasible and equates to simply dropping the "default"
>> feature, leaving everything else intact.  The second option, on the other
>> hand, will take us back to the drawing board and I don't see how we can do
>> that within the ES6 timeline.  We don't want Promises all over again.
>>
>> So, if we cannot settle on option 1, then I think modules must be
>> deferred from ES6.
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Default exports, without explicit syntactic support

[John Barton]

On Thu, Jun 26, 2014 at 7:39 AM, Axel Rauschmayer  wrote:

> // my-class.js
> export class MyClass {
> constructor() { ... }
> method() { ... }
> }
>
> // use-class.js
> import { MyClass } from "my-class.js";
>
>
> You do have redundancy in `my-class.js` and, as Marius pointed out, the
> importer has to know both the name of the module and the name of the entity
> inside the module. Not that big of a deal.
>

But these examples are misleading. "my-class.js" is not the name of the
module. Its is a module identifier, and probably incorrect since the
identifier is both absolute and ending in .js.

A more realistic example is

import {MyClass} from "./pretentious/kernel/core/util/my-class";

In the big picture the time to type a few characters in regular pattern is
completely overwhelmed by the time it takes to figure out what MyClass does
and where it lives.



> Again, standardizing on `_` for default exports helps,
>

I guess you meant "developers may choose to adopt short export
identifiers"; I don't suppose you are proposing to standardize _.


> but then importing is more verbose:
>
> // my-class.js
> export class _ {
>
> constructor() { ... }
> method() { ... }
> }
>
> // use-class.js
> import { _ as MyClass } from "my-class.js";
>
> --
> Dr. Axel Rauschmayer
> a...@rauschma.de
> rauschma.de
>
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[John Barton]

// I have a module named `foo`.
// I don't care what `foo` is.
// Including whether or not its a namespace.
// I need make no promises about identifier `foo`.
import {bar} from './foo';


On Wed, Jun 25, 2014 at 12:52 PM, C. Scott Ananian 
wrote:

> On Wed, Jun 25, 2014 at 2:59 PM, Kevin Smith  wrote:
>
>> Correct me if I'm wrong, but the perspective says: "why would I need to
>> import the multiple-exports if I'm specifically overriding the exports with
>> a default?  Having a way to import both the default and multiple-exports is
>> silly and confusing."
>>
>
> For my part, my personal perspective is, "I have a module named `foo`.  I
> want to write `foo.bar` to get the export named bar.  I don't care *what*
> `foo` is.  Perhaps its a function object for backwards-compatibility.
>  Perhaps it's a module object because of some circular dependency.  Perhaps
> it's a plain object.  To me it's just a namespace.  Please let me use the
> same import syntax regardless.  In exchange, I promise never to use bare
> `foo` in my code."
>
> There are a couple of different solutions; default-default is one of those.
>  --scott
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: debugging modules

[John Barton]

On Tue, Jun 24, 2014 at 12:53 PM, Guy Bedford  wrote:

> If it is a tools problem, it becomes a much more complex problem.
>
> Firstly note that the promise isn't rejecting, it is resolving correctly.
> That is if I have a module X:
>
> X.js
> throw "this module throws";
>
> Then:
>
> System.import('X').then(function(m) {
>   // this returns correctly, with m defined.
> });
>
>
Surely this case must call reject().  What circumstances would call
reject() if not the failure to import?


> So the only information we have is the environment exception that
> something went wrong executing module X. We have no information of what
> dependency chain caused this.
>
> If we want to inspect the dependency chain, there is nothing to inspect,
> since we don't even know what loads might have caused it in the first place.
>
> So there is no way for a debugger to tell the user anything useful apart
> from inspecting the entire dependency tree. The evaluation chain that was
> an explicit set of modules for ensureEvaluated, is no longer available for
> useful debugging.
>

I don't follow all of this but using your example from
es6-module-loaders/test for import('load/main') dependent on
'load/depError' which throws 'dep error', then we should be able to give an
error like

Module Evaluation Error: 'dep error' in
loads/deperror loaded by
loads/main

https://github.com/google/traceur-compiler/pull/1127

We can give line/col info with a bit of work in Traceur; it would be
trivial in a native implementation.

If the spec does not allow this, then we need to fix it.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Loader Hooks

[John Barton]

Guy Bedford's es6-module-loader follows the Loader spec closely. I just
refactored it to create a function call `parse(load) -> deps`:

https://github.com/ModuleLoader/es6-module-loader/blob/master/lib/loader.js#L389

This location in the pipeline is pretty much where you suggest. I think
I've convinced Guy to let me add it as a hook. Maybe your request will push
him over the edge ;-)

Note that as far as I can tell, this function call provides a neat
interface between the Loader and parser.

jjb




On Tue, Jun 24, 2014 at 7:17 AM, Calvin Metcalf 
wrote:

> I've been doing work with the loader hooks and one gap that stands out is
> that there is no hook to let you manipulate the exports and imports of an
> module without parsing it yourself, in other words if you want to add,
> remove, or modify exports or imports of a module you have to write your own
> parsing function because the default instantiate function returns undefined.
>
> Ideas:
>
> - There is a way of doing what I need to do that I am missing.
> - Add a post instantiate hook between 15.2.4.5.3 (InstantiateSucceeded)
> and 15.2.4.6 (ProcessLoadDependencies)
> - The steps in 15.2.4.5.3.4 could be moved to the default instantiate
> function so that when overriding it you can still call it to get the parsed
> module object.
>
> ---
> -Calvin W. Metcalf
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[John Barton]

On Fri, Jun 20, 2014 at 4:17 PM, Ron Buckton 
wrote:

> > From: John Barton [mailto:johnjbar...@google.com]
> > Sent: Friday, June 20, 2014 3:48 PM
> >
> > ES6 already has what you want:
> >
> > _Named Exports_:
> >
> > export var foo = 1;
> >
> > _Single Export Object_:
> >
> > export var moduleName = {
> >   foo: 1,
> >   bar: function() {}
> > };
> >
> > _Single Export Function_:
> >
> > export function fName() { }
> >
> >
> > And even cooler, the syntax for import is uniform,
> >
> > import {foo} from './namedExport';
> >
> > import {moduleName} from './singleExportObject';
> >
> > import {fName} from './singleExportFunction';
> >
>
> I'm not stating that I specifically "want" anything here, but was rather
> recommending an alternative approach to the single export vs named export
> debate and the removal of the ModuleImport production.


Sorry, I did understand that. I was (cryptically) recommending that
removing ModuleImport and `export default` until a later date gives us a
good-enough solution to the cases you outline. These features can be added
at a later very easily and since they would be based on real users asking
for more features we could move on them quickly.



> David's mail was proposing the addition of the following syntax:
>
> ```
> import * as fs from "fs"
> ```
>
> This is designed to work around the fact that without ModuleImport,
> there's no simple way to get the module object for the named exports. What
> you really want to write is:
>
> ```
> import fs from "fs";
> ```
>
> However, the current semantics don't allow this.  David proposed the new
> syntax as a replacement for ModuleImport. My only issue is that for the end
> user this could be confusing, and its possibly future-hostile for
> refactoring.
>

So let's just remove it and export default and go. No confusion. We make
progress. We study real feedback. We reconsider.


>
> If I have a library today that uses an object literal as a default export
> in Node, and I want to migrate to ES6, the easiest approach is to just
> replace `module.exports =` with `export default`.


Easing migration is a great goal for the next release.  We can refine
ModuleImport between now and then.


> My consumers would happy use `import foo from "foo"`. If I later want to
> move to named exports, I would break my consumers as they would have to
> change this to `import * as foo from "foo"`.  The whole reason for this is
> that there is a semantic distinction with how a default export is handled
> vs. how named exports are handled.
>

Exactly. So don't allow default export. Presto, problem solved.


>
> If I were to use TypeScript's syntax for exports and imports, changing
> from a default export to named exports results in no change for the
> consumer:
>
> [before.ts]
> ```
> export = {
>   foo: 1,
>   bar() {}
> }
> ```
>
> [after.ts]
> ```
> export var foo = 1;
> export function bar() {}
> ```
>
> [consumer.ts]
> ```
> import before = require("before");
> import after = require("after");
> before.foo; // 1
> before.bar; // function bar() {}
> after.foo // 1
> after.bar; // function bar() {}
> ```
>
> Albeit, TypeScript does not have a Module exotic object, nor does it have
> mutable bindings, nor an ImportList in its import clause. That said, as far
> as the consumer is concerned there's no real distinction between the
> "default export" approach in before.ts and the "named export" approach in
> after.ts.  We have this distinction in ES6 because it was designed that way
> to support mutable bindings and cyclic dependencies. I'm proposing that we
> come up with alternative semantics that preserve that approach while
> keeping the import syntax simple.
>

I think both export default/module import and cyclic dependency support are
marginal features that cause as many wacky problems as the solve. They just
don't matter one way or another.  The export default/module-import are easy
to add later: removing them now is simple. Changing the semantics means
redesigning modules.


> As a module consumer, I would constantly need to be aware of whether I
> need to use the `import * as foo from "foo"` syntax or the `import foo from
> "foo"` syntax. Where in Node I would use `require("foo")` for both cases.
> By changing the semantics of ImportDeclaration in ES6 and using a simpler
> syntax, we could would save developers the cognitive cost of determining
> which import syntax to among two very similar forms, as well as supporting
> the ability for a module author to refactor their module from a default
> export to named exports for the single-export-as-object case without
> affecting their consumers.
>

Omitting export default and module-import achieves the same cognitive
savings.

jjb
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: ModuleImport

[John Barton]

ES6 already has what you want:

_Named Exports_:

export var foo = 1;

_Single Export Object_:

export var moduleName = {

  foo: 1,

  bar: function() {}
};

_Single Export Function_:

export function fName() { }

And even cooler, the syntax for import is uniform,

import {foo} from './namedExport';

import {moduleName} from './singleExportObject';

import {fName} from './singleExportFunction';


On Fri, Jun 20, 2014 at 3:21 PM, Ron Buckton 
wrote:

>  > -Original Message-
>
> > From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
>
> > Sébastien Cevey
>
> > Sent: Friday, June 20, 2014 3:46 AM
>
> > To: Axel Rauschmayer
>
> > Cc: es-discuss list
>
> > Subject: Re: ModuleImport
>
> >
>
> > On 20 June 2014 11:39, Axel Rauschmayer  wrote:
>
> > > > The `*' symbol universally represents a glob of "everything", but
>
> > > > when used to import from a module that has multiple exports, you
>
> > > > won't get everything, you will get either the single default export
>
> > > > (if there is
>
> > > > one) or nothing.
>
> > >
>
> > >
>
> > > What gives you that impression? Quoting David’s original email:
>
> > >
>
> > > ```js
>
> > > import * as fs from "fs"; // importing the named exports as an object
>
> > > import Dict from "dict";  // importing a default export, same as ever
>
> > > ```
>
>
>
> With all due respect, why is it that we cannot change the specification to
> allow `import name from "module"` for both the default export (for single
> export modules) and the Module object (for multi-named export modules). The
> same question goes for using `import { name as "name" } from "module"` for
> both. As specified, a default export is equivalent to a Module object with
> a "default" property, and as a result requires special handling with
> respect to how it is bound to the _ImportBinding_ in `import name from
> "module"`. Wouldn't it make sense to simplify the syntax and expand the
> static and runtime semantics for imports? Are we sure that the current
> semantics are the right approach that we should shoehorn the syntax into?
>
>
>
>
> Is it imperative for module authors to be able to provide both a default
> export *and* named exports within the same module? From most of the
> comments in this thread, it seems that expected module use falls into two
> categories:  Single-export modules and Multi-export modules. Is there a
> use-case in the wild (via ES6 module transpilers) where a single module
> today uses both a default export as well as named exports?
>
>
>
> With respect to Node libraries, I often see one of three approaches to
> exporting from a module:
>
>
>
> _Named Exports_:
>
> ```
>
> exports.foo = 1;
>
> // or
>
> module.exports.foo = 1;
>
> ```
>
>
>
> _Single Export Object_:
>
> ```
>
> module.exports = {
>
>   foo: 1,
>
>   bar: function() {}
> }
>
> ```
>
>
>
> _Single Export Function_:
>
> ```
>
> module.exports = function() { }
>
> ```
>
>
>
> In Node, if you wanted to have a default export that is a function, but
> also have additional exports you would most likely add them as data
> properties on the function:
>
> ```
>
> module.exports = function() {}
>
> module.exports.foo = 1;
>
> ```
>
>
>
> Given that, why not simplify the syntax and semantics to just the
> following three forms:
>
> ```
>
> import "module"; // imports the module but does not perform binding
>
> import name from "module"; // imports the module (either the default
> export or a module object with the named exports, see below)
>
> import { name1, name2 as "otherName" } from "module"; // imports members
> of the module.
>
> ```
>
>
>
> Simplifying this requires the following (approximate) changes in semantics:
>
>
>
> * Either (A) a module cannot have *both* a default export and named
> exports, _or_..
>
> * (B) A modules named exports become attached properties of the default
> export if provided.
>
> * If (B), it becomes an runtime error to add a default export after a
> named export, and a runtime error to add a named export if the default
> export is not an Object.
>
> * The ImportBinding (`name` above) becomes bound to a [[Value]] property
> of an (not part of the current spec) Import exotic object.
>
> * When the Module exotic object is loaded, if it has a property named
> "default", that becomes the value of the [[Value]] property of the Import
> exotic object.
>
> * If the Module exotic object does not have a property named "default",
> the Module itself becomes the value of the [[Value]] property of the Import
> exotic object.
>
> * NamedImports now points to bindings to the [[Value]] property of the
> Import exotic object. If you want both a default export and named exports,
> attach the named exports as properties of the default export.
>
>
>
> With the above changes, whether you're using a default export or named
> exports becomes transparent to the developer.  If the developer _really_
> wants the module object, they could fall back to:
>
> ```
>
> import "module";
>
> var nam