use harmony modules

[jmesserly]

v8 tracking bug here: https://code.google.com/p/v8/issues/detail?id=1569

in general, if we wanted to start moving in a good direction, we could convert Dart libraries to object literals using the module pattern. Along with enhanced object literals we can get fairly clean top-level codegen. However it may make sense to wait for harmony module support in V8 and just target that.

[Aetet]

Hello. Is there any new about harmony module system in dart? Is work on this in progress?

[vsmenon]

We'd like to map to it, but modules are not natively supported in Chrome / V8 yet. That is blocked on spec work around the loader. See the V8 tracking bug on the original comment.

[Aetet]

Why don't use polyfill until then? https://github.com/ModuleLoader/es6-module-loader

[jmesserly]

The loader polyfill doesn't help us. Chrome won't do anything with the module syntax (import export etc).

[jmesserly]

Oops hit send too soon... Basically the way the loader polyfill works, is to transpile ES6 modules into ES5. Well DDC is already a transpiler, so we don't get benefit from that (instead, it's a cost, it will add time to reloading the app).

What I really really want is for DDC to emit ES6 modules, and for those to be the real source files that V8/Chrome loads. Or any modern browser, really :) -- now that ES6 support is landing in all of them (yay). Unfortunately I don't think anyone will parse the ES6 module syntax yet. =(

As far as transpiling ... well, we're already doing that, by transpiling your Dart code into ES6 :). We just can't get much use of modules yet.

That said ... I've been playing around with an ES6 module code gen mode, just to get a feel for it. It might be worth having it as an option. But we'd probably do the ES6 module -> ES5 lowering ourselves, so we don't need to invoke another compiler that runs after us (slow).

Hope that makes sense. Definitely keep beating the drum for modules ... IMHO it's a hugely awesome feature of ES6, and it's not happening fast enough right now.

[Aetet]

For me the main problem with dart is that I cannot just do npm install and use modules from js world, that already solve the problem. That pushes me reinvent the wheel with dart and unreliable code for production instead of using open source tools. I want to use dart with react and redux but I cannot because currently I can't just do

import react from 'react';

I don't need be always type-checked but I need reliable instruments that maintained by community in which code I can be sured. But not use Yet Another My Implementation. So that's what I wait from new dart compiler. Instrument that helps me check types where it is needed and not struggling with infrastructure and ecosystem. So for me modules will be bridge with js-world, that already solves many problems and instruments more handy.

[jmesserly]

yeah ... we definitely need to be emitting an ES5-friendly module pattern, at the very least.

Do you have an idea of what format would work best?

[jmesserly]

Oh, and we also need to make it easier for Dart import JS modules. +@jacob314

[Aetet]

I think it sure be CommonJS, because it is wide spreaded enough. And transpiled es6 code with babel can import and export such code without any problem. Closure modules is not so good encapsulated as CJS and instruments for this python and java, which force you use another techs for just for build, where you can avoid them. So my vote is for CJS.

[jmesserly]

Sounds good! I'll add a note over at #284, I think you're right, this is something we should get to soon

[jonaskello]

Even if browsers don't support them natively, I think ES6 modules would be useful right now so we can experiment with bundler tools. ES6 modules are are statically analyzable by a bundler tool such as webpack while the custom Dart module system is not. Is there a branch where ES6 module output is being worked on? I would like to experiment with it and I think I found the place to start adding it. Although it seems to be part of a large function. Could module generation be refactored into a smaller function so it would be easier to implement an alternative?

[jmesserly]

There isn't a branch yet, but we can make one! I'd previously created the js_ast nodes and have it in a local branch, let me send out a change for review.

Yes that looks like the right place.

My plan was: have js_codegen emit ES6 modules in the JS AST, and then (optionally) have a phase to convert that into ES5 to keep the compiler compatible with directly loading in Chrome.

[jmesserly]

also CC @ochafik on this one

[jonaskello]

Ah, yes, outputting ES6 modules as standard in the AST and then transforming to ES5 makes more sense than having an alternate impl. Maybe you could send your local branch to my fork? Or I'll wait until it is available in the main repo.

[jmesserly]

lots still to do, but we have preliminary ES6 as well as Node.js module support