Re: How can HTML5 compete with Native?

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


> Can you provide more detail about why apps are using the and why they are
> important?


Power Management is used to prevent the device from sleeping or the screen
from turning off. This is important in case of a timer app or a dashboard
with live data (e.g. stock market) or a chat window.

WiFi is used to list available wifi networks in the area and connect to or
disconnect from them. This is important in case of WiFi Direct, Ad-hoc wifi
networks or simply a Starbucks app, where you download the app and you
automatically get connected to the WiFi network of the shop.

> As far as performance is concerned (smooth scrolling, fast canvas, even
> DOM rendering) I think we are in desperate need of tools right now.



> These assertions may be valid, but we need to specifically look what
> things developers are having problems understanding/using.


Taking out the IDE part, which comes from my experience, the rest are not
exactly assertions. We have some quotes from important players in the
field. And I could also get a couple more that didn't make it to the
report. But also, we have survey data. Tools is the third most popular
stopper from HTML5, following Performance and APIs (n: 1518). On the other
hand, cross-platform code portability is the most popular driver to HTML5
(n: 1974).

Dimitris Michalakos
Web Technology Lead | VisionMobile :: Knowledge, Passion, Innovation
Tel: +30 693 6526071 | visionmobile.com/blog


On 21 October 2013 18:38, Marcos Caceres <w3c@marcosc.com> wrote:

>
>
> On Monday, October 21, 2013 at 3: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.
>
> Can you provide more detail about why apps are using the and why they are
> important?
>
> >
> > 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". 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?
>
> These assertions may be valid, but we need to specifically look what
> things developers are having problems understanding/using.
>
> > 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. The same happened with FT, Goo Engine and more. So,
> again the issue here is not the technology, it's education.
> >
>
> Right, if there are more things the browser evangelist teams could be
> doing, we can speak to them. People here have frequent contact with the
> appropriate people on those teams, so if we can get a list of complaints
> together, it would be helpful. That would also be helpful in encouraging
> members of those teams to join this group.
>
>
>
>