What HTML5 mobile framework to use?

Yeah, it's been a month. Again, been working instead of talking about working. :)

Today I'll start touching on a topic as emotionally charged as religion and politics... a choice of HTML5 mobile frameworks for use with Cordova/Phonegap. That's me, always the troll, pushing the envelope of good taste and social acceptability, pushing buttons just to get a reaction. ;)

I've been using jQuery Mobile, but it has some bugs, and isn't exactly swift and fluid; on the other hand, it does have some nice button icons and default styles, and works well with jQuery. But there are other HTML5 mobile frameworks out there which may be more fluid, less buggy, have richer icons and styles.

So this next series of postings isn't really a "How I did it" sort of tech bragging, as much as current opinions on several HTML5-for-mobile setups. Some of them are subject to change as I learn something later, so if your opinion differs, this is a place where your comments would be appreciated!

Our Needs

jQuery is very visual -- you start with a HTML mockup and then you make it interactive. This is how our clients and designers think. They start with cosmetic mockups and designs, which will change often (sometimes 2-3 times in a week) as more visually-thinking people give input and do 180-degree spec changes. The "real programmers" shudder when I press the point, that the design (as implemented in HTML) defines the application, and that project specifications are typically defined after the fact based on budget leftovers and feedback. But that's the reality. We don't need a framework to build apps out of widgets, as much as a HTML/JS toolkit for making app-like behaviors starting with HTML.

• We're building our apps with Cordova / Phonegap. Virtually everything should work well with Cordova, but then again let's not presume. If the final product doesn't work well once we've plugged it into Phonegap and tried it on a few devices, it's a loss. (see Ionic in a future posting)
• The HTML/JS API must not be dogmatic, forcing us to use prefab widgets that cannot be quickly customized. The designers and the clients decide what we do; they can be quite capricious, and we never say no to any customization. If they want THIS selector to have its handle on the left while OTHERS have the handle on the right, that needs to happen and pronto. Right off the bat, this means that a lot of programming-heavy frameworks which let you "just tie widgets together" via a configuration file, are right out. (see Sencha in a future posting)
• But that said, we  do want the prefab widgets... just ones that we can ignore or modify, preferably in HTML. Utility classes are awesome, and so are glyphicons. (see jQuery Mobile and Ratchet in a future posting)
• We do most of our programming in jQuery, so anything that plays well with jQuery is a big bonus.

jQuery Mobile

Well, let's start with the framework we are already using.

- Good. It's highly visual. As I described above, you start with your HTML and then program behaviors into it. This fits perfectly into the paradigm of our project managers, designers, and clients.

- Good. A very large community and great documentation. There isn't much about jQuery Mobile that remains mysterious after five minutes in Google and StackOverflow and/or ten minutes with JQM's docs. We still need to do some tedious CSS discovery sometimes, but 90% of questions have already been answered.

- Good. Page management. Attractive cross-platform CSS. Decent widget set. Custom event handlers and DOM manipulation. It's pretty sweet.

- Bad. It's a little slow. Even with FastClick, there is a noticeable lag between tapping a button and going somewhere. I've tried changing the delay, disabling page animations, FastClick of course, ... It's not killer slow, but it's not really smooth.

- Bad. Rendering bugs. I find myself implementing corrective CSS on every new project. a) Hyperlinks that are a[data-role="button"] has a visible underlines on the text. This is easily corrected in CSS, but seems a silly thing to need to correct. b) Buttons in the header, will sometimes "stick" in their highlighted/active state long after the finger has moved on, sometimes even after switching to a different page, and then coming back minutes later. This means that the active color needs to be the same as the inactive color (CSS fixes), which sort of misses the point.

- Mediocre. The data-role paradigm is nice, but not as rich and flexible as a good set of utility classes, e.g. class="button button-panic button-wide"  We get two themes (data-theme="a" and data-theme="b"), but need to write custom HTML to simulate a third theme if we want a third button color (but need to replicate that for header buttons and so on. By comparison, Bootstrap and Ionic have several types of button.

- Dicey. Lazy rendering. One of the first executing statements in our programs is $('div[data-role="page"]').page() to effectively disable lazy rendering. Our typical use case, is that a listview needs to be populated programmatically, but we cannot guarantee that the user has previously visited the page and caused the listview to render into DOM, allowing the refresh to happen. Lazy rendering is intended to reduce memory usage, but realistically it's just a race condition waiting to happen.


So, what are other options? That's the focus of upcoming articles...