This post over on the Scirra blog has gotten several people within my HTML5 development circles talking again about the future of the hybrid app frameworks on mobile platforms. The move away from CocoonJS and Ejecta by Construct 2, and the promotion of WebView as the coming winner, has generated much discussion around one central question that has risen up once again: wrappers or WebView?

See, the entire hybrid app framework field can, generally, be divided between the two poles of a continuum right now: wrappers (including CocoonJS and Ejecta) at one end and the WebView approach (Cordova and PhoneGap) at the other. Somewhere in the middle is Crosswalk, a project that acts like a wrapper, but uses Chromium libraries to parse content. (A competitor to Ludei’s own CocoonJS Command-line interface, which uses the same idea, but is itself wrapped by Cordova.)

For the most part, choosing which end of the continuum, be it more wrapper or WebView, has been a contrast of either wanting more speed or general accessibility. Until that blog post, it was generally thought that wrappers were faster: by dropping extra browser features like DOM and XML support, they could render quicker. But by choosing WebView, users would, again generally, have the same experience as they would with the site opened within a mobile browser. However, by using WebViews, your code might also run slower — it’s running not just the code, but in some ways an extra browser to render it too.

Yet, if we are to believe Ashley in the post (and many people are), there is a coming possibility that, with the arrival of iOS 8 and native WebGL support, WebViews might be on par or even faster than wrappers. Instead of having to lose some accessibility (and usually design for an additional ‘platform’, the wrapper), using WebViews will often be the better way to go. Using some method of compiling the project, along with this faster “WKWebView“, could push hybrid apps even closer to the Holy Grail of consistent native speeds.

However, and here is where it crossed paths with me, this also means a coming decision about where to spend development time. For community-driven projects like Phaser, for example, this means trying to decide if it is worth the time and resources to support wrapper engines like CocoonJS and Ejecta, which can mean using extra hacks or libraries to supply what the wrappers lack in browser functionality, or shift toward more WebView-based code. (Disclaimer: I’ve written patches for Phaser for both, but have recently moved to actively supporting Cordova.)

If this new “WKWebview” can delivery what Ashley is writing about, though, and similar code arrives in Android relatively soon, this could signal a power shift. If WebViews can catch up to wrapper speeds, or surpass them even, there would be very little need, as I assume Scirra is thinking too, of trying to keep up with the wrapper engines. If, with only a handful of changes like detecting mobile events like ‘pause’ and ‘resume’ for apps, HTML5 could run at or near 60 FPS with little to no work on mobile, the WebView approach might win out completely.