domenic at domenicdenicola.com (2013-09-08T01:05:05.998Z)
That's how Caja currently deploys. If [feature detection](https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js) says the browser adequately implements ES5, we deploy the (approximately no translation) [SES-on-ES5 implementation](https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/). Otherwise we fall back to Caja's [ES5-to-ES3 translator (ES5/3) and runtime](https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/es53.js). You can see the effect by visiting http://caja.appspot.com/ and watching the menu whose state starts in "Autodetect Mode" and then switches to either "ES5 Mode" or "ES5/3 Mode" depending on this autodetection decision. It is a menu so that you can also override this by manually forcing the choice you'd like. As you can see from [repairES5.js](https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js), the autodetection is tricky because browsers only gradually implemented more and more of ES5 and few implement it completely. But the autodetection has to judge when they implement enough to be considered an ES5 browser. I expect the same will be true for the ES5 to ES6 transition. You can also see the outcome of the individual tests used in this autodetection at http://google-caja.googlecode.com/svn/trunk/src/com/google/caja/ses/explicit.html, or by watching the console when visiting http://caja.appspot.com/.
On Thu, Sep 5, 2013 at 4:27 AM, Axel Rauschmayer <axel at rauschma.de> wrote: > In principle, you could serve different files to different browsers: > > – Browser supports ES6 => serve an ES6 .js file > – Otherwise => compile ES6 to ES5 (or ES3) > > What is the best way to do this? > > – Browsers tell servers their level of ECMAScript support? > – You can do a feature detection in JS and then load modules > conditionally? But that seems like a more complicated solution. I’m not > even sure how I would implement the detection part. > That's how Caja currently deploys. If feature detection < https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js> says the browser adequately implements ES5, we deploy the (approximately no translation) SES-on-ES5 implementation < https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/>. Otherwise we fall back to Caja's ES5-to-ES3 translator (ES5/3) and runtime < https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/es53.js >. You can see the effect by visiting <http://caja.appspot.com/> and watching the menu whose state starts in "Autodetect Mode" and then switches to either "ES5 Mode" or "ES5/3 Mode" depending on this autodetection decision. It is a menu so that you can also override this by manually forcing the choice you'd like. As you can see from < https://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/repairES5.js>, the autodetection is tricky because browsers only gradually implemented more and more of ES5 and few implement it completely. But the autodetection has to judge when they implement enough to be considered an ES5 browser. I expect the same will be true for the ES5 to ES6 transition. You can also see the outcome of the individual tests used in this autodetection at < http://google-caja.googlecode.com/svn/trunk/src/com/google/caja/ses/explicit.html>, or by watching the console when visiting <http://caja.appspot.com/>. > > -- > Dr. Axel Rauschmayer > axel at rauschma.de > > home: rauschma.de > twitter: twitter.com/rauschma > blog: 2ality.com > > > _______________________________________________ > es-discuss mailing list > es-discuss at mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130905/9811cc00/attachment-0001.html>