Re: How can HTML5 compete with Native?

Hadn't seen the recommendation to implement Power Management and WiFi API.  

That's very misguided imho and probably an incorrect appreciation of the data you've collected. For example, it seems the power management API in Android is mostly used to organize waking up the application to perform background tasks, so the real request here would be for those.

Also have you asked the developers about this recommendation? I've yet to hear a developer claiming he chose the native route because he couldn't have access to the Wifi API.

I would argue that looking at the apps in terms of features and seeing how these could be replicated on the Web Platform would give you a much better sense of the _real_ gaps in the platform than API permissions. As would focusing on how properly implemented these features are (which remains a key issue we're trying to help solve with the testing effort I'm leading).

There are plenty of other key API that this methodology is missing as they don't require permissioning on the Android platform: e.g.: payments, offline (that's a given on Android), etc.

Similar research we conducted at Facebook over a year and a half ago using the methodology I described above gave a very different picture, much more inline with preoccupations regularly expressed by developers. I really think you should reconsider this approach.

--tobie

On Friday, October 18, 2013 at 12:11 PM, Tobie Langel wrote:  
> Fantastic work.  
>  
> Thanks for sharing that.
>  
> A small nitpick inline, however:  
>  
>  
> On Friday, October 18, 2013 at 11:51 AM, Dimitris Michalakos wrote:
>  
> > 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.
>  
> JavaScript performance is almost never the bottleneck in an application (that is, unless you're building a game which relies on a physics engine). Rendering is the issue. And rendering is not implemented in JavaScript. Native mobile platforms have similar rendering issues, they just provide better ways to deal with them (e.g. separate UI threads, etc.).
>  
> We should be focusing on fixing the rendering problem (notably by providing adequate APIs which allow delegating the heavy processing to native code, background threads, etc.) not on raw JS perf (it's irrelevant) or blame games. (If the politics theory was true, Firefox OS would be blazing fast. It's not.)
>  
> Best,
>  
> --tobie

Received on Friday, 18 October 2013 11:05:23 UTC