5 ms·

JavaScript needs modules

• sant0sk1 16y ago
  Direct link to pdf: http://www.ccs.neu.edu/home/dherman/talks/javascript-needs-modules.pdf http://www.ccs.neu.edu/home/dherman/talks/javascript-needs-m...
• lhorie 16y 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 16y 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.
    • deleted 16y ago
      [deleted]
    • lhorie 16y 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)
      • dherman 16y ago
        >> 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.
        • lhorie 16y ago
          >> 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.
    • andreyf 16y 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.
      • DjDarkman 16y ago
        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.
  • deleted 16y ago
    [deleted]
• grayrest 16y 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 16y 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. }
• TrevorBurnham 16y ago
  You can get modules right now, in every browser, with CoffeeScript. It compiles nicely to standard JS: http://coffeescript.org http://coffeescript.org
  • endtime 16y ago
    I'm a big fan of CS, but I wasn't aware it has module support. Are you talking about the class system?
    • TrevorBurnham 16y 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.
  • jashkenas 16y ago
    CoffeeScript does many things at the language level, but modules is not one of them.
    • endtime 16y 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`.
      • jashkenas 16y ago
        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...
        • endtime 16y ago
• wslh 16y ago
  It's a shame that somebody point at this obvious feature on 2010. Javascript lacks a lot of features from scripting languages.
  • jmillikin 16y 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 16y ago
      Lua has packages. http://www.lua.org/pil/15.html http://www.lua.org/pil/15.html
    • lunchbox 16y ago
      Python, Perl, Ruby, Lua, R, Matlab, etc...I can think of more that do than don't.
      • jmillikin 16y ago
        None of those are scripting languages, except maybe Matlab -- I haven't used it enough to say. Just because a language is dynamically typed doesn't make it a "scripting language".
        • melvin 16y ago
          Dynamically typed, no. Interpreted, yes.
          • jmillikin 16y ago
            JavaScript is typically implemented with a JIT compiler, just like Java or C#. Python, Ruby, and Lua use virtual machines (like Java used to be).
            • 16y ago
• wallfly 16y 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/Joose/Manual/Construction.html http://openjsan.org/doc/s/sa/samuraijack/Joose/3.010/lib/Joo... http://openjsan.org/doc/s/sa/samuraijack/JooseX/Namespace/Depended/0.05/lib/JooseX/Namespace/Depended.html http://openjsan.org/doc/s/sa/samuraijack/JooseX/Namespace/De...
• invisible 16y ago
  I think until there is some native namespace/module solution for JS, fusebox [http://github.com/jdalton/fusebox#readme 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 16y ago
  I think it is better to replace JavaScript with a more powerful language like C
  • nijikunai 16y ago
    It's all about using the right tool for the job.
• jerome_etienne 16y 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
• access_denied 16y ago
  The later part of this presentation by Robernt Nyman show another point of view. He shows how you can work without polluting the global namespace and presents a somwhat philosophical conclusion that Javascript is not C or Java but seomthing else and we shouldn't try to treat it as such. http://blip.tv/file/3004532 http://blip.tv/file/3004532