Reply inline.
On Donnerstag, 7. Januar 2016 17:30:08 CET, Lorenzo Ferrara wrote:
> Dear Ecma International, (and Dear readers, as I don't exactely know who
> will read this mail)
Actually, you're posting to a mailing list whose members may include whoever
subscribes to it. But skimming over your text, this seems like the right place
to discuss your issues.
>
> 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.
This was a deliberate design choice, since this goes hand in hand with static
code analysis. Although slightly outdated, you might want to read [this]
(http://www.2ality.com/2014/09/es6-modules-final.html).
If you DO need to dynamically import modules, have a look at the [Module
Loader API](https://whatwg.github.io/loader/#loader-import) (which introduces
a global variable named `System`, allowing for these kinds of things).
You can read about it [here](http://exploringjs.com/es6/ch_modules.html),
starting with section 16.5.
>
> 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.
The Module Loader API is actually promise-based, which makes this point moot,
I suppose.
>
> 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);
> });
First of all, I strongly disagree: New syntax can't always be transpiled,
since sometimes, there's no way to express it in an earlier version of the
language (compare `Proxy` for instance). This isn't a bad thing; it's actually
really important to a lot of us to extend the descriptive power of the
language, especially since JS has become a "transpile-to language" for many
other languages.
Now, how to load modules isn't actually part of ES6 but has been deferred to
the Loader API. You might want to check out SystemJS if you need something
close to what browsers will implement soon. Right now, what you need to do
when transpiling your code is also transforming it into your module system of
choice (AMD, CommonJS, SystemJS, UMD, your custom system, …) before handing it
over to environments such as browsers. Babel is very capable of doing this,
and it has been for over a year, IIRC.
>
> 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.
What do you mean? Something like:
```js
import jQuery from "jquery";
let jQueryInstantiation = new jQuery();
```
seems overly verbose to me, at least for the sole purpose of getting an
instantiation of jQuery. It seems like this is rather something a person with
a Java-esque background would do. There are often times where librarys are
really instantiable [classes](https://github.com/tvcutsem/harmony-reflect), so
what's your point exactly?
>
> 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
