On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf
<calvin.metcalf at gmail.com> wrote:
> They curly braces only look like destructuring if you keep the name the
> same, when imported with a different name it's a slightly different syntax,
> {oldname as newname} not {oldname: newname}, also as it currently stands

I wish that the authors of the module spec would accept that "object
as module" is something JS authors have gotten used to.  It's rather
nice that we don't have to add another "module" type to our mental
model.  I understand that the spec authors want to insert some magic
mechanisms so that cyclic dependencies "just work", but that shouldn't
require us to invalidate our simple mental model for the common case.

Using destructuring syntax for imports would be a *good thing*.  It
builds on our existing understanding of JS constructs, instead of
adding more gratuitously different things to learn.

Similarly, I like the proposal floated here on es-discuss that reuses
the same syntax for "default exports", so that the user doesn't have
to know whether the module author did a default export of an single
object, or used exports of named functions.  The syntax should help
the developer by papering over these differences so that destructuring
and uses were consistent.  Sure, there would be some subtle
differences under-the-covers regarding the type of the module object
and how the destructuring assignment was implemented, but the syntax
shouldn't make the user stumble over these.
  --scott

> On Mon, Jun 16, 2014 at 8:53 AM, Calvin Metcalf <calvin.metcalf at gmail.com> wrote:
> 
> They curly braces only look like destructuring if you keep the name the
> same, when imported with a different name it's a slightly different syntax,
> `{oldname as newname}` not `{oldname: newname}`, also as it currently stands

I wish that the authors of the module spec would accept that "object as module" is something JS authors have gotten used to.  It's rather
nice that we don't have to add another "module" type to our mental model.  I understand that the spec authors want to insert some magic
mechanisms so that cyclic dependencies "just work", but that shouldn't require us to invalidate our simple mental model for the common case.

Using destructuring syntax for imports would be a *good thing*.  It builds on our existing understanding of JS constructs, instead of adding more gratuitously different things to learn.

Similarly, I like the proposal floated here on es-discuss that reuses the same syntax for "default exports", so that the user doesn't have
to know whether the module author did a default export of an single object, or used exports of named functions.  The syntax should help
the developer by papering over these differences so that destructuring and uses were consistent.  Sure, there would be some subtle
differences under-the-covers regarding the type of the module object and how the destructuring assignment was implemented, but the syntax shouldn't make the user stumble over these.