4 ms·

I really dislike what they're doing with modules because it's such a step back from the commonjs-inspired require() that node uses. In node, require() just retu

I really dislike what they're doing with modules because it's such a step back from the commonjs-inspired require() that node uses. In node, require() just returns a value. That value is usually an object but often it's just a function. Why should a module that encapsulates exactly one function return anything else but that one function? In ES.next, you've got to use pythonesque `import y from Bar` statements which introduce a frustrating correspondence between the lexicals of your own program and the export names of the module you're trying to use which is really terrible if you're using as many modules as I typically do. I presume ES.next will invent even more specific syntax for some sort of `as` like keyword to side-step this but it seems so unnecessary when javascript already has a module system that is so very good as is exploding in popularity and use (>7000 modules now on http://search.npmjs.org/ http://search.npmjs.org/). I understand what they're trying to do with static analysis too but you can already pretty much do that and I've done it. It's not hard at all, just ignore require() statements that don't contain strings when you walk the AST, like this: https://github.com/substack/node-detective https://github.com/substack/node-detective Inventing more syntax instead of just adopting a far better module system that has seen actual use in practical situations is such a shame and ES.next is rife with this kind of prescriptivism. It irritates me to no end and I sometimes want ES.next to die a quiet death in obscurity because of it. http://wiki.ecmascript.org/doku.php?id=harmony:modules http://wiki.ecmascript.org/doku.php?id=harmony:modules

deleted 15y ago
[deleted]
tjholowaychuk 15y ago
I agree. In general unless there is very good reason to do so I think adding to the grammar is the least elegant thing you could possibly do. Like you say it's often very helpful to effectively assign a new name to something you want to require, I do it all the time too. I really prefer the implicit scoping that we have too, not wrapping things in "module Foo { module Bar {} }" blah blah.
mcantelon 15y ago
Attempts to create big iterations on successful languages seem to consistently fail to win adoption.
- gjm11 15y ago
  C++ seems like a pretty obvious counterexample, even though it didn't call itself "C". Others: Fortran 90. Common Lisp. Visual Basic. [EDITED to add: Perl 5.] ANSI C was quite a big change from K&R, even.
  - batista 15y ago
    Not to mention: C11x (or whatever it's called), which has huge support from vendors and C++ guys, C# 4.0 that is miles ahead of C# 1.0,
Andi 15y ago
+1 (and substack is talking)
erichocean 15y ago
Totalyl agree. The lack of a module system in JavaScript has been an enormous benefit to the developer community, because it has allowed us to develop idioms that make sense in the context of JavaScript. Adopting a hard-coded, python-esque module system is a step backwards from what we have now, and I doubt will be used much, if at all -- why give up features that already exist (and will continue to work)? sigh
- batista 15y ago
  Sure, the top JS language designers in the ES6 group haven't thought of these issues...
ootachi 15y ago
You haven't considered optimization -- with closed modules, the compiler can statically know, for instance, that "Math.sin" is actually the sine function and can compile that straight down to the hardware instruction. No speculation or guards are necessary. Additionally, your static analysis must be unsound if modules are mutable. The problem is not figuring out which module is being imported, it's figuring out whether the bindings are mutated. CommonJS cannot guarantee that modules haven't been mutated. And yes, you can rename imports. Why is "var { foo: bar } = require('baz')" so much better than "import { foo: bar } from baz;"? They look the same to me, except that the ES6 one is better for static analysis and better for optimization.
- RobertWHurst 15y ago
  I don't think you get it. The right way to require a module in commonjs is var baz = require('baz'). The reason its better is because I can accomplish just as much as the ridiculous ES6 modules and its simple. We don't need to add complexity if it doesn't get us anywhere. I'm not convinced that static analysis is worth it. Existing module systems work just fine without this shit.
Baggz 15y ago
+1
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 ago
  To 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 ago
  I'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...

deleted 15y ago

[deleted]

tjholowaychuk 15y ago

I agree. In general unless there is very good reason to do so I think adding to the grammar is the least elegant thing you could possibly do. Like you say it's often very helpful to effectively assign a new name to something you want to require, I do it all the time too. I really prefer the implicit scoping that we have too, not wrapping things in "module Foo { module Bar {} }" blah blah.

mcantelon 15y ago

Attempts to create big iterations on successful languages seem to consistently fail to win adoption.

gjm11 15y ago
C++ seems like a pretty obvious counterexample, even though it didn't call itself "C". Others: Fortran 90. Common Lisp. Visual Basic. [EDITED to add: Perl 5.] ANSI C was quite a big change from K&R, even.
- batista 15y ago
  Not to mention: C11x (or whatever it's called), which has huge support from vendors and C++ guys, C# 4.0 that is miles ahead of C# 1.0,

Andi 15y ago

+1 (and substack is talking)

erichocean 15y ago

Totalyl agree. The lack of a module system in JavaScript has been an enormous benefit to the developer community, because it has allowed us to develop idioms that make sense in the context of JavaScript. Adopting a hard-coded, python-esque module system is a step backwards from what we have now, and I doubt will be used much, if at all -- why give up features that already exist (and will continue to work)? sigh

batista 15y ago
Sure, the top JS language designers in the ES6 group haven't thought of these issues...

ootachi 15y ago

You haven't considered optimization -- with closed modules, the compiler can statically know, for instance, that "Math.sin" is actually the sine function and can compile that straight down to the hardware instruction. No speculation or guards are necessary. Additionally, your static analysis must be unsound if modules are mutable. The problem is not figuring out which module is being imported, it's figuring out whether the bindings are mutated. CommonJS cannot guarantee that modules haven't been mutated. And yes, you can rename imports. Why is "var { foo: bar } = require('baz')" so much better than "import { foo: bar } from baz;"? They look the same to me, except that the ES6 one is better for static analysis and better for optimization.

RobertWHurst 15y ago
I don't think you get it. The right way to require a module in commonjs is var baz = require('baz'). The reason its better is because I can accomplish just as much as the ridiculous ES6 modules and its simple. We don't need to add complexity if it doesn't get us anywhere. I'm not convinced that static analysis is worth it. Existing module systems work just fine without this shit.

Baggz 15y ago

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 ago
To 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 ago
I'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...