Module import syntax (leading / trailing from)

[Maël Nison]

Hi,

It's probably too late to raise an objection, but anyway.

I've tried to find out the rational for the "import [...] from [...]"
syntax (rather than the common "from [...] import [...]"), and only found
the following old thread :
http://esdiscuss.org/topic/simpler-sweeter-syntax-for-modules, especially
this sentence :

I came to this because earlier versions of the syntax were inconsistent
> about whether from meant the-module-itself or an-export-of-the-module,
> which made it even more confusing. This new syntax was inspired by Python,
> but with import as the leading keyword, rather than from. Which is what
> leads to the inversion of order.


However, I'm still not quite sure to understand why is the "import" key
leading here. It sounds definitely better when speaking (since it's correct
valid english), but I don't find it very nice when wrote in a source code.

For example, I've got a lot of source code in multiple languages where the
imports are sorted according to their categories (vendors / app) and name,
ie something like :

    define( [

        'vendors/Backbone,
        'vendors/Underscore',
        'vendors/JQuery',

        'models/Note',
        'models/Users',
        'views/Note',
        'views/User',
        'settings'

    ], [...] )

Using the ES6 syntax, however, comes to :

    import { Backbone } from 'vendors/Backbone';
    import { _ }        from 'vendors/Underscore';
    import { $ }        from 'vendors/JQuery';

    import { NoteModel : Note, UserModel : User } from 'models';
    import { NoteView : Note, UserView : View }   from 'views';
    import { MAX_NOTES }                          from 'settings';

The pythonic syntax ("leading from") would have been

    from 'vendors/Backbone'   import { Backbone };
    from 'vendors/Underscore' import { _ };
    from 'vendors/JQuery'     import { $ };

    from 'models'   import { NoteModel : Note, UserModel : User };
    from 'views'    import { NoteView : Note, UserView : User };
    from 'settings' import { MAX_NOTES };

Which, I think, is clearer : the reader knows what are the components used
by the module at the first glance. A "trailing from" sounds more difficult
to read, since it may be at the right of the screen (or even hidden
depending on the screen width).

I would also argue that knowing the module is more important than knowing
the symbols, since multiple modules can export the same symbols, and then
the reader has to parse the destructuring import to know what is the symbol
purpose (or look at the right).

Finally, symbols are often added / removed in a source code. However, a
module name doesn't often change. Using a "trailing from" may be a burden
for OCD-driven developers who like to keep some kind of indentation inside
their code.

    import { NoteModel : Note, UserModel : User } from 'models';
    import { MAX_NOTES }                          from 'settings';

Which becomes after a new feature

    import { NoteModel : Note, UserModel : User, ReferenceModel : Reference
} from 'models';
    import { MAX_NOTES }
   from 'settings';

Then again after a refactoring

    import { BookModel : Book, UserModel : User } from 'models';
    import { MAX_NOTES }                          from 'settings';

The issue also arises in some extreme cases (this example comes from
Traceur) :

    import { ARGUMENT_LIST, ARRAY_LITERAL_EXPRESSION, BINARY_OPERATOR,
BINDING_IDENTIFIER, CALL_EXPRESSION, [...], PAREN_EXPRESSION,
PROPERTY_NAME_ASSIGNMENT, REST_PARAMETER, SYNTAX_ERROR_TREE } from
'./trees/ParseTreeType';

In such a case, it's not very clear which is the module holding those
symbols (our eyes are trained to read from the top to the bottom, and I
think there's also a pythonic legacy which attracts the eyes at the top to
find the module name).

That's a purely cosmethic note, and I'm very satisfied by the current
direction of ES6; I was just wondering if this point had been discussed
before.

Thanks,

-- 
Maël Nison (arcanis <https://twitter.com/arcanis>)
Frontend Developer @ Sketchfab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140611/dee03781/attachment-0001.html>