- From: Dimitris Michalakos <dimitris@visionmobile.com>
- Date: Fri, 18 Oct 2013 09:51:51 +0000
- To: public-web-mobile@w3.org
- Cc: Dan Appelquist <daniel.appelquist@telefonica.com>, MIGUEL SCHNEIDER <msf@tid.es>, Michael Vakulenko <michael@visionmobile.com>, Andreas Constantinou <andreas@visionmobile.com>, Carlos Domingo <carlosd@tid.es>
- Message-ID: <CAKiHAk=qdQg=xDn6V1DBBHjNyho6ym3mJZrFox5-9Ry9sv8a3g@mail.gmail.com>
Hi all, We ‘ve recently completed an important piece of research at Visionmobile, in collaboration with Telefonica, on “How can HTML5 compete with Native”. I personally led the project. My name is Dimitris Michalakos. I am a software developer, proficient in web technologies. I have worked as a software team lead for Renew, a network of screens located in the city of London and now I am leading web research at Visionmobile. There is a lot of discussion around HTML5 vs. Native, and it’s usually polarized. But most people express opinion, rather than facts. In our research we attempt to answer some of the key questions with data. Before I talk about the results, I ‘d like to explain the approach to the research. - *30,339 Android apps from Google Play (US) *analyzed in terms of app categories and API permissions; - *6,000+ mobile developers worldwide* surveyed in April – May 2013 as part of VisionMobile’s 5th semi-annual Developer Economics survey; - *42 HTML5 tools*, analysed and mapped into categories across Architectural frameworks (e.g. Angular.js, Backbone.js, Ember.js), UI frameworks (e.g. Bootstrap, jQuery Mobile), Gaming engines (e.g. Goo Engine, ImpactJS), Web wrappers (e.g. Phonegap, Sencha Cmd, Ludei), Web-to-native converters (e.g. Appcelerator, Game closure) and Native Javascript APIs (e.g. Firefox OS, Tizen, Blackberry Webworks); - *32 developers, industry experts and tool vendors* interviewed, from Angular.js to FT and Mozilla; So here’s an overview of what we found. More on the linked PDF<https://www.dropbox.com/s/51bmutcuqikz03e/Visionmobile-Telefonica-How_Can_HTML5_Compete_with_Native.pdf> .. Four routes to market Web developers have four fundamental routes to the mobile market… 1. *Go direct to mobile browser;* *e.g. iOS Safari, Android browser, etc.* 2. *Use a web wrapper (aka “the hybrid approach”);* *e.g. Phonegap, Sencha Cmd, Ludei, etc.* 3. *Use a web-to-native converter;* *e.g. Appcelerator, Game closure* 4. *Use a Native JavaScript API platform;* *e.g. Firefox OS, Tizen, Blackberry webworks, etc.* Not all routes are the same How do the four routes compare? Are they all the same? A sample of 2,275 mobile developers from VisionMobile’s Developer Economics Q3 2013 survey, says *61% of HTML mobile developers go direct to the mobile browser, 27% use a web wrapper like Phonegap, 7% use a native JavaScript API platform like Blackberry Webworks and finally 5% use a Web-to-native converter like Appcelerator*. But routes also differ in terms of API depth. Among 30,339 Google Play (US) apps, *37% can be implemented using HTML5 via the Mobile browser, 49% via Phonegap, 63% via Appcelerator and 98% via Firefox OS*. Lack of APIs Lack of APIs is a valid concern. It comes both as a result of survey data, as well as by comparing Google Play (US) API usage to HTML5. But, are all APIs equally important to mobile apps? And since resources are limited, where should W3C focus? In other words, which APIs, if existed, would make the biggest impact to the developer community? *Power Management and WiFi APIs, if implemented, would result to an astonishing 20.83% rise in the number of apps that can be created with HTML5.* Slow performance HTML5 performance, and specifically JavaScript performance, is highly debated. In July 2013, Drew Crawford, an iPhone developer from Texas implied that JavaScript performance reached a dead end and is not going to improve anytime soon, receiving 499 points on HackerNews. Nevertheless, CPUs for mobile devices do get better. iPhone 5S has twice the CPU power of iPhone 5 and that is twice the CPU power of iPhone 4S. Within two years iPhone improved 4x in terms of CPU. At the same time, JavaScript compilers improve. JIT compilation is 5x slower than Native and asm.js promises approximately 1.3x slower. So, if software and hardware are improving, what makes JavaScript slow? The real problem is browser politics. Besides Opera, all major browser vendors are mobile OS vendors. Google promotes it’s own Native Chrome Apps. Apple is keen to implement all latest standards but leaves out performance related APIs, e.g. WebGL. Therefore, *HTML5 performance is it’s current phase is more about politics, rather than technology*. Ease of development Lack of APIs and slow Performance is at the center of criticism. But when we spoke to Robert Shilston, Director of FT labs, champion of HTML5 mobile apps, he argued that “the biggest issue for HTML5 is the maturity of tools”. Ran Ben Aharon, head of Front End Development of Everything.me supported the case: “Hearing Mark Zuckenberg denounce HTML5 made me angry at first, but then I looked at some data and realized that the main reason was not performance or APIs but the lack of memory management and debugging tools.” Finally, Louis Stowasser, author of CraftyJS added “it would be great to have something like yslow (debugging tool) for game developers.” Once an app has a memory leak, it is like a speeding car with no dashboard. You never know how fast you go, or when the engine will explode. Developers need simple, comprehensible tools, like YSlow, that offer insights on what to fix, rather than cold data. *So it’s not about performance, it’s about tools and the ability to measure performance and improve. The absence of instrumentation tools, especially debugging and memory profiling is profound.* You can download our full research at the following link. https://www.dropbox.com/s/51bmutcuqikz03e/Visionmobile-Telefonica-How_Can_HTML5_Compete_with_Native.pdf Your feedback is most appreciated, Dimitris Michalakos Web Technology Lead | VisionMobile :: Knowledge, Passion, Innovation Tel: +30 693 6526071 | visionmobile.com/blog
Received on Friday, 18 October 2013 09:53:45 UTC