On Thu, Sep 11, 2014 at 12:02 AM, Kevin Smith zenpars...@gmail.com 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.
Hmmm... In many other circles talking to people and working on
something
On Thu, Sep 11, 2014 at 12:56 AM, Mark S. Miller erig...@google.com wrote:
If there are no objections to recommending .js vs .jsm in this informal
way, I propose that we place it there.
FWIW, .jsm extension is currently used as a convention in XUL for denoting
JavaScript modules (not the
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
John Barton wrote:
The long, painful, sometimes contentious discussions about classes
yielded an outstanding design that works well.
In no sense were ES6 classes designed by es-discuss draw-out contentious
painful committee.
If you meant by yielded reviewed the design after champions had
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
Personally I have felt this way for a long time as well. I think `.esm` is
somewhat confusing since most js developers don't really think about it as
EcmaScript. I would think you could just as easily do `.jsm` but this also
suggests that files of this alternate should be served with a different
Matthew Robb wrote:
Personally I have felt this way for a long time as well. I think
`.esm` is somewhat confusing since most js developers don't really
think about it as EcmaScript.
(sounds like a skin disease...)
I would think you could just as easily do `.jsm` but this also
suggests that
On Wed, Sep 10, 2014 at 6:14 PM, Brendan Eich bren...@mozilla.org 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
On Sep 10, 2014, at 8:44 AM, Matthew Robb wrote:
Personally I have felt this way for a long time as well. I think `.esm` is
somewhat confusing since most js developers don't really think about it as
EcmaScript. I would think you could just as easily do `.jsm` but this also
suggests that
On Wed, Sep 10, 2014 at 12:20 PM, Anne van Kesteren ann...@annevk.nl
wrote:
(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...)
The
On Wed, Sep 10, 2014 at 6:23 PM, Matthew Robb matthewwr...@gmail.com wrote:
The problem is that there are now two distinctly different types of
javascript file, some should be parsed as script and some should be parsed
as module. Assuming everything is script that is not explicitly module would
Well the default browser loader which is still secret(?) purportedly
standardizes on a js suffix. That is probably why this came up.
My understanding is that we have backed off from automagically appending
.js to relative paths, but that info could be old.
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
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
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
On Wed, Sep 10, 2014 at 9:35 AM, Allen Wirfs-Brock al...@wirfs-brock.com
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
Alternatively you could argue that some of the hooks in Loader shouldn't be
in the language spec because they should likely exist outside of something
that is hyper-specifically a module loader. So if the web has a resource
loader construct similar to ES6 Loader and it would handle resolving paths
On Sep 10, 2014, at 12:23, Matthew Robb matthewwr...@gmail.com wrote:
On Wed, Sep 10, 2014 at 12:20 PM, Anne van Kesteren ann...@annevk.nl wrote:
(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
On Sep 10, 2014, at 12:35, Allen Wirfs-Brock al...@wirfs-brock.com 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
There are numerous discussions about this throughout the last two years and
you can find record of them throughout es-discuss. Someone closer to the
topic can likely fill you in but I won't try to pull that information off
the top of my head.
- Matthew Robb
On Wed, Sep 10, 2014 at 12:53 PM,
But why?
To be completely serious. Why do we have to make a difference?
Because we have implicit module bodies, which have different
variable-scoping and strict-mode semantics than regular scripts. The
alternative would have been boilerplate in every module forever.
Some info was discussed here: http://esdiscuss.org/notes/2014-01-28
- Matthew Robb
On Wed, Sep 10, 2014 at 12:53 PM, Todd Kennedy t...@selfassembled.org
wrote:
On Sep 10, 2014, at 12:35, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 10, 2014, at 9:28 AM, Matthew Robb wrote:
As
On Sep 10, 2014, at 9:41 AM, John Barton wrote:
On Wed, Sep 10, 2014 at 9:35 AM, Allen Wirfs-Brock al...@wirfs-brock.com
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
Yeah heres a bit more in depth discussion on the topic:
http://esdiscuss.org/topic/detecting-js-language-mode-for-tools#content-12
- Matthew Robb
On Wed, Sep 10, 2014 at 12:53 PM, Todd Kennedy t...@selfassembled.org
wrote:
On Sep 10, 2014, at 12:35, Allen Wirfs-Brock al...@wirfs-brock.com
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`.
We know that we need outside metadata to work out how to interpret
So my thought based on this comment:
http://esdiscuss.org/topic/detecting-js-language-mode-for-tools#content-14
Why not deprecate sloppy-script mode explicitly and encourage the movement
to module-strict for all scripts moving forward. Once you do that then you
can make the decision to spec the
On Wed, Sep 10, 2014 at 10:07 AM, Guy Bedford guybedf...@gmail.com 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
In NodeJS, this can be through `package.json` properties which inform what
module format the package is.
Right - although having a runtime system looking at json config files is a
terrible idea. : ) In es6now, I'm experimenting with the following rule:
- If some folder that might be a
Boil the ocean schemes never work, especially not on the Web. Indeed
Allen's use of dream to describe the hope that in the far future
everything is module code is not unfair. Dreams do come true, but only
incrementally where there's local advantage.
Saw your followup to my Nope-topus post.
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.
- Matthew Robb
On Wed, Sep 10, 2014 at 1:22 PM,
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
I just think the idea of 1JS has already been compromised and really what
we have is a spec that supports two almost-entirely different sets of
expectations. The maintenance of keeping them of equal priority seems like
it will only get worse over time. The `use strict` pragma is already sort
of an
On Sep 10, 2014, at 10:33 AM, Brendan Eich wrote:
Tools will have to read metadata, tea-leaves, and etheric winds to keep up.
Same as ever.
And humans. When scanning a big directly of js files it's going to be real
useful for code readers to be able to quickly identify what they are
On 10 September 2014 19:23, Kevin Smith zenpars...@gmail.com wrote:
In NodeJS, this can be through `package.json` properties which inform
what module format the package is.
Right - although having a runtime system looking at json config files is a
terrible idea. : ) In es6now, I'm
E-S4L
N-S4L
On Sep 10, 2014, at 12:14 PM, Brendan Eich bren...@mozilla.org wrote:
Matthew Robb wrote:
Personally I have felt this way for a long time as well. I think `.esm` is
somewhat confusing since most js developers don't really think about it as
EcmaScript.
(sounds like a skin
On 10 September 2014 19:18, John Barton johnjbar...@google.com wrote:
On Wed, Sep 10, 2014 at 10:07 AM, Guy Bedford guybedf...@gmail.com
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
On Wed, Sep 10, 2014 at 10:40 AM, Matthew Robb matthewwr...@gmail.com
wrote:
I just think the idea of 1JS has already been compromised and really what
we have is a spec that supports two almost-entirely different sets of
expectations. The maintenance of keeping them of equal priority seems
Rick Waldron wrote:
On Wed, Sep 10, 2014 at 10:40 AM, Matthew Robb matthewwr...@gmail.com
mailto:matthewwr...@gmail.com wrote:
I just think the idea of 1JS has already been compromised and
really what we have is a spec that supports two almost-entirely
different sets of
But if the goal is for everything going forward to use the scope
environment characteristics of modules (strict-mode and local-global) then
why not specify that and move the old model to a legacy mode. This just
shifts all existing implementations to be compliant with legacy mode but
not yet
On Wed, Sep 10, 2014 at 11:02 AM, Guy Bedford guybedf...@gmail.com wrote:
On 10 September 2014 19:18, John Barton johnjbar...@google.com 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
Matthew Robb wrote:
But if the goal is for everything going forward to use the scope
environment characteristics of modules (strict-mode and local-global)
then why not specify that and move the old model to a legacy mode.
What old model? There's one spec. We are not forking specs. Engines
E-S4L
N-S4L
On Sep 10, 2014, at 2:13 PM, Matthew Robb matthewwr...@gmail.com wrote:
But if the goal is for everything going forward to use the scope environment
characteristics of modules (strict-mode and local-global) then why not
specify that and move the old model to a legacy mode.
I don't think it should have anything to do with modules though. It's a
fundamental change in the scoping/execution mechanics of any new script
compiled into a running environment. Previously new code compiled and run
would execute with global scope and sloppy mode. My suggestion is a pragma
you
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'
}
```
Of course
I don't see how this is not forking:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-ecmascript-language-scripts-and-modules
There are now two distinctly different models and yes they both work in the
same VM simultaneously but that's not what authors would care about.
Personally I want
I'd prefer the heading be Scripts and LegacyScripts. Just so happens that
the module features are only available in Scripts.
- Matthew Robb
On Wed, Sep 10, 2014 at 2:28 PM, Matthew Robb matthewwr...@gmail.com
wrote:
I don't see how this is not forking:
Why would it be a terrible idea to read the package.json as part of a
server-based import mechanism?
Architecturally, it should be possible to write self-describing programs.
Configuration files are good for tools (e.g. package managers and
compilers) and application settings.
Node
Here's the idea, in full:
https://github.com/zenparsing/es6now/blob/master/docs/modules.md
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Wed, Sep 10, 2014 at 10:33 AM, Brendan Eich bren...@mozilla.org 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
On Wed, Sep 10, 2014 at 11:28 AM, Guy Bedford guybedf...@gmail.com 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:
I think the point I was trying to originally make was that if you want to
take full advantage of the loader, you don't want to, in the long run,
treat CommonJS as a global script, running the NodeJS loader and System
loader both side-by-side, you want to be able to unify on a single loader.
When
On Wed, Sep 10, 2014 at 9:21 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 10, 2014, at 8:44 AM, Matthew Robb wrote:
Personally I have felt this way for a long time as well. I think `.esm` is
somewhat confusing since most js developers don't really think about it as
EcmaScript.
So... Your saying bring environmental scope to the script file... As
having it's own context execution... Like each script tag is its own iframe or
DOM environment, while in the same html page?
E-S4L
N-S4L
On Sep 10, 2014, at 2:24 PM, Matthew Robb matthewwr...@gmail.com wrote:
I don't
For what it's worth, node already deals with 'modules' versus 'plain
scripts'. The latter typically start with `#!` and are found in a `bin`
subdirectory. In case of ambiguity you can add `/* jshint ... */`
directives as necessary to select the appropriate language mode. I don't
see this as a
Wrt to the proposed `default.js` convention: node doesn't *need* to
specify a main entry point in the `package.json`. It could have chosen an
arbitrary convention.
Clearly, and it already did: index.js. My (perhaps imperfect)
understanding of history is that support for the main
55 matches
Mail list logo
