Re: How can HTML5 compete with Native?

>
> 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.


Tobie I get your point. I respect your opinion, and you are right to say
that the 21% is misleading. Its a theoretical number. In retrospect, I
should have diminished it's value.

But, I have taken platform requirements into account and I strongly believe
there is value in this approach.

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.


The key sentence here is "competition".

Yes we need better tools. And better APIs to hook those tools deeper in the
> guts of the browsers.


Panagiotis Astithas from Mozilla Dev tools suggested creating a Debug API.
I think this is similar to what you say. If such a thing existed then third
party vendors could hook their tools to browsers and competition would
drive innovation.

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.


Every platform has quirks. And every developer must learn to overcome a
platform's issues. Whether HTML5 has more issues than Native, that is a
good question to answer. Still, I do not believe it's possible to see all
kind of developers thriving, nor on Android or iOS. We should try making
the developers' lives easier, but we can't do the work for them.

Btw it's not good enough for a mobile ecosystem to attract developers in
general, it has to have the elite in order to succeed.

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.


I couldn't agree more.

Dimitris Michalakos


On 21 October 2013 19:10, Tobie Langel <tobie@w3.org> wrote:

> 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
>
>