If we're going to do a mass conversion, shouldn't we try to move to ES modules? There's some support for them in SpiderMonkey for chrome code, and it would be great to move towards a future standard.
-Bill On Sat, Sep 24, 2016 at 4:16 PM, Bobby Holley <bobbyhol...@gmail.com> wrote: > If the conversion is tractable and we end up with module ergonomics that > frontend developers are happy with, I'm certainly in favor of this from the > platform side. It would get us the 15-20MB of memory savings that bug > 1186409 was pursuing without the smoke and mirrors. > > bholley > > On Sat, Sep 24, 2016 at 3:13 PM, David Teller <dtel...@mozilla.com> wrote: > > > Once again, there have been discussions on the feasibility of adding > > static analysis to our JS code, possibly as part of MozReview. As usual, > > one of the main problems is that we are not using standard JS, so we > > pretty much cannot use standard tools. > > > > One of the main differences between mozilla-central JS and standard JS > > is our module system. We use `Components.utils.import`, while the rest > > of the world is using `require`-style modules. If we could get rid of > > `Cu.import`, we would be a very large step closer towards standard JS. > > > > Which begs the question: what's the point of `Cu.import` these days? > > > > Yes, I'm aware that it isolates code in separate compartments, and that > > there is a benefit to isolating add-on code from platform code. However, > > it is pretty unclear to me that there is any benefit in separating > > compartments inside mozilla-central, rather than, say, relying upon > > static analysis and/or reviews to ensure that nobody modifies > > `Object.prototype` in funky ways. > > > > If we decide to abandon the guarantees provided by compartments to > > isolate mozilla-central modules from each other, it's not hard to > imagine: > > - semi-automated rewrites that could convert mozilla-central code to > > RequireJS-style modules, all sharing a single compartment (per process); > > - a backwards compatible, compartment-isolating implementation of > > `Cu.import` for the sake of add-ons. > > > > There would also be side-benefits in terms of memory usage, which is > > always good to have. > > > > So, can anybody think of good reason to not do this? > > > > Cheers, > > David > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
