Discuss
  • Module import syntax (leading / trailing from)

Module import syntax (leading / trailing from)

# Maël Nison (11 years ago)

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 : 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,

# Andrea Giammarchi (11 years ago)

I think I was still using tabs when I've written a semantic import that used from upfront [1]

However, it depends how you look at your imports ... when you read

import { _ } from import { $ } from import { gzip } from

you realize you don't even need to know where does that come from since the semantic name used with the import is what you are looking for your script, not in your folder structures.

+1 for the current import { A } from "I don't really care where A comes from"

My 2cents

[1] webreflection.blogspot.com/2007/04/semantic-import.html