Separate event-loop for same-origin CPU intensive iframe

Question

Let's say I have a CPU intensive iframe.
It's on the same domain as the parent page, thus cross-origin does not apply, so it shares the parent's event-loop.

Is it possible to have a separate JS context (including a separate event-loop) for the iframe, such that it doesn't block the parent's UI?

Setting the sandbox attribute for the iframe tag doesn't solve this, although the docs state that the iframe will be considered to be from a 'unique origin'.

This question is hypothetical/conceptual. I don't have a real use-case for this. Just curious.
I was wandering how sites like JSFiddle run users' code, and apparantly it runs from an iframe from a different domain (jshell.net in JSFiddle's case).

Answer 1

How do Services like JSFiddle run user code in a different event loop?

They don't resolve the actual problem, they just hack their way around it, by using cross-origin iframes.

For example, this can easily be seen on StackBlitz, they create a subdomain for each execution environment.

On JSFiddle, this is a bit harder to see through at first, since their iframe doesn't have a src attribute set. However, the iframe is bound to a form, which ends up being another cross-origin iframe.

Workaround - Web Workers

As others have mentioned correctly, you can use web workers, to generate a new JS context, and run some heavy calculations there.

This works, since web workers run in isolated threads (MDN).

Workaround - Running code in smaller chunks

As others have mentioned as well, you get a performance increase by running code in smaller chunks. Take the following example:

const array = [ ... ]; // array with hundreds of items
const result = [];

const stepByStepCalculation = () => {
  if (array.length) {
    result.push(doExpensiveCalculation(array[0]));
    array.shift();
    requestAnimationFrame(stepByStepCalculation);
  }
}

stepByStepCalculation();

Now, after every iteration of the event loop, one item of our array is being processed - step by step.

Also, using requestAnimationFrame instead of setInterval or setTimeout has the advantage, that it will be called after every event loop iteration, and not after ~4ms, making it much faster.

The problem with our workarounds

Our workarounds only work, if our expensive tasks, don't have to constantly read from the DOM.

This is a big problem, if our same-origin iframe has expensive JavaScript animations, it will heavily interfere and may cause lags in the UI.

Summarising

Moving calculations into worker threads, or doing them step by step to reduce the load works.

However, to your main question, we can't create a separate JS context (as of right now) for same-origin iframes. Online JS shells tackle this problem by using cross-origin iframes.

It would be interesting to see, if we can somehow run JavaScript code in the compositor or raster thread, since they should have access to our DOM, unlike web workers.