JavaScript needs modules!

I’ve just given my breakout session, “JavaScript needs modules!“, at the Mozilla Summit. (Note: none of this is implemented yet, so please don’t take any of the code snippets too literally.)

The enthusiastic atmosphere at the summit has been palpable– it’s hard not to be in awe of my coworkers and fired up for what’s ahead for the web. For my part, I believe that modules are one of the most important upcoming features of JavaScript, and I also believe we can make them happen.

21 Responses to JavaScript needs modules!

  1. Wouldn’t it be better to instead utilize the let statement in blocks for privates and the var statement for public variables to export? That way, you can include a lib globally and the exported vars will be global, or you can include the library in function scope so all exported vars stay confined within the function. Also, you can do this right now with the current Mozilla JavaScript engines, instead of waiting for someone to implement the module pattern described in your presentation.

  2. Cannot agree more.
    Would love to be able to do a require(”) like in Node.js.

    It’s a hack but for now people can simply do the following:

    var require = function(jsfile,callback) {
    var script_tag = document.createElement(‘script’);
    script_tag.setAttribute(“type”,”text/javascript”);
    script_tag.setAttribute(“src”, jsfile);

    if(typeof callback == ‘function’) {
    script_tag.onload = callback;
    script_tag.onreadystatechange = function () { // IE
    if (this.readyState == ‘complete’ || this.readyState == ‘loaded’) {
    callback();
    }
    };
    }

    (document.getElementsByTagName(“head”)[0] || document.documentElement).appendChild(script_tag);

    };

  3. The link is to a PDF slideshow. I can discern some of what was discussed, but it would be nice to have a written transcript of the presentation. Perhaps, depending on the demand.

  4. CommonJS modules work. Build on it, don’t trash it.

  5. pc1oad1etter

    Thanks for sharing this! If it was recorded by chance, I’d love to hear/see it.

  6. Wow man. That’s some seriously cool stuff. Coming from Python world I would find this amazing. Mostly JS is great, it’s just modules I have been missing.

    Btw KISS rocks! :)

  7. module jQuery = load “jquery.js”;
    How exactly is this going to happen at compile time? Would all the scripts load before executing any javascript, or this would just load them synchronously, or maybe the rest of the code will be wrapped implicitly in a callback function? None of these are viable for the web, or at all. Other than that it adds very little functionality with a lot of syntax, which didn’t turn out to be a good strategy regarding ES4/Harmony either.

  8. We have no intention of trashing CommonJS! I feel bad that I gave that impression.

    We need to fix the mistakes of JS’s past, and we need to make it easier for people to easily structure their programs. Static modules cover those basic needs.

    But people will continue to want to create repositories of libraries that dynamically load, cache instances, handle versioning, etc. and CommonJS (or other systems like it) can continue to innovate on these fronts. We are providing some better building blocks that CommonJS should be able to leverage. That said, we aren’t tying ourselves to build directly on CommonJS because it was designed with different constraints– primarily, we can and should move the language forwards, whereas CommonJS was designed with the existing language as it was.

  9. Loading the files over the net happens at compile time, and at runtime the modules are executed in order. This is much the same as how script tags work now.

    If you want finer-grained control, or to make dynamic decisions about conditional or lazy loading, you use the dynamic loading provided by module loaders.

  10. The let/var distinction as public/private is a cute thought, though mostly just a syntax question. (Not that syntax is unimportant, but you have to settle on the semantics before the syntax.)

    As for the rest, JavaScript needs to keep growing! Just because our proposal isn’t available today doesn’t mean we shouldn’t do it.

  11. Pingback: Diskussion: JavaScript braucht Module! » t3n News

  12. Thx for sharing your session Dave! I really like the idea of javascript moduling and I hope it will become one day

  13. Pingback: JavaScript needs modules!, ctd « Dave Herman

  14. But then the new syntax seems even more pointless, since in a client side application if you have a large complex code base then you have to use lazy loading anyway (see YUI3 for example). On the other hand, if you have a smaller app then the whole module things is hardly necessary. What am I missing?

  15. I was being silly – you weren’t trashing anything.

    I do feel like there are more good things that can come from CommonJS, on the browser-side. I don’t feel that CommonJS modules are perfect.

    Question:

    Within a CommonJS project, I have many “private” modules that the end user will never touch. I “use” them within other modules like so:

    var util = require(“./util”);

    With your modules proposal, would I instead write this?

    var util = load “util.js”;

    And would I then expect the browser to fetch that file, similar to CSS @import rules?

    Thanks!

  16. khs,

    What you would write would be:

    module util = load “util.js”;

    and then you could do things like:

    import util.*;

    or just refer to parts of util directly (including submodules of util).

    And yes, the browser would fetch the file, the same way it does with today.

  17. Jules,

    First, not everything is client-side, as the success of node.js demonstrates. On the server-side, often you don’t want or need lazy loading.

    Second, even on the client-side, not every module needs to be loaded lazily. If you’re writing a substantial library, you may modularize it in a simple way, and expect clients to load the top-level module lazily. It’s important to support lazy loading well (that’s a big part of what’s hard to design about module systems), but it’s not the only concern.

  18. Have you solicited feedback from the YUI3 and google closure (goog) teams? Could be useful.

  19. @Sam TH: Sure, but introducing new syntax, which is fine for many cases but useless for large web applications, where it’s the most difficult to solve this issue… it just doesn’t feel right for me.

  20. Jules,

    The new syntax *is* useful for large web applications. For example, if you look at the jQuery source, it has multiple sections, each of which could be a module, and yet multiple parts of a file are obviously loaded synchronously. Just because the top-level import of jQuery might be done asynchronously doesn’t mean everything else must be.

    Second, not every file loaded by every large web app is loded asynchronously. For example, a quick look at the source of my Gmail window shows a use of script src=””, implying synchronous loading.

    So I think you’ll find that the syntax is useful in almost every web app.