Caja performance recommendations

[Mike Power]

Dear Caja Developers and Users,

I have seen in posts (dated back in 2016) that caja can be very heavy weight.  Is there any documentation/data describing this? What are the best ways to mitigate this?  Has the continued development of SES.js improved this, or is it more related to sandboxing the HTML and CSS?  I was thinking of having a page with some 20 elements of third party UI.  It sounds like this would be possible with caja but really slow.  If I planned to change the data, but not the components very often, can I cache the initialization and change the data?  Would this enable me to only pay the initialization cost once, and then reuse the component with different data?\

Michael Power

[Kevin Reid]

On Fri, Jan 10, 2020 at 10:40 AM 'Mike Power' via Google Caja Discuss <google-ca...@googlegroups.com> wrote:

I have seen in posts (dated back in 2016) that caja can be very heavy weight.  Is there any documentation/data describing this? What are the best ways to mitigate this?  Has the continued development of SES.js improved this, or is it more related to sandboxing the HTML and CSS?

Both — SES's lockdown and repairs significantly reduce JS execution performance, and the HTML/CSS sandbox requires executing a lot of JS.

 

  I was thinking of having a page with some 20 elements of third party UI.  It sounds like this would be possible with caja but really slow.

I do not recommend using Caja for new development, particularly if you are intending to embed third party widgets without any complex interaction of your JS and their JS — <iframe sandbox> is a much more robust and efficient tool for that, and built into browsers.

 

  If I planned to change the data, but not the components very often, can I cache the initialization and change the data?

No. Something like this used to be possible with the old "cajoler" and "ES5/3" approach (where a server-side computation rewrote the HTML and JS), but that is even slower and even more deprecated (and does not support eval() or any other form of dynamic code loading).

[Mark S. Miller]

https://github.com/agoric/SES is SES rebuilt for modern JavaScript. It is strictly better than the old Caja SES, which is still mostly stuck in EcmaScript-5 concepts.

https://github.com/Agoric/SES-beta/blob/master/packages/ses/src/main.js will be the next generation. Better still.

Both have negligible performance overhead.

--

---
You received this message because you are subscribed to the Google Groups "Google Caja Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-caja-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-caja-discuss/CACvbym65X%2BwF6ZWEd9B%3DZvU1oeG4q_Brh1rrMbOQYtraTdU4-Q%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Mike Power]

Well since the broad conclusion is not caja, and there are a great many ses discussions regarding iframes and containment over on ocapjs.  I'll let this topic expire and review ocapjs for related threads, like: https://ocapjs.org/t/containment-via-service-worker/94.