Alternative proposal to privateName.public

Mark S. Miller erights at google.com
Mon Dec 26 13:28:20 PST 2011


On Mon, Dec 26, 2011 at 11:08 AM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 26/12/2011 19:40, Mark S. Miller a écrit :
>
[...]

> A pointer would be appreciated, thanks. Caja has a rather complete
> emulation of ES5 that runs in legacy browsers going back to IE6. [...]
>
>  You can try out our emulation online at <
> http://caja.appspot.com/trycaja/index.html> and <http://caja.appspot.com/>.
>
>
> Since ES3 is Turing-complete, it's always possible to write an ES5.1
> interpreter and run any ES5.1 code (as used in node) in an ES3-capable
> browser. I don't think neither Caja nor my extreme idea have been
> considered by the speaker.
>

Likely. My point was to avoid the same oversight being made by those who
hear and repeat the speaker's message ;).

The Caja translation is much more direct than a general emulation of one
Turing complete language on another. It maps ES5 concepts onto ES3 concepts
very directly, enabling the emulated ES5 world to interoperate pleasantly
with the host ES3 world. For example, leaving aside property names ending
with "__" (double underscore), if "x.foo" succeeds in both guest and host
language, it generally means the same thing. The directness of the mapping
also helps the efficiency of the layering.


> I think that the concern that was raised was about not having the features
> natively. For instance, Object.defineProperty is not available and unless
> using rewritting like in Caja (or more radical solutions), it's not
> possible to emulate it in the browser.
>
> In practice, IE6/7/8 already suffer from a performance penalty and adding
> the overhead of runtime checks made by Caja are probably not worth the cost
> in most web applications. That is certainly the reason why people will
> prefer to either "dumb down" their code to ES3 if they care about sharing
> or maintain the few sharable parts independently rather than using a
> rewrit[]er.
>

It depends on your goals. More and more web applications are starting to
write off IE6 as no longer supported. Depending on your goals, it may be
better to have your modern web app limp along correctly on legacy platforms
than to not work correctly or at all on them.



>
> Do you have benchmarks on the overhead between "naive code" and Caja
> generated code, specifically on IE6/7/8?
>

I no longer have easy access to a machine running IE6. As I recall, the
slower the JS engine, the less relative overhead added by the Caja
translation (which btw is a nice tradeoff since we expect to switch modern
browsers over to translation-free SES). If memory serves, the relative
slowdown on Rhino was similar to the relative slowdown on IE6. Though if
someone could double check this, I'd be grateful.

The Rhino benchmark comparisons are at <
http://code.google.com/p/google-caja/wiki/Performance>. The "cajita" and
"valija" numbers are no longer relevant. Please check only the various
"original" and "es53" checkboxes. "es53" is short for "EcmaScript 5 over
(as emulated on) EcmaScript 3". The most relevant results are the
macro-benchmark runtimes, for which we get

testRichards: 2.1x slowdown
testEarleyBoyer: No significant slowdown

As always, take all benchmarks with a pound of salt.

-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111226/ebb050b5/attachment.html>


More information about the es-discuss mailing list