Over on the mobile team we've been chatting for a while about the various trade-offs in native vs HTML-based (PhoneGap/Cordova) development.
Currently our main Wikipedia apps are all HTML-based: * Android - HTML + Cordova + plugins * iOS - HTML + Cordova + plugins * BlackBerry PlayBook (and later BB 10) - HTML + WebWorks * Firefox OS - HTML * Windows 8 - HTML + WinRT (mostly separate UI code)
We also used Cordova and HTML for the Wiki Loves Monuments app. While it worked and was good for quick prototyping, we've run into a number of problems doing HTML-based development in both apps:
* performance -- especially when combining large scrolling text areas with static controls * compatibility -- making something that worked on Android 2.x and 4+, and on iOS 4.x and 5+, is sometimes.... fun. Since we're stuck running in the native web view control on each platform, we're stuck with old bugs and sometimes have to make huge workarounds. * platform limitations -- for WLM we had to modify the Cordova platform so we could do a progress bar on upload. Ouch! * platform integration -- to use system sharing features and other things well we often need plugins for Cordova, which means either relying on third-party code (which may not be as well maintained as Cordova core) or writing our own (and keeping them up to date as Cordova evolves). Either way we have to fiddle with native code to handle things like saved pages already, so we're not playing pure HTML+JS. * crash reports are often useless, not giving us JavaScript stack traces
For instance we recently ran into a problem where HTTPS stopped working in release builds on Android 2.2... we got no backtraces from the system, just knew that *something* somewhere in the WebView's infrastructure stopped working. It was.... not fun to track down. If we'd been doing the page loads in native Java, we probably would have gotten stack traces automatically.
We've started a couple experimental projects as fully-native Android apps: a Signpost app that uses native notifications to alert you to new issues, and a Commons uploader which lets you take photos or videos and upload them direct to Commons.
Going native on these means: * good access to notifications, multimedia, etc * faster startup times * native use of Android accounts management system when doing editing features * more native look & feel * no damn tricks for scrolling areas :P * crash reports are more likely to point at something relevant
So we've been thinking about splitting up the HTML-based Wikipedia app as well. There'll still be a big WebView in the middle of the app -- it shows web content after all! -- but most of the UI chrome, retrieval of data, and all the system integration will go into the native-side code.
Essentially we may reorg to: * HTML core for the WebView -- handle section collapsing, references, table collapse/expand, etc. Probably share much of this code with MobileFrontend. * native iOS UI (Obj-C) * native Android UI (Java) * separate HTML UI for Firefox OS, BlackBerry PlayBook & BB 10 * separate HTML UI for Windows 8/RT
Firefox OS, BlackBerry 10, and Windows 8 all give us fairly good system integration within the HTML+JS environment so we probably won't have to do truly 'native' code on these, which is good since we'll have less time to devote to them.
iOS and Android remain our top-tier mobile platforms, and we know we can do better on them than we do so far...
Any thoughts? Wildly in favor or against?
-- brion