John Lenz wrote:
There are three issues in my mind for tooling:
1) should the code be parsed as use strict
2) are import and export and module statements valid
Note no module form in ES6.
3) should top level declarations be considered visible outside the
file (no can be inferred from the
On Tue, Jan 28, 2014 at 12:32 PM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
There are three issues in my mind for tooling:
1) should the code be parsed as use strict
2) are import and export and module statements valid
Note no module form in ES6.
module M from
Erik Arvidsson wrote:
Note no module form in ES6.
module M from './path/to/module';
is a valid ModuleItem.
Ah, right. I thought John meant module M {...}. Thanks!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
Le 27/01/2014 06:45, Brendan Eich a écrit :
Kevin Smith wrote:
Is a new attribute necessary? What about using @type?
Old browsers will ignore unknown types, losing the two-way
fallback option.
Two-way fallback? Why is that important? Since modules are
implicitly strict,
Once you focus on inline bodies, you face harsh adoption barriers without
enabling works-in-old-and-new coding.
OK, I follow.
However, I'm sympathetic with David because adding an attribute
specifically to fix the JS script/module issue is
design-entropy-increasing.
I wonder to what
Thanks for the explanation.
Given all of the costs, perhaps it is worth reconsidering the benefit.
Many issues affect the load timing of web pages, will this one change make
such an improvement that it's worth the disruption it causes?
On Sat, Jan 25, 2014 at 3:31 PM, Brendan Eich
Le 27/01/2014 19:41, David Herman a écrit :
On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:
Indeed. I'm wondering why we need inline script for modules.
Because people write inline scripts all the time. It's unacceptably
inconvenient not to be able to bootstrap your app
On Jan 27, 2014, at 10:58 AM, David Bruant bruan...@gmail.com wrote:
Agreed. Note that I didn't suggest to stop writing inline scripts and
proposed an alternative to script@module that can work today.
Granted, it's somewhat hacky, but I think it can work during the period
during which
On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:
Indeed. I'm wondering why we need inline script for modules.
Because people write inline scripts all the time. It's unacceptably
inconvenient not to be able to bootstrap your app with inline code. It also
allows you to
[Resending, not sure why it's not getting through to the list...]
On Jan 27, 2014, at 10:41 AM, David Herman dher...@mozilla.com wrote:
On Jan 27, 2014, at 2:07 AM, David Bruant bruan...@gmail.com wrote:
Indeed. I'm wondering why we need inline script for modules.
Because people write
On Jan 24, 2014, at 6:33 PM, Brendan Eich wrote:
John Barton wrote:
On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com wrote:
I should have also included:
2A) Hopefully, overtime, the old script syntactic goal will fade
from
David Herman mailto:dher...@mozilla.com
January 27, 2014 at 12:03 PM
OK, sorry I jumped in the middle of things missing some context. In
fact, I think what we've been planning on proposing is not too far --
I think -- from what you're talking about. The plan is *not* a module
attribute (that
On Sun, Jan 26, 2014 at 9:44 PM, Brendan Eich bren...@mozilla.com wrote:
David Sheets wrote:
There is no out-of-band metadata in a new script attribute. Attributes are
data, not data-about-data, and in-band in HTML.
The channel is the contents of the script element or the ES resource.
John Lenz wrote:
1. a file extension
Talk here is not demand, and I bet we'll regret trying to add a
new one. Extensions mapped by servers to media types require
server configury, often missed or mangled. This has led in the
past to clients hardcoding, e.g.
Brendan Eich wrote:
OK, sorry I jumped in the middle of things missing some context. In
fact, I think what we've been planning on proposing is not too far --
I think -- from what you're talking about. The plan is *not* a module
attribute (that was a think-o on my part, and maybe some
On Mon, Jan 27, 2014 at 2:51 PM, Brendan Eich bren...@mozilla.com wrote:
John Lenz wrote:
1. a file extension
Talk here is not demand, and I bet we'll regret trying to add a
new one. Extensions mapped by servers to media types require
server configury, often missed
John Barton wrote:
It's pretty clear from NPM experience that a new suffix is not
needed for out-of-line modules. Or are you suggesting that Node.js
lacks tooling? I'm not offended, just trying to understand.
What about the node experience helps? They have only one type of
On Mon, Jan 27, 2014 at 4:57 PM, Brendan Eich bren...@mozilla.com wrote:
John Barton wrote:
It's pretty clear from NPM experience that a new suffix is not
needed for out-of-line modules. Or are you suggesting that Node.js
lacks tooling? I'm not offended, just trying to
John Barton wrote:
On Mon, Jan 27, 2014 at 4:57 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
John Barton wrote:
It's pretty clear from NPM experience that a new suffix is not
needed for out-of-line modules. Or are you suggesting that
On Sat, Jan 25, 2014 at 3:31 PM, Brendan Eich bren...@mozilla.com wrote:
John Barton wrote:
The Script goal disallows 'import' and 'export' specifically to ensure
that the Script goal is inconvenient for developers and thus they are
encouraged to shift to the Module goal.
No, that's not
Because it is js everywhere. Pick any file in an AMD/require.js system
and you can parse it.
ES6 cannot support require as a function that synchronously loads from the
filesystem, and I think you know this.
Without a new extension, you cannot import from an old-style module in
the
Kevin Smith wrote:
Because it is js everywhere. Pick any file in an
AMD/require.js system and you can parse it.
ES6 cannot support require as a function that synchronously loads
from the filesystem, and I think you know this.
Without a new extension, you cannot
John Barton wrote:
Why can't script type='module' mean If we see import/export/module
statements then we will will not evaluate the body synchronously.?
That way we avoid the jank with new code just as we do with two
parsing goals and yet we don't need two parsing goals.
We could do this,
All browsers support non media types. Can we change the specs to match
reality
On Monday, January 27, 2014 10:24:49 PM, Brendan Eich bren...@mozilla.com
wrote:
John Barton wrote:
Why can't script type='module' mean If we see import/export/module
statements then we will will not evaluate the
My argument was that Node.js has both non-module and module files with a
common suffix, .js.
Yes - but Node-modules and non-modules can be parsed the same way, so a
common extension makes sense. But when a file needs to be parsed a
different way in Node, how's that's done? By registered
On Jan 27, 2014, at 8:35 PM, Erik Arvidsson erik.arvids...@gmail.com wrote:
All browsers support non media types. Can we change the specs to match reality
Examples? What is the specified grammar?
I hope you aren't thinking of language= here.
How about fallback for old browsers?
/be
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan
Eich
Examples? What is the specified grammar?
From [the HTML spec][1]:
The `type` attribute gives the language of the script or format of the data.
If the attribute is present, its value must be a [valid MIME
Domenic Denicola wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Brendan
Eich
Examples? What is the specified grammar?
From [the HTML spec][1]:
The `type` attribute gives the language of the script or format of the data. If the
attribute is present, its
There are three issues in my mind for tooling:
1) should the code be parsed as use strict
2) are import and export and module statements valid
3) should top level declarations be considered visible outside the file (no
can be inferred from the presence of import or exports)
It is my guess that
In-Reply-To= 5B36C364-13FF-44AA-9B01-4ABC25AB4D65%40wirfs-brock.com
Regarding the .jsm suggestion, a colleague suggested .es, no need
for the m as you could say all ES files are modules.
___
es-discuss mailing list
es-discuss@mozilla.org
On Sat, Jan 25, 2014 at 11:26 PM, Brendan Eich bren...@mozilla.com wrote:
David Sheets wrote:
. Old browsers ignore the new attribute will process the content, which
could be written to work both ways.
Is a new attribute necessary? What about using @type?
Old browsers will ignore
David Sheets wrote:
On Sat, Jan 25, 2014 at 11:26 PM, Brendan Eichbren...@mozilla.com wrote:
David Sheets wrote:
. Old browsers ignore the new attribute will process the content, which
could be written to work both ways.
Is a new attribute necessary? What about using @type?
On Mon, Jan 27, 2014 at 1:29 AM, Brendan Eich bren...@mozilla.com wrote:
David Sheets wrote:
On Sat, Jan 25, 2014 at 11:26 PM, Brendan Eichbren...@mozilla.com
wrote:
David Sheets wrote:
. Old browsers ignore the new attribute will process the content,
which
could be written
Is a new attribute necessary? What about using @type?
Old browsers will ignore unknown types, losing the two-way fallback option.
Two-way fallback? Why is that important? Since modules are implicitly
strict, there is little intersection between scripts and modules.
David Sheets wrote:
There is no out-of-band metadata in a new script attribute. Attributes are
data, not data-about-data, and in-band in HTML.
The channel is the contents of the script element or the ES resource.
The attribute is not transmitted in the contents of the script element
or ES
Kevin Smith wrote:
Is a new attribute necessary? What about using @type?
Old browsers will ignore unknown types, losing the two-way
fallback option.
Two-way fallback? Why is that important? Since modules are
implicitly strict, there is little intersection between scripts
Once you focus on inline bodies, you face harsh adoption barriers without
enabling works-in-old-and-new coding.
OK, I follow.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Sat, Jan 25, 2014 at 2:33 AM, Brendan Eich bren...@mozilla.com wrote:
John Barton wrote:
On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com wrote:
I should have also included:
2A) Hopefully, overtime, the old script syntactic
Well, sorry my extra angle brackets. Let me try again.
Allen says, if I understand correctly, that the tiresome complexity of the
second parsing goal will be repaid when the superior Module goal supplants
the Script goal. But we undermine this tradeoff by allowing Scripts to use
System and
Peter van der Zee wrote:
`noscript type=module/noscript`
Again, no two-way fallback option. Clever thought re: implicit CDATA
content model, though!
/be
___
es-discuss mailing list
es-discuss@mozilla.org
John Barton wrote:
The Script goal disallows 'import' and 'export' specifically to ensure
that the Script goal is inconvenient for developers and thus they are
encouraged to shift to the Module goal.
No, that's not the rationale. The reason is to avoid enabling more
synchronous script
For static language parsers there seems to be a bit of a dilemma with ES6
modules. I would appreciate a correct or hint.
Here is my understanding:
- standard scripts as we know them today will parse in the browser as
loose code
- scripts with the standard use strict will parse as strict
On Fri, Jan 24, 2014 at 8:48 AM, John Lenz concavel...@gmail.com wrote:
For static language parsers there seems to be a bit of a dilemma with ES6
modules. I would appreciate a correct or hint.
Here is my understanding:
- standard scripts as we know them today will parse in the browser as
You don't get let, function block scoping, yield or other
incompatible constructs. (let and yield aren't a reserved word in ES5
loose)
On Fri, Jan 24, 2014 at 8:49 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Jan 24, 2014 at 8:48 AM, John Lenz concavel...@gmail.com wrote:
For static
On Fri, Jan 24, 2014 at 8:49 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Jan 24, 2014 at 8:48 AM, John Lenz concavel...@gmail.com wrote:
For static language parsers there seems to be a bit of a dilemma with ES6
modules. I would appreciate a correct or hint.
Here is my
I believe the conclusion with |let| was to identify let syntax:
let foo(=*) is syntactically unambiguous, just a bit more work to identify.
yield is only valid in generators (function*) so that gets reserved the moment
you enter a generator definition
—Oliver
On Jan 24, 2014, at 9:11 AM, John
On Fri, Jan 24, 2014 at 9:16 AM, John Barton johnjbar...@google.com wrote:
On Fri, Jan 24, 2014 at 8:49 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Fri, Jan 24, 2014 at 8:48 AM, John Lenz concavel...@gmail.com wrote:
For static language parsers there seems to be a bit of a dilemma
On Fri, Jan 24, 2014 at 9:17 AM, Oliver Hunt oli...@apple.com wrote:
I believe the conclusion with |let| was to identify let syntax:
let foo(=*) is syntactically unambiguous, just a bit more work to identify.
yield is only valid in generators (function*) so that gets reserved the
moment you
Le 24/01/2014 18:26, John Lenz a écrit :
REPL is a dilemma: if you parse as module, then obtaining the last
expression value is not simple. if you parse as a script, then
common cut/paste fails on export/import statements.
My basic question remains. As a tool owner how do I know
You don't get let, function block scoping, yield or other incompatible
constructs. (let and yield aren't a reserved word in ES5 loose)
It is true that there is some weirdness with let/const and block scoping in
non-strict mode, but these issues can be sufficiently mitigated. IE11 has
shipped
On Fri, Jan 24, 2014 at 9:32 AM, David Bruant bruan...@gmail.com wrote:
Le 24/01/2014 18:26, John Lenz a écrit :
REPL is a dilemma: if you parse as module, then obtaining the last
expression value is not simple. if you parse as a script, then common
cut/paste fails on export/import
If we are asking questions: why two parse goals? Why not allow import in
Script and let it act like the code was wrapped in Loader.import() and
allow export then just ignore it? The semantics of 'var' would be changed
by appearance of 'import' just like the semantics of code changes with the
As long as you can import from a script in some fashion: Loader.import
works for me.
I'm a little concerned that import/export will need to work as a use
strict
On Fri, Jan 24, 2014 at 9:55 AM, John Barton johnjbar...@google.com wrote:
If we are asking questions: why two parse goals? Why not
On Jan 24, 2014, at 9:32 AM, David Bruant wrote:
Le 24/01/2014 18:26, John Lenz a écrit :
REPL is a dilemma: if you parse as module, then obtaining the last
expression value is not simple. if you parse as a script, then common
cut/paste fails on export/import statements.
My basic
7) Hence, it probably makes sense to promote a convention of using a new
file extension for ES6 source files that are intended to be parsed with the
modules goal. .jsm, or mjs, or something similar that is appropriately
suggestive and isn't already widely used as an extension.
Allen, I'm
I should have also included:
2A) Hopefully, overtime, the old script syntactic goal will fade from use, and
the module goal will become the norm for new code.
On Jan 24, 2014, at 11:38 AM, Allen Wirfs-Brock wrote:
On Jan 24, 2014, at 9:32 AM, David Bruant wrote:
Le 24/01/2014 18:26,
Assuming the current system for a moment, and discussing only conventions:
It is true that a use strict at the top of every *.js file does have
the virtue of making it clear, both to tools and humans, that the
remainder is strict code, even in one doesn't know if the file is to be
loaded as a
On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
I should have also included:
2A) Hopefully, overtime, the old script syntactic goal will fade from use,
and the module goal will become the norm for new code.
Now here is a reason, finally, for all the extra
I'm perfectly happy with convention of some kind:
a) a file extension
b) a comment on the first line of the file:
// module mymodule
c) a use strict style annotation that is just documentation:
module mymodule;
The key thing in my mind is that TC39 pick something and encourage it.
On Fri,
I'm perfectly happy with convention of some kind:
a) a file extension
b) a comment on the first line of the file:
// module mymodule
c) a use strict style annotation that is just documentation:
module mymodule;
One of the nicest things about the current modules syntax is that it avoids
John Barton wrote:
On Fri, Jan 24, 2014 at 12:17 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
I should have also included:
2A) Hopefully, overtime, the old script syntactic goal will fade
from use, and the module goal will become the norm for new
61 matches
Mail list logo
