JavaScript Modules

by steveklabnik • 12 years ago

169 73 12 years ago

jlongster4• 12 years ago

I kind of wish this was posted tomorrow in the morning so a lot more people would see it. It's crucially important for JavaScript.

roryokane• 12 years ago

According to http://kangax.github.io/compat-table/es6/, absolutely no browsers support JavaScript Modules yet; only the Traceur compiler[1] and EchoJS compiler[2] do. I would not call this feature “crucially important” yet.

[1] https://github.com/google/traceur-compiler [2] https://github.com/toshok/echo-js

ollysb• 12 years ago

The ember community has really embraced ES6 modules and now with the introduction of broccoli[1] and the broccoli-es6-transpiler[2] it's really easy to start using modules and the other ES6 features right now. If you're already using SASS or Less then an ES6 transpiler seems like a natural next step.

[1] https://github.com/broccolijs/broccoli [2] https://github.com/sindresorhus/broccoli-es6-transpiler

jlongster4• 12 years ago

Besides the points made by the sibling comment, this feature is crucially important to JavaScript. It hasn't been implemented yet because the spec itself is just now being finalized. This page was made in an effort to spread the word about the upcoming modules, which people really need to see now and understand because it's going to be a big change.

I don't see how it still can't be crucially important.

kybernetikos3• 12 years ago

Including three script tags into your page - traceur, es6-module-loader and systemjs lets you use all this today.

steveklabnik• 12 years ago

Sounds very-US centric ;) A lot of Europeans will hopefully learn about it too!

jlongster4• 12 years ago

Good point, hadn't thought about that. Glad it's getting views! :)

wereHamster2• 12 years ago

It is morning, 6:22am to be exact. Not all developers live in the US.

baddox• 12 years ago

And I suspect far fewer live in your time zone.

jonpaul2• 12 years ago

The problem with introducing new keywords and doing this in a backwards incompatible way, is that we'll be running with three module systems for years: CommonJS, AMD, and ES6. As far as I can tell, and please correct me if I'm wrong, it looks like ES6 modules aren't solving any new problem that CommonJS did not solve. Browserify does an excellent job of bringing CommonJS to the browser and it's gaining a lot of momentum. With ES6 now pushed back until June 2015... I'm not sure what to think anymore.

netghost• 12 years ago

I'm sort of assuming it can be ignored for now. Like you said, it doesn't add anything, but also doesn't preclude anything that we can do today, so it seems like a wash.

jlongster4• 12 years ago

It adds a lot of stuff, and I think this site is going to add more explanation about that. I'm not fully qualified to go into everything, but off the top of my head:

* The dependencies are static, so you can't do stuff like `if(Math.random() < .5) { require('foo') } else { require('bar') }`. That is a good thing. A lot of people at this point agree that a statically analyzable dependency graph is a huge win.

* Bindings are truly exported. If you exported `const foo = 5`, imported it in another module, and tried to change it, you would get a static error. Semantics and identity of bindings carry over. This also means they are mutable; if the module exporting `foo` changes it everyone else will see it too.

* A fleshed out module loader API, which is seriously lacking in node

There are other advantages too. The simplistic approach of CommonJS works, but long-term it's not the best solution for the wide use-cases of JavaScript.

EDIT: and this will be backwards-compatible. I don't know all the details but this can be implemented in a browser today without breaking things (I know people on the teams working on this)

notduncansmith• 12 years ago

The simplistic approach of CommonJS works, but long-term it's not the best solution for the wide use-cases of JavaScript.

Could you elaborate on this point a little more? I've worked on Node.js projects varying greatly in size, and even on the larger ones I've yet to feel encumbered the CommonJS module system.

nawitus4• 12 years ago

The ES6 module system could still use ES6 inspired syntax. (Or even TypeScript's syntax, e.g. import x = require("x");).

cwmma2• 12 years ago

The dependencies are static, so you can't do stuff like `if(Math.random() < .5) { require('foo') } else { require('bar') }`. That is a good thing. A lot of people at this point agree that a statically analyzable dependency graph is a huge win.

yeah but the 80% solution of loading them both statically but only executing them when the require is run works ridiculously well in practice.

streptomycin• 12 years ago

Won't people use a pre-processor for ES6 modules, like they do for CommonJS and AMD? Otherwise, it'd be a lot of HTTP requests. So you wouldn't have to wait for browser support to start using ES6 modules.

aroman• 12 years ago

And Node?

kybernetikos3• 12 years ago

Probably. This is indeed how I see most es6 development going for a while, but many servers already support SPDY which allows the server to push things into the clients cache that it knows they will need. This basically removes the need for bundling, while keeping the advantages of separate files.

BinaryIdiot• 12 years ago

This. I can't imagine, except maybe in a development mode, where I would want all of these different modules loading at different times especially if they're loading later rather than referencing the script in the HTML's HEAD.

CMCDragonkai• 12 years ago

Check out webpack

kybernetikos3• 12 years ago

ES6 modules are actually a nice combination of the asynchronicity of AMD (really required in a browser) and the code clarity of commonJS, so it's not really the case that it's not solving anything that commonJS doesn't solve. It also deals with circular dependencies better than CommonJS.

On top of that, module loaders provide hooks, so it's quite possible to use a module loader (e.g. System.JS) that can load commonjs or amd modules.

Browserify is brilliant, and if I couldn't use es6 I'd be using it, but I'm pretty excited about es6 modules.

canadev• 12 years ago

Modules are a good thing.

I quite like npm as far as package managers go (the default installation directory being ./node_modules is a big improvement over the global rubygem directory, IMO).

All the same, I don't mean to be overly negative but code like this is why I am not a fan of JS:

var isNode = typeof process !== "undefined" && {}.toString.call(process) === "[object process]";

I mean, I am no JS expert but it took me a couple of minutes just to parse this thing, and this is the next generation. I just don't like it.

jonpaul2• 12 years ago

Browserify is great for npm/CommonJS modules on the browser side. Also, you can just check if `process.browser` is defined. =)

nawitus4• 12 years ago

The main problem with npm is that it's a module manager for JavaScript files. As applications scale, you need to start packaging other files in addition to .js files, and npm doesn't support it.

You can try to create workarounds and hacks, but that's pretty much building a new package manager on top of npm.

The core problem is that if your package depends on another package, it's impossible to know the location of that package (no, it's not always or even often under node_modules).

There's of course a lot of other problems with npm I've noticed..

couchand5• 12 years ago

Can you elaborate with more details? In my experience it's flexible and predictable. Folks seem to be able to package C++ extensions to Node well enough on npm. What else would you like to package? What other problems have you noticed?

russellsprouts• 12 years ago

While a module system in JavaScript will be useful, this seems overly complicated.

I like Lua's approach to modules. In Lua, a file is basically equivalent to a function body. It accepts arguments and can return values. In JavaScript, this is not allowed.

In Lua, a function can accept multiple arguments in a tuple called `...`. Every file is implicitly a vararg function, so we can unpack the `...` to get arguments.

    > add.lua
      local a,b = ...
      return a + b 


    > file.lua
      local add = load 'add.lua'
      print(add(1,2)) --> 3

load takes a file path and returns that source file as a function. Most files ignore arguments, but they do return values.

    > add2.lua
      return function(a,b) return a + b end

    > file2.lua
      local add = require 'add'
      print(add(1,2))

`require` loads a source file, executes it, and returns the value that it returns. It is similar to `return load(fileName)()`, but it also has a search mechanism, and caches the result. So, the Lua equivalent of export default is simply returning a value at the end of a source file.

The named exports are also easy to replicate. You simply return an object with the keys you want.

    > math.lua
      return {
        add = function(a,b) return a + b end,
        sub = function(a,b) return a - b end
      }

    > other.lua
      local math = require 'math'
      local add, sub = math.add, math.sub

You can also have something similar to the `export function name(){}` declaration.

    > hello.lua
      local exports = {}

      function exports.hello()
        print "Hello World"
      end

      exports.VERSION = '0.0.1'

      return exports

    > file3.lua
      local hello = require'hello'.hello
      local version = require'hello'.VERSION

      hello() --> Hello World

In all, I think the Lua's require is a much cleaner way to implement modules. Unfortunately, it cannot handle circular references. It may be possible to add this feature using Lua's coroutines, however. I will have to research how it is handled in JavaScript to be sure.

pcwalton• 12 years ago

In all, I think the Lua's require is a much cleaner way to implement modules.

The idea behind ES6 modules is to add static name resolution to JavaScript. Because of the incredibly dynamic nature of JS, you can never know what any global name resolves to, as it could change at a moment's notice. The same is true in Lua's module system: `_G` is completely mutable and it (or its metatable!) can change at any time, altering the bindings in the program.

I personally feel that, given how JavaScript is getting used in larger and larger codebases, some measure of static checking was long overdue.

oblio2• 12 years ago

Unfortunately, it cannot handle circular references.

Wouldn't this be bad design in 99% of circumstances anyway? I say 99% because I don't want to be categorical, personally I think circular references/dependencies are always bad on some level.

jiyinyiyong• 12 years ago

It can be great if published before CommomJS existed. It's a bit annoying when people have embraced CommonJS. It aleady took me a lot time choosing between CommonJS AMD and CMD. Please end this war as son as possible.

pje• 12 years ago

    > var isNode = typeof process !== "undefined" &&
    >              {}.toString.call(process) === "[object process]";

WHAT DO YOU THINK YOU'RE RUNNING FROM?! THE DISEASE IS INSIDE OF YOU!

pekk• 12 years ago

Can you clarify?

oblio2• 12 years ago

Well, back off from your Javascript knowledge a little and try to figure out if the intention of the code is readable.

As an outsider is seems... cryptic.

modarts• 12 years ago

Hate to come off as a Luddite, but why should I care about this when we have a really nice solution in the form of CommonJS + Browserify?

thealphanerd• 12 years ago

I think this is due to the fact that not every has ability / desire to live in the console. Having a development process that can work without a compile step is important.

warfangle4• 12 years ago

browserify + watch ... run it and forget it

bonus points because you can hook a linter into it.

couchand5• 12 years ago

It's really sad to me that this is the best explanation I've heard so far for reinventing CommonJS in ES6 and it still falls flat on its face.

ripter2• 12 years ago

CommonJS is not an official standard that is part of the language. It works, but it's also competing with AMD.

ES6 Modules officially add modules to the language. It gives a standard that should work in browser and in node. It's heavily inspired by CommonJS and AMD.

efnx• 12 years ago

Would it be impossible for browsers to include support for more than one scripting language? I've never looked at the architecture of browsers but it would be fun to run pychrome or haskafari.

Just because we all got on the js train doesn't mean we have to ride it till the end.

I guess this is why there are so many cross compilers from x -> js. Thanks be to those guys. Cheers.

cypher543• 12 years ago

Dartium (https://www.dartlang.org/tools/dartium/) is a version of Chromium with both JavaScript and Dart VMs running side-by-side, so it's certainly possible. Of course, getting every major browser developer to adopt a new scripting language is a completely different story.

kyrra• 12 years ago

It is a lot of work. WebKit didn't want it in their code base, but blink is experimenting with it with oilpan[0]. It would also take a lot of work in Firefox to do. The big issue is having both runtimes executing in the same DOM. handling garbage collection becomes a lot more complicated.

[0] http://www.chromium.org/blink/blink-gc

ksherlock• 12 years ago

IE used to support JScript and VBScript out of the box. I think you could also install ActiveState PerlScript to run perl in the browser, too.

Chrome supports JavaScript and Dart.

dreamdu5t• 12 years ago

Pointless. CommonJS rocks. Browserify with a watcher and forget about it.

alessioalex• 12 years ago

true that, CommonJS and Browserify are so simple and proven that I don't even get the effort for ES6 modules.

Kiro• 12 years ago

Or QuickStart (from Spotify) and you don't even need a watcher.

pmontra• 12 years ago

The syntax is better than the CommonJS one. Check the side by side comparison at http://jsmodules.io/cjs.html However CommonJS is here now and JS engines might take a while to implement the new syntax. Example: the => (which is in the same ES6 draft) works in FF since version 22 and not in V8 yet. http://wiki.ecmascript.org/doku.php?id=harmony:specification...

178• 12 years ago

That is not an honest comparison, though.

    import { getCodec } from "iconv-lite";

would be

    var getCodec = require("iconv-lite").getCodec;

couchand5• 12 years ago

Or in CoffeeScript,

    {getCodec} = require "iconv-lite"

Explicit dependencies without introducing new syntax? Yes, please.

aikah• 12 years ago

A language module system shouldnt depend on a build tool or a third party library,so javascript modules are more than welcome.

The transition from ES5 to ES6 will be something interesting to live.ES6 is a paradigm shift for Javascript.

guiomie• 12 years ago

"We’re going to build a simple asap module, which lets you schedule some work to happen as soon as possible, but asynchronously. In Node.js, you can do this via process.nextTick," ... I thought process.nextTick wasn't the equivalent to an async, and that async could only be done in native modules ... Can someone correct me or the author?

Touche7• 12 years ago

process.nextTick is a native module. You can test this simply yourself:

    var a = 1;
    process.nextTick(function() {
      console.log(a);
    });
    a = 2;

phleet• 12 years ago

Can someone explain to me the migration path towards ES6 and syntax like this? This isn't syntactically valid ES5, so is there a reasonable path to making the browsers run ES6 directly?

If I just include it in a <script> tag directly, it'll throw syntax errors in any non-es6 compliant browser. So I'd have the transpile, and send down the es5 version of the code.

But if I'm transpiling, what's the point? I still have a build step, so why use ES6 over another compile-to-js language? The eventual promise, that years and years and years from now, all the non-es6 compliant browser will be dead, so I can send down the es6 code directly?

ripter2• 12 years ago

script supports a new type, module.

    <script type="module">
        // loads the 'q' export from 'mymodule.js' in the same path as the page
        import { q } from 'mymodule';

        new q(); // -> 'this is an es6 class!'
    </script>

You can use it today with things like : https://github.com/ModuleLoader/es6-module-loader

eleith• 12 years ago

Coursera is hosting a tech talk on 7/23 in mountain view where james burke (author or require.js) will be speaking about javascript modules.

drderidder• 12 years ago

I'd have preferred support for Common JS (or closer to it), which doesn't seem to suffer from the namespacing and syntax issues raised by this new spec. Importing to the global namespace by default seems kinda dodgy, and the mechanisms to avoid name collisions are syntactically awkward, imho. I think this proposal might actually have cemented the long-term popularity of browserify for years to come.

JavaScript Modules

Related Stories