Re: How can HTML5 compete with Native?

On Monday, October 21, 2013 at 10:23 PM, Marcos Caceres wrote:
> (chair hat off)
>  
> On Monday, October 21, 2013 at 5:00 PM, jeanfrancois.moy@orange.com (mailto:jeanfrancois.moy@orange.com) wrote:
>  
> > 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.
>  
> I'm confused as to what this means. The core components of the Web are HTML and related APIs (xhr, web sockets, touch events, IDB, etc.). Which of these components would you say are not well documented? Or do you mean that it's not well documented how one composes this components to compose a web application?
> > 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.
>  
> Yes, picking the right framework can be hard. However, the thriving competition of frameworks that are built on-top of the platform should be seen a as a success. These frameworks are constantly evolving and improving.  
> > 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.
>  
>  
> Web components is not really about this - well not directly. It still expects that people will create frameworks (e.g., polymer and x-tags) for components to be useful.  
> > Also, we should look at proposing a
> > large and useful range of components for developers to rely on when
> > developing web applications.
>  
>  
> I don't agree that this is the right approach. We should leave those to the market (i.e., web component framework developers are in a better position to respond to demands from application developers). What we could focus on is making sure that Web components provide enough primitives and hooks into the platform that any element in HTML can be defined in terms of Web Components. Please see "The Extensible Web Manifesto" for more details:
My understanding is Jean-François was referring to UI components. It is true that compared to native platform, what the web has to offer there is underwhelming.

Although Web Components should provide the primitives to allow third parties to fill in that gap, discoverability, composability and interoperability of those components might still be an issue.

--tobie

Received on Monday, 21 October 2013 20:49:19 UTC