Hacker News new | comments | show | ask | jobs | submit login

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.



You missed two bits:

  - 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.


Because the Mozilla developers are the same wise guys who think IndexedDB is superior to SQLite!

If they keep this up, web developers will eventually abandon Firefox. Firefox is starting to be the new IE6.


>> 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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: