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.ferr...@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@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss