3 ms·
I'll try to separate out the different issues you're raising here, and respond to each individually. 1. What if I want to have my module be a function, the way
by samth 15y ago
I'll try to separate out the different issues you're raising here, and respond to each individually.
1. What if I want to have my module be a function, the way that $ in jQuery is both a function and a namespace for the rest of the functionality?
This is an important use case, and so we're going to support it in ES6 modules. You'll be able to say:
module $ at "http://jquery.com/jquery.min.js";
$(...)
$.ajax(...)
2. Modules will requiring using names without the prefix.
This isn't true. As you can see in the above example, you can just use $ directly, even though it's a module. You can also say:
import ajax from $;
but you don't have to.
3. We should just standardize the node module system.
Of course, there are many different module systems being used in JS code right now, and we could just pick one. Unfortunately, we couldn't just pick the node module system, since it's fundamentally synchronous, which is great on the server side but not in the browser.
However, we feel that we can bring real advantages to JS programmers by extending the language -- we can simplify using modules, we can make some patterns direct that currently have to be written using callbacks, we can better support encapsulation, and we can allow engines to use knowledge about modules for optimization.
3. Static analysis is doable even without a static module system.
The static analysis you describe, while useful, isn't going to tell an engine statically where it can go to lookup references to an export from a module. That means it's not useful for many of the optimizations that we want to enable. Additionally, your analysis isn't sound -- it can miss uses of `require` that are generated dynamically, for example. Again, that means that engines can't use it for optimization.
Finally, if you have comments about ES development, I strongly encourage you to make them on es-discuss, rather than on HN, where they are more likely to have an impact on the development of the language.
- samth 15y agoTo make my perspective here clear, I should mention that Dave Herman (of Mozilla Research) and I are the designers of the ES6 module system.
- medikoo 15y agoI'll just add that I totally I agree with samth I'm strong user of Node.js style modules (also for client side) and I see modules as proposed for Harmony as big step forward. It's basically same concept but with dedicated syntax (well put syntax) and some extra powerful features. I've once setup some comparison how today modules written for Node.js (like modules that are functions) will look in harmony. I didn't spot any issues. See slides 86-87 at http://www.slideshare.net/medikoo/javascript-modules-done-right http://www.slideshare.net/medikoo/javascript-modules-done-ri...
- samth 15y agoSince it came up on twitter, here's how you'd implement the `$` module I describe above: export function ajax(...) { ... }; // NB: not how jQuery actually works ;) export this(query) { return document.find(query); }; The `export this` syntax specifies how the module instance object behaves when called as a function.
- substack 15y agoThanks for this. I'm glad that using a single export function will at least be possible. I'm still pessimistic about the amount of syntax being introduced here. In particular, I still really dislike the special import "local renaming" syntax since it seems so unnecessary compared to just having an import keyword that returns an object and letting the programmer extract and manipulate the relevant entries. You would still get the static analysis benefits of having static imports without all the awkward complexity of the current proposal. Wouldn't it just be the same thing to Object.freeze() the export object but without any syntax magic necessary? Plus, overloading `module` to do loading AND defining with the `module Bar at "uri"` form seems really wrong. Why can't it JUST do defining and just let import do all the loading?
- samth 15y agoFirst, if you want to just use objects-as-prefixes, the way require(...) works in node today, that's easy to do: module m at "blah.com"; ... references to m go here ... We also want to support other use cases, like binding the exports to names available in your local scope. We understand that not everyone likes that style, but I don't think the language should mandate a particular side in that fight. Second, the `module m at "URL"` form above is a definition of `m`. It's just that you're allowed to refer to that binding as an object too. Would you rather have: module m at "example.com"; import m; That just seems like unnecessary typing to me.
- substack 15y agoI mean why does `module` pull down resources? Shouldn't that be import's job?