On Sun, Sep 25, 2016 at 12:13:41AM +0200, David Teller wrote:
So, can anybody think of good reason to not do this?

One major problem I see with this is that we currently lazily import most modules the first time that a symbol they export is referenced. If we move to CommonJS or ES6 modules, we need to either:

a) Load essentially *all* of our Chrome JS at startup, before we even draw the first window. Maybe the static dependency handling of ES6 modules would make that more tractable, but I'd be surprised.

b) Manually import modules whenever we need them. That might be doable in CommonJS or with the proposed future dynamic imports of ES6, but with a lot of additional cognitive overhead.

c) Use CommonJS, but with a lazy import helper. I wouldn't mind that approach so much, but I think that it would pretty much nullify any advantage for static analysis.

or,

d) Some hybrid of the above.

Frankly, I've been considering transitioning the code I work with to CommonJS for a while, mainly because easier for outside contributors to cope with (especially if they're used to Node). Cu.import tends to hide the names of the symbols it exports (which shows in how often our ESLint hacks fail to guess at what it exports), and even defineLazyModuleGetter takes some getting used to.

The main things that have been stopping me are the lack of support for lazy imports, and the unfortunate impact that the SDK loader has on debugging, with its mangling of exceptions, and the source URL mangling imposed by the subscript loader. But those problems can be overcome.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to