All content DOM workers use JSVERSION_DEFAULT unless the
"dom.workers.latestJSVersion" pref is set to true. (Note: you need to
manually add the pref in about:config.) Chrome workers get
JSVERSION_LATEST. There is no way to tell the worker to use a specific
JS version like we can do in page content by using the version parameter
on the MIME type for script tags.
JSVERSION_DEFAULT on trunk currently makes it impossible to use nice
things like "let" and apparently at least some uses of "yield". This is
problematic for some Firefox OS/B2G work where we are faced with needing
to use a transpiler like Babel or not having nice things. (I am
speaking for the email and calendar apps at this time on work targeted
for v3 or whatever the next major release ends up being.)
I'm writing for guidance on how to address this problem in the near
term. It seems like the things that can happen are:
A) The JS concept of versions goes away, at least for web content and
ES6 features (in the next few weeks). This covers things like
https://bugzil.la/855665 on making let work without requiring JS 1.7.
B) Have DOM workers use some JS version other than DEFAULT. It seems
like there could be web-compat isues with JS1.7/JS1.8 in their entirety,
but perhaps a stop-gap version could be introduced.
C) Let DOM workers inherit the version of their calling context as
proposed in https://bugzil.la/1151739 so the version parameter is
effectively propagated.
D) Some other means of allowing explicit DOM worker versions to be
specified.
E) B2G-Specific:
E1) Set "dom.workers.latestJSVersion" for only B2G's trunk, which has no
releases planned for the foreseeable future.
E2) On B2G have certified apps get JSVERSION_LATEST since that's where
we hide dangerous things where there's an explicit burden on the apps to
stay up-to-date with potentially breaking changes.
F) Just use the Babel transpiler for now for workers at the cost of not
being able to provide feedback to the JS engine in cases where it's not
practical to flip the preference. Many FxOS apps already use AMD-style
module loaders that support loader plugins
(http://requirejs.org/docs/plugins.html) that support both dynamic
transpiling and optimized build-time transpiling, and one exists for
Babel already (https://github.com/mikach/requirejs-babel).
Thanks,
Andrew
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
