import script --> .esm
matthewwrobb at gmail.com
Wed Sep 10 11:12:42 PDT 2014
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 compliant with the new mode. This should be fine it's mostly about
how to view and focus efforts when writing the spec, adding features, using
new features, and teaching the language.
- Matthew Robb
On Wed, Sep 10, 2014 at 2:05 PM, Rick Waldron <waldron.rick at gmail.com>
> On Wed, Sep 10, 2014 at 10:40 AM, Matthew Robb <matthewwrobb at gmail.com>
>> 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 opt-in to the new mode.
> Only in non-strict Script (
> sense. Modules (
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-modules) are
>> To me the more graceful path forward is the one where the world as people
>> know it stays the same but then there is an opt-in path for moving to the
>> supersets of the future.
> Unnecessary when nothing about the future directly changes the extant
> works of the past.
>> Dong this once after having considered many of the issues of the old
>> model seems reasonable to me specially with the amount of buy in people are
>> doing on transpilers and even buy in on other languages/runtimes such as
>> - Matthew Robb
>> On Wed, Sep 10, 2014 at 1:33 PM, Brendan Eich <brendan at mozilla.org>
>>> 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
>>> Tools will have to read metadata, tea-leaves, and etheric winds to keep
>>> up. Same as ever.
>> es-discuss mailing list
>> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss