Hi Lorenzo, almost all of your requests are covered by a related imperative
loader API,
http://whatwg.github.io/loader/#loader-import
This work is not quite complete and thus not well described but your goals
will be met with this API.

jjb

On Thu, Jan 7, 2016 at 8:30 AM, Lorenzo Ferrara <lorenzo.ferrara at gmx.at>
wrote:

> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160107/299eca85/attachment.html>

almost all of your requests are covered by a related imperative
loader API,
http://whatwg.github.io/loader/#loader-import
This work is not quite complete and thus not well described but your goals
will be met with this API.