Re: How can HTML5 compete with Native?

On Monday, October 21, 2013 at 4:30 PM, Dimitris Michalakos wrote:
> > Sure. But to make it the one of the top two priorities of what's missing on the Web platform seems quite a stretch.
> > Can we get offline, auto-rotation lock, smooth scrolling, fast canvas, etc. first?
> 
> I would agree that offline needs to be fixed asap. Auto-rotation lock is also very important. 
> 
> I am not proposing leaving everything behind and focusing sorely on WiFi and Power Management. Nevertheless, studying an already successful mobile app ecosystem such as Google Play leads me to the conclusion that these two APIs are important.
These APIs are important on Android because the platform requires that you call them to perform very basic tasks (such as keeping the CPU running or making an HTTP request). You can't just map the requirements of one platform on to another without considering the very different way the two platforms are architectured, differences in their security model, etc. Inferring from the data you collected that adding support for WiFi and Power Management to the Open Web Platform would help increase the number of applications built on the platform by 21% is misguided. Suggesting these are the APIs we should focus on implementing is misguiding. 
> 
> As far as performance is concerned (smooth scrolling, fast canvas, even DOM rendering) I think we are in desperate need of tools right now. What I 've learned is that "if you can't replicate a bug, you can't fix it", "if you can't measure an app, you can't improve it".

Yes we need better tools. And better APIs to hook those tools deeper in the guts of the browsers. This is work we've been trying to drive in the WebPerf WG, BTW[1], not sure how it has been moving forward since (I changed focus shortly after contributing to this document).
> Native SDKs have what we call an IDE (which is essentially an editor with debugging, profiling and deploying functionality). With HTML5, coding and debugging are two separate processes. You code on the editor (e.g. vim or sublime) and test on the browser (e.g. using Chrome developer tools). At the same time, browser developer tools are difficult to learn. The Gmail team asked help from the Chrome team to debug gmail that had serious issues with memory. They managed to fix the problem. But normal developers, on the other hand, don't have access to the chrome team. So, if it's rocket science, how are they going to use it?

Vendors are doing a better job with dev tools nowadays (and also with evangelizing them). This clearly needs more work and would really benefit from competition from third parties would they be able to hook into the browsers directly.
> What I also find very interesting is tools like famo.us (http://famo.us). While we were talking about performance these guys just went and fixed it. And not by introducing some new technology, but by using correctly the existing technology.

Well, we're yet to see this deployed in prod somewhere. :)
> The same happened with FT, Goo Engine and more. So, again the issue here is not the technology, it's education.

I'm not familiar with Goo Engine, so maybe there's a thriving economy of mobile HTML5 games built on top of it. With regard to the FT it is clearly not a resource intensive app and still required true engineering prowess to build. That's a problem. A successful platform needs to see all kinds of developers thrive, not only top engineers. Effectively, educating developers to code around perf issues, implementation bugs and inconsistent APIs, is pushing the burden of dealing with what are platform and implementation issues from browser vendors and standards bodies to developers. Effectively this means that building the same experience (if it is at all possible) on the Web takes more time (and thus is more costly) then using a native SDK. This simply decreases the value proposition of the Open Web Platform and drives decision makers and developers to proprietary platforms.

In truth, issues have't changed much since I wrote down some of the reasons which had driven Facebook to move it's apps more towards native technology[2] last year. they are:

1) poor tooling (as you brought up),
2) missing features (e.g. camera access, offline, etc),
3) performance issues, 
4) interoperability and quality of implementation issues (aka death by a thousand paper cuts).

These are what we should be focusing on.

--tobie

---
[1]: https://docs.google.com/document/d/1Yw_qNMCnGsWQRsdcrifzh_kzFey-ThQ3yp-DmxuJxvg/edit 
[2]: http://lists.w3.org/Archives/Public/public-coremob/2012Sep/0021.html

Received on Monday, 21 October 2013 16:08:50 UTC