Dear Ecma International, (and Dear readers, as I don't exactely know who will read this mail)

first of all, I think you do a great job standardising ECMAScript,
which I honestly am a great admirer of.

However, there is 1 (only 1) point I can't agree with: the "import" statement.
I want to state my opinion on the ECMAScript "import" statement,
which is why, as I couldn't find a GitHub issues page, I am writing you this letter.
English is not my primary language, so I hope I can explain you my opinion without misconceptions.

Since years there has been a need for a C-style "include" method,
which enables "importing" external library code into own code.
Finally, with the ES6 standard, the "import" directive has been developed,
which is a synchronous and kind of intuitive method for importing external library code.

1) However, I think the ES6 "import" doesn't conform with the general ECMAScript-style very well,
because while ES is a very dynamic scripting language, where you can choose almost everything at runtime,
"import" breaks with this style as "import" requires the name of the library to be known at "compile-time",
what makes things like
import f from (prompt("use old library, for older browsers")?"oldlib.js":"newlib.js");
impossible, which takes away a bit of dynamism from ES.
"import" should enable choosing the required libraries at run-time.

2) imports shouldn't be synchronous, as they require a file to be downloaded (probably over network).
As almost any Ajax tutorial states, synchronous file downloads over network are bad practice for various reasons.
For example, subsequent code in a file importing a library has to pause execution until the library file has loaded.
So, code in a .js file cannot execute until all libraries have loaded, which is a great impact.

imports should be asynchronous.
And, as they can either succeed (when they are successfully downloaded and parsed) or fail,
they should be tied closely to Promises.
Every import should return a Promise
that fulfills when the library is ready to use
and fails when something went wrong while loading the library.

3) imports shouldn't have their own syntax since this makes polyfilling harder.
there are already some transpilers around, but no recent transpiler can successfully transpile the following:
alert(1);
eval('import x from "mylib"; alert(x)');
alert(2);
In this short piece of code, we can see 2 downsides of current imports:
* they are synchronous, so alert(2) will not alert 2 until "mylib" has loaded.
* to execute the code, the execution environment (interpreter) has to fully support the syntax.
Instead of inventing a new syntax for imports, I would use the existing function-style syntax.
Like the following:
alert(1);
import("mylib").then(function(mylib){
	alert(mylib.x);
	alert(2);
});

4) I don't think a library should be a singleton. Rather, libraries should be kind of instantiatable classes.
Further more, one should be able to pass arguments to the library when importing a library.
But 4) is just my personal opinion based on personal experience.
However, I think 1) to 3) are important and should at least be considered.

So, in general, I think introducing imports on a language level is a great idea,
however, for implementation easement and for other reasons,
I would prefer asynchronous imports using existing syntax
instead of synchronous imports with new syntax.

Please correct me if I got something wrong.
I'm looking forward to your feedback.

Cheers,
74h7k3fg

Dear Ecma International, (and Dear readers, as I don't exactely know who will read this mail)

first of all, I think you do a great job standardising ECMAScript,
which I honestly am a great admirer of.

However, there is 1 (only 1) point I can't agree with: the "import" statement.
I want to state my opinion on the ECMAScript "import" statement,
which is why, as I couldn't find a GitHub issues page, I am writing you this letter.
English is not my primary language, so I hope I can explain you my opinion without misconceptions.

Since years there has been a need for a C-style "include" method,
which enables "importing" external library code into own code.
Finally, with the ES6 standard, the "import" directive has been developed,
which is a synchronous and kind of intuitive method for importing external library code.

1. However, I think the ES6 "import" doesn't conform with the general ECMAScript-style very well,
because while ES is a very dynamic scripting language, where you can choose almost everything at runtime,
"import" breaks with this style as "import" requires the name of the library to be known at "compile-time",
what makes things like
`import f from (prompt("use old library, for older browsers")?"oldlib.js":"newlib.js");`
impossible, which takes away a bit of dynamism from ES.
"import" should enable choosing the required libraries at run-time.

2. imports shouldn't be synchronous, as they require a file to be downloaded (probably over network).
As almost any Ajax tutorial states, synchronous file downloads over network are bad practice for various reasons.
For example, subsequent code in a file importing a library has to pause execution until the library file has loaded.
So, code in a .js file cannot execute until all libraries have loaded, which is a great impact.

  imports should be asynchronous.
And, as they can either succeed (when they are successfully downloaded and parsed) or fail,
they should be tied closely to Promises.
Every import should return a Promise
that fulfills when the library is ready to use
and fails when something went wrong while loading the library.

3. imports shouldn't have their own syntax since this makes polyfilling harder.
there are already some transpilers around, but no recent transpiler can successfully transpile the following:
```js
alert(1);
eval('import x from "mylib"; alert(x)');
alert(2);
```
In this short piece of code, we can see 2 downsides of current imports:

  * they are synchronous, so alert(2) will not alert 2 until "mylib" has loaded.
  * to execute the code, the execution environment (interpreter) has to fully support the syntax.

  Instead of inventing a new syntax for imports, I would use the existing function-style syntax.
  Like the following:
```js
alert(1);
import("mylib").then(function(mylib){
	alert(mylib.x);
	alert(2);
});
```

4. I don't think a library should be a singleton. Rather, libraries should be kind of instantiatable classes.
Further more, one should be able to pass arguments to the library when importing a library.
But 4) is just my personal opinion based on personal experience.
However, I think 1) to 3) are important and should at least be considered.

So, in general, I think introducing imports on a language level is a great idea,
however, for implementation easement and for other reasons,
I would prefer asynchronous imports using existing syntax
instead of synchronous imports with new syntax.

Please correct me if I got something wrong.
I'm looking forward to your feedback.