HTML5 Frameworks - SpiderOak/so_client_html5 GitHub Wiki

Often, HTML5 doesn't just mean html5 + CSS + Javscript. We also depend on a framework for easy, programmatic articulation of the DOM, traversal, and other elaborate stuff. We curently use jQuery Mobile. We will periodically have to reevaluate this choice, as the state of the art develops, maybe considering another framework or maybe considering mixing and matching a collection of lower-level facilities.

In thinking about this, I recognized some fundamental things our implmentation depends on from our framework. I have probably missed some fundamental elements, but I'm recording it so we can refine it, as our understanding and the state of the art grows.

Query	The "query" in "jQuery" to obtain DOM elements for programmatic manipulation, using CSS-style selectors.	Absolutely essential, I would hope that any substantial framework would provide this, and it would be cool as an a la carte library.
DOM Encapsulation	Encapsulation of DOM elements for dynamic manipulation of existing ones and formulation of new ones.	Ditto. Easily produce new, articulate existing, and inject elements into the DOM.
Pages as DOM elements	Abstraction of pages as DOM elements in a single HTML page, for quick navigation (together with dynamic addition of new pages).	This is an optimization. I would be fine with other ways to achieve this, if they don't make things more awkward.
Ajax object	Ajax - comprehensive XMLHttpRequest/Response objects and callback operation	This apparently is modeled on (or outright stolen from) some Google framework, and is de rigeure for anything adequate
Custom URL traversal	Ability to take over the URL traversal process, and do our own handling.	Getting this to work right took some effort, and is probably different for each framework. But, if it can be done once...

I should mention some of the specifics that give me trouble in jQm. Eg, at this point pop-ups are relatively new and still buggy, but dialogues are static, not controllable enough via programming. I know that designers must like the way that Sencha uses iOS native-looking Back button, on iOS. Maybe there are other look-and-feel, performance, functionality advantages to be found elsewhere.

I've looked at Sencha, but not under the covers, so don't know how it does things. It does seem, though, to be more polished than jQm, and it does appear that the crucial components are available under an open source license (GPL3) that is compatible with our app's license (Apache2).

Mixing and matching lower level facilities is also an interesting question. We might gain greater agility and control. If the interdependencies are too elaborate, though, we might wind up just creating the burden of another framework that we, ourselves, have to shepherd.