JavaScript needs modules

http://blog.mozilla.com/dherman/2010/07/08/javascript-needs-modules/

by sant0sk1 • 16 years ago

47 37 16 years ago

blog.mozilla.com

sant0sk1• 16 years ago

Direct link to pdf: http://www.ccs.neu.edu/home/dherman/talks/javascript-needs-m...

lhorie3• 16 years ago

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.

bokchoi• 16 years ago

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.

lhorie3• 16 years ago

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

andreyf• 16 years ago

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.

grayrest• 16 years ago

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.

Sephr• 16 years ago

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

TrevorBurnham3• 16 years ago

You can get modules right now, in every browser, with CoffeeScript. It compiles nicely to standard JS:

http://coffeescript.org

endtime3• 16 years ago

I'm a big fan of CS, but I wasn't aware it has module support. Are you talking about the class system?

TrevorBurnham3• 16 years ago

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.

jashkenas2• 16 years ago

CoffeeScript does many things at the language level, but modules is not one of them.

endtime3• 16 years ago

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

wslh• 16 years ago

It's a shame that somebody point at this obvious feature on 2010. Javascript lacks a lot of features from scripting languages.

jmillikin5• 16 years ago

Javascript is a scripting language -- and off the top of my head, I can't think of any scripting language with modules (maybe VBScript?)

tung• 16 years ago

Lua has packages.

http://www.lua.org/pil/15.html

lunchbox• 16 years ago

Python, Perl, Ruby, Lua, R, Matlab, etc...I can think of more that do than don't.

wallfly• 16 years ago

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:

http://openjsan.org/doc/s/sa/samuraijack/Joose/3.010/lib/Joo...

http://openjsan.org/doc/s/sa/samuraijack/JooseX/Namespace/De...

invisible• 16 years ago

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.

known• 16 years ago

I think it is better to replace JavaScript with a more powerful language like C

nijikunai• 16 years ago

It's all about using the right tool for the job.

jerome_etienne• 16 years ago

Please dont break compatibility when it is possible to avoid it.

js is coming to the server quite nicely, most modern browsers support it well too... Even microsoft starts to take the web seriously with IE9.

I am not convinced mozilla fondation is in its role breaking compatibilities when avoidable

JavaScript needs modules

Related Stories