Seems like CommonJS but with keywrords added to the language instead of magic functions/free variables. As such it's six of one, half dozen the other as far as I can tell.
From a cursory glance, this seems like mostly useless syntactic sugar. I don't exactly see what is the functional different between
module A {
export var myPublic = 1
var myPrivate = 2
}
and
var A = new function() {
this.myPublic = 1
var myPrivate = 2
}
except that the first will clash with a bunch of existing script that use "module" and "export" as variable names. And the idea of making "load" a keyword in page 26 is just plain silly.
- the goal is to not pollute the global namespace as we do today
- the module/export/load are a part of an opt-in dialect of javascript when you specify "text/es-harmony" as the language.
the goal is to not pollute the global namespace as we do today
What is the other option? The jQuery in "import jQuery.$" has to refer to something. Does he want to create a "module namespace" with special "module objects" not referenceable from normal variable scope? No thanks: that sounds like Java, not JavaScript.
the module/export/load are a part of an opt-in dialect of javascript when you specify "text/es-harmony" as the language
Why does Mozilla need to build dialects into their browser for something which can be done with a simple compiler? Between "create a little module syntax compiler which works in all browsers now" and "wait for all of the borwsers to implement the text/es-harmony dialect", I'd rather see the former.
>> the goal is to not pollute the global namespace
Right, like this, I guess
new function() {
var jQuery = ...
}
I think this document is either omitting the important details or it simply doesn't address the namespacing problem correctly. Remember when Prototype.js had a document.getElementsByClassName? Fun times when that broke.
>> the module/export/load are a part of an opt-in dialect
That doesn't seem very well thought-out. How would one access a module declared in a <script type="text/es-harmony"> from a <script type="text/javascript">? It's a pretty realistic scenario (e.g. say you have a non es-harmony codebase and you want to add a es-harmony library)
>> I think this document is either omitting the important details or it simply doesn't address the namespacing problem correctly. Remember when Prototype.js had a document.getElementsByClassName? Fun times when that broke.
Interfering with other modules' exports is not possible. But modifying the properties of arbitrary objects is just as possible as ever. Modules are all about fixing scope, not about locking down objects.
To put it differently, the document is not a module, it's an object. The module system has nothing to do with it.
>> How would one access a module declared in a <script type="text/es-harmony"> from a <script type="text/javascript">? It's a pretty realistic scenario (e.g. say you have a non es-harmony codebase and you want to add a es-harmony library)
This is accounted for in the design. The global object is not in the scope chain of Harmony code, but it is still available to Harmony code via a standard binding in the standard library, and the Harmony modules are made available to legacy JS as module instance objects in the global object. So communication is available in both directions.
>> Harmony modules are made available to legacy JS as module instance objects in the global object.
Does this mean a module is visible like this?
window.jQuery
window.Prototype
That's kinda what already exists... For that matter, any variation of that (e.g. window.modules.jQuery) can be done with the patterns you mentioned at the beginning of the document.
>> The global object is not in the scope chain of Harmony code
Ah, I see. That's certainly a new feature, but what's a use case for that? I find it hard to justify giving up a few fairly common variable names just for knowing that window.i or whatever is not polluted. It kinda feels like just shifting the name collisions around.
JavaScript 1.7 already supports a very similar module pattern. For example:
myModule: {
// don't do anything if myModule is already included
if (myModule) break myModule;
let this_is_private = ...;
var myModule = ...;
// myModule is public and won't pollute the
// global NS if it isn't included globally.
}
Joose has a Modules facility that works pretty nicely both in the browser and in other contexts, e.g. Node.js. When combined with the "use" facility of JooseX.Namespace.Depended, I think you get a similar functionality as to what's being described:
I think until there is some native namespace/module solution for JS, fusebox [http://github.com/jdalton/fusebox#readme] will fill an excellent gap (upon release, soon!!!) for this sort of need.
I am really excited about the future of Fuse and fusebox in web development. John David-Dalton's work on both is excellent, and I am happy I have been apart of the exciting development process.
Maybe in 0.8 or 0.9, Jeremy? ;-) It could "solve" the "problem" of wrapping compiled code in anonymous functions and having to attach exports to `window`.
Ah, but all of your compiled code is already wrapped in a safety function. (perhaps that's what Trevor was referring to). As for attaching to exports or window, that's going to have to be something that you do by hand regardless. If everything is added to the exports, then there's no point in wrapping in the first place...
Yes, I meant that the JavaScript "module pattern" is implemented by default, and the language prevents you from declaring globals by mistake. So, you get most of the benefits of the proposed JS module syntax.
Sorry, I should've been clearer: I meant that CoffeeScript gives you the safety benefits of modules, just by breaking your code into separate .coffee files (unless you use '--no-wrap'), since variables aren't shared unless explicitly exported.
Lua is a full programming language -- you can use it to write a complete application without depending on external third-party tools.
I usually take "scripting language" to mean "a language only suitable for combining pre-written components", since that seems to be the only useful definition. Other definitions are too broad (containing such languages as Python, Java, Haskell, and Forth) or too narrow (excluding QuakeScript, JavaScript, or Bash).
In particular, I refuse to call any language a "scripting language" merely because it uses dynamic typing, implicit compilation, or high-level concepts.
Javascript can be run at the command-line just like ruby, python, and the rest. You can write a full application in pure javascript without depending on external third party tools too -- see stuff like nodejs.
Also, I don't know of anyone that would consider Haskell to be a scripting language. If we consider Haskell a scripting language, we might as well consider Java, C, C++ to be scripting languages too...
According to the Wikipedia definition, Haskell is a scripting language (it can be dynamically typed, interpreted, embedded, etc). That's why I don't think it's a useful definition.
How do you write a full application in JavaScript? The language doesn't even define any way to open a file. NodeJS is a third-party tool -- it's not part of the JavaScript language.
While I agree that "scripting language" is a bit loosely defined (though nothing like "object-oriented"), Lua was written with a "hard and soft layers" (http://c2.com/cgi/wiki?AlternateHardAndSoftLayers) approach in mind. To me, that seems like the defining characteristic of a scripting language.
I'm not saying Lua isn't a full programming language - it's actually my language of choice for day-to-day hacking, supplemented with C as necessary. It was clearly designed to accommodate projects where it isn't primary language, though.
