5 ms·

On performance, the new WKWebView on iOS (with Nitro JS + GPU rendering, including WebGL), and the Chromium webview on Android 5.0+ (or Crosswalk for Android 4.

On performance, the new WKWebView on iOS (with Nitro JS + GPU rendering, including WebGL), and the Chromium webview on Android 5.0+ (or Crosswalk for Android 4.0+, similar features all round), radically changes the performance story. It's almost identical to the system browsers now. Facebook's comments about HTML5 were back in the dark ages when the webviews generally used horribly slow software rendering and didn't have JIT for Javascript on iOS. It's a completely different picture today. In fact, our performance-sensitive HTML5 game engine[1] targets the iOS 8 webview and Crosswalk for Android for making native apps, and they generally work as well as in the browser, which is very good, especially on newer devices. Modern web APIs are also asynchronous which helps offload work from the UI thread, and Web Workers can do that for arbitrary JS code too. For example our game engine runs A* pathfinding in a web worker, offloading any performance impact from the CPU intensive algorithm and running it in parallel to the game. I think it's time to stop accusing webviews of being slow. [1] scirra.com

sfjailbird 11y ago
> the Chromium webview on Android 5.0+ The Chromium based webview is available already in Android 4.4. So about 50% penetration at this point. It is indeed a huge boost to performance.
- AshleysBrain 11y ago
  Oh, good point. I mentioned Android 5.0+ because the 4.4 one is missing some major features including IIRC WebGL, Web Audio and WebRTC, which still rules it out for some use cases (such as a game engine).
0x0 11y ago
Does WKWebView work with file:/// urls needed by Cordova?
- gpmcadam 11y ago
  Is there a reason they don't ship with a simple web server to server out the static files, similar to `python -m SimpleHTTPServer`?
  - eddieroger 11y ago
    Why would they want to? Both platforms have webviews that can render HTML from a file, or passed in strong form, or whatever you like. Why point it at an internal web server? If anything, it'd add overhead to the system that's unnecessary.
    - 0x0 11y ago
      Apparently WKWebView does not support loading from file. That's why he suggested wrapping it in a localhost HTTP server.
  - Spoom 11y ago
    The Android Cordova platform used to do this by including OkHttp but they moved away from that because it's now unnecessary.
- RoboSeldon 11y ago
  Last time I checked (a few months ago) you couldn't use file:/// with a WKWebView at least on iOS8. Apparently, latest iOS9 beta allows you to load a local file.
- windsurfer 11y ago
  No, but there is a drop-in plugin that adds a webserver and converts your webview to WKWebView: https://github.com/Telerik-Verified-Plugins/WKWebView https://github.com/Telerik-Verified-Plugins/WKWebView It has a few limitations, but it's quite nice for games.
- o_____________o 11y ago
  Check out https://github.com/Telerik-Verified-Plugins/WKWebView https://github.com/Telerik-Verified-Plugins/WKWebView
_pmf_ 11y ago
> radically changes the performance story So that it's only 100 times slower than a native app instead of 200 times?
luckydata 11y ago
the facebook app used to be slow partly due to the fact that the devs working on it had no idea what they were doing (at the time, Facebook really stepped up their game lately). The dev team at my ex company built a demo to show that the same app could have been made to perform acceptably using the right strategies. https://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/ https://www.sencha.com/blog/the-making-of-fastbook-an-html5-...
kllrnohj 11y ago
> It's almost identical to the system browsers now. Facebook's comments about HTML5 were back in the dark ages when the webviews generally used horribly slow software rendering and didn't have JIT for Javascript on iOS. Incorrect at least as far as Android goes. Android's WebView literally was the system browser until Chrome was released complete with the JIT since Froyo (V8) and hardware rendering since Honeycomb. And the first several versions of Chrome on Android had much worse performance than the old WebView did. This aside the bulk of HTML content is still software-rendered. It's software-rendered into tiles which are then GPU composited. It's a different story if you use <canvas>, but at that point you aren't gaining much by paying the browser tax so why not just drop to C++ and write GLES directly and get like 10x the performance? That aside while there have been improvements in JavaScript performance, HTML/CSS & rendering performance really has not improved much if at all over the years. Browsers are still dreadfully slow to actually produce pixels compared to any other UI toolkit.

sfjailbird 11y ago

> the Chromium webview on Android 5.0+ The Chromium based webview is available already in Android 4.4. So about 50% penetration at this point. It is indeed a huge boost to performance.

AshleysBrain 11y ago
Oh, good point. I mentioned Android 5.0+ because the 4.4 one is missing some major features including IIRC WebGL, Web Audio and WebRTC, which still rules it out for some use cases (such as a game engine).

0x0 11y ago

Does WKWebView work with file:/// urls needed by Cordova?

gpmcadam 11y ago
Is there a reason they don't ship with a simple web server to server out the static files, similar to `python -m SimpleHTTPServer`?
- eddieroger 11y ago
  Why would they want to? Both platforms have webviews that can render HTML from a file, or passed in strong form, or whatever you like. Why point it at an internal web server? If anything, it'd add overhead to the system that's unnecessary.
  - 0x0 11y ago
    Apparently WKWebView does not support loading from file. That's why he suggested wrapping it in a localhost HTTP server.
- Spoom 11y ago
  The Android Cordova platform used to do this by including OkHttp but they moved away from that because it's now unnecessary.
RoboSeldon 11y ago
Last time I checked (a few months ago) you couldn't use file:/// with a WKWebView at least on iOS8. Apparently, latest iOS9 beta allows you to load a local file.
windsurfer 11y ago
No, but there is a drop-in plugin that adds a webserver and converts your webview to WKWebView: https://github.com/Telerik-Verified-Plugins/WKWebView https://github.com/Telerik-Verified-Plugins/WKWebView It has a few limitations, but it's quite nice for games.
o_____________o 11y ago
Check out https://github.com/Telerik-Verified-Plugins/WKWebView https://github.com/Telerik-Verified-Plugins/WKWebView

_pmf_ 11y ago

> radically changes the performance story So that it's only 100 times slower than a native app instead of 200 times?

luckydata 11y ago

the facebook app used to be slow partly due to the fact that the devs working on it had no idea what they were doing (at the time, Facebook really stepped up their game lately). The dev team at my ex company built a demo to show that the same app could have been made to perform acceptably using the right strategies. https://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story/ https://www.sencha.com/blog/the-making-of-fastbook-an-html5-...

kllrnohj 11y ago

> It's almost identical to the system browsers now. Facebook's comments about HTML5 were back in the dark ages when the webviews generally used horribly slow software rendering and didn't have JIT for Javascript on iOS. Incorrect at least as far as Android goes. Android's WebView literally was the system browser until Chrome was released complete with the JIT since Froyo (V8) and hardware rendering since Honeycomb. And the first several versions of Chrome on Android had much worse performance than the old WebView did. This aside the bulk of HTML content is still software-rendered. It's software-rendered into tiles which are then GPU composited. It's a different story if you use <canvas>, but at that point you aren't gaining much by paying the browser tax so why not just drop to C++ and write GLES directly and get like 10x the performance? That aside while there have been improvements in JavaScript performance, HTML/CSS & rendering performance really has not improved much if at all over the years. Browsers are still dreadfully slow to actually produce pixels compared to any other UI toolkit.