Re: UX gap, was Re: How can HTML5 compete with Native?

On Wednesday, October 23, 2013 at 7:12 PM, Marcos Caceres wrote:
> > These different library/frameworks also don't work together at all.
>  
> I don’t think that’s necessarily true (though it may be true in general). For instance, Topcoat is built specifically to just provide the UI components and to be model and controller agnostic. I don’t know how well it achieves this, but at least that’s the sell.
>  
> I know that the guys from PhoneGap encourage people to use handlebars together with Topcoat + require + jQuery. For example:
> https://github.com/ccoenraets/phonegap-day-eu/tree/master/part08-final/

Yeah, the verticals work. But now try integrating a product that has been partially using Bootstrap with one using Topcoat. You're in for a world of pain.


> > So if you've picked library A and need a component x of library B, you're either bound to re-implement it, or will end up bloating your app by adding both libs to it (plus you might bump into weird compat issues).
>  
> Yeah, can see that happening. But, at the same time, it’s should be seen as a good thing that developers have a great deal of choice in what frameworks they use to build their apps. This is at least what we want with regards to the extensible web manifesto.

If you look at the two most popular trends in WebDev of the last decade (Rails and node.js) you'll see that the first one was strongly opinionated about reducing choice (convention over configuration) and the second one adamant about building highly composable components through standardizing on the right set of primitives.

Choice is good as long as it doesn't pigeonhole you.
>  
> > Finally, high level components in native platforms can be wired-up really easily to data models (using MVC-like patterns) which means that changes to the data will propagate immediately to the UI.
>  
> Yes, some of that is nice. Better data binding options is something that is totally missing today. I imagine Object.observe is going to be a killer feature once it lands too.  
> > While such solutions also exist as JS frameworks (Angular, Ember, ReactJS, etc.), you're just adding another level of buying into a framework on top of the UI one you might have picked.
>  
> Ok, so my spidey senses are feeling like the data binding aspects might be a significant part of the problem. Mozilla has been toying around with a generic “data source” API that might be useful here [1]. It could provide a generic interface for data (which can come from anywhere, including memory, the device, or remotely)… be nice if there was a way of hooking up HTML elements to those data sources to watch for changes.

Sounds interesting!

--tobie

Received on Wednesday, 23 October 2013 21:44:24 UTC