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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
