What Features Should A GUI toolkit have?

[via Digitalmars-d]

On Friday, 6 March 2015 at 12:30:36 UTC, Paulo  Pinto wrote:
> I am hoping mobile applications and application stores bring an 
> end to the non-sense of bending documents into applications.

Yes, the model-view separation could be better for large datasets 
( > 5000 items), but you can do it just fine now that 
hardware/engines are fast enough (by absolute positioning 
relative to the list view). Once most platforms are fast enough 
you can get good updates/framerates even if HTML5 is somewhat 
inefficient for some display strategies. The good thing is that 
we are really close to that threshold now, and that better 
refresh rates than 60hz makes no sense.

> Or that we get to have the second comeback of XHTML, and 
> finally have something like XAML on the browser, which was 
> XHTML original idea.

I think HTML5 brings very nice semantics to document markup, so 
you can use XHTML5 if you want. And Shadow-DOM/Polymer with 
two-way binding (variables and UI-elements are automatically 
updated when one change) is more like an extensible display-graph 
than a document, but you can also turn XML-ish/JSON-ish data into 
a pre-filled form to have a custom editor in a document like 
fashion.

Quite a few quirks and some boilerplate at the moment, but one 
can play with it already. I am testing Dart+Polymer+Paper 
Elements for an Chrome based admin interface right now. I think 
it is moving in the right direction, although at bit 
"complicated" without tooling.

When the quirks are ironed out, the tooling certainly will 
come... Overall, I think it will be easier to use than Cocoa et 
al, with roughly the same capability, but a lot more ready made 
components. If Google keeps investing in the tech... The only 
problem would be that it might be too complicated for avarage web 
devs without tooling, and that the tooling-devs wait for avarage 
web devs to pick it up. Catch 22.