I'd be curious to hear when the author's experience was. They mention off-handedly that using Ejecta didn't improve performance meaningfully compared to switching to WKWebView.
Ejecta formerly used its own compiled version of JavaScriptCore, and thus couldn't execute JS in the same sandboxed context as WKWebView (gaining performance through JIT execution, etc). The most recent versions of Ejecta does in fact use the system JSCore, which means it should see the same JS performance characteristics of WKWebView.
Given that Ejecta also replaces the HTML5 canvas implementation with its own native implementation, I'd assume that modern Ejecta is much faster than WKWebView, particularly for games where the performance bottleneck is graphics rendering.
Does using the system JavaScriptCore as a library, as Ejecta does, in fact allow you to make use of the JIT? I thought WKWebView could do it only because it runs in a separate process which doesn't have the same restrictions applied to it as the app's own processes.
The Ejecta release notes[0] don't mention anything about the switch to the system JSC library enabling JIT (which would be a big deal!), just that it makes the apps a lot smaller.
Ejecta formerly used its own compiled version of JavaScriptCore, and thus couldn't execute JS in the same sandboxed context as WKWebView (gaining performance through JIT execution, etc). The most recent versions of Ejecta does in fact use the system JSCore, which means it should see the same JS performance characteristics of WKWebView.
Given that Ejecta also replaces the HTML5 canvas implementation with its own native implementation, I'd assume that modern Ejecta is much faster than WKWebView, particularly for games where the performance bottleneck is graphics rendering.