Re: How can HTML5 compete with Native?

Hello everyone,

I have been passively reading the current debate on what the group should
be focusing on. A point that has not been mentioned (or I unfortunately
missed it) is the existence of easy to use and well documented components.

When a native developer wants to develop an application for Apple iOS or
Google Android, he will have access to a large set of components, that are
well documented and work out of the box. These components support a rather
large set of customisation and if anyone faces an issue while using them,
there is a large community that uses the same set of components ready to
help them. That is a massive advantage for the native platforms.

On the other hand, the web does not have (yet, I know it's coming) such
components. The web developers often use a framework, with more or less
boilerplate and conventions, and will have to build a lot of custom
components on top of it. These custom-built components will probably not
be optimised, and the developer will then have to optimise his/her
application piece by piece, reading a lot of contradicting articles on how
you can obtain a jank free UX for your users. I let you imagine how
complex this process can become.

I think this is one of the issue we should look at, and we should make
sure that the web components spec answers this problematic, and if not,
give suggestions on how to improve it. Also, we should look at proposing a
large and useful range of components for developers to rely on when
developing web applications.

Jean-Francois

On 21/10/2013 16: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.
>
>
>
>


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

Received on Monday, 21 October 2013 16:01:00 UTC