Framework7 -- HTML5 framework for Cordova Mobile

It's been a long quiet time, I know. I've been working on a lot of stuff, but nothing had a "wow, folks would be interested to hear about this" sort of flavor.

But, as is typical at the time of the winter solstice holiday, clients went on vacation, backlogged lower-priority work got done, and eventually my inbox flatlined. That feels good... and opens me up to get back onto  thread I've been promising since September - - picking a new HTML5 toolkit, to use with Phonegap/Cordova.

To reiterate, our basic wish list (which could be interpreted as a gripe list with jQuery Mobile) is as follows:

• Structured and configured in HTML and CSS, as opposed to code. Not that I myself am opposed to code, as much is that the designers are the ones who call the shots, so anything strongly based on prefab widgets declared in code is likely to run afoul of the designers wanting something that the code just doesn't do.
• Highly configurable CSS. jQuery mobile is configurable and flexible, to a degree. Then again, it has a whole lot of decor already in place that we often need to override. Again, the clients of the designers specifically pick things that the toolkit doesn't do, since they don't like to look like a default kitchen sink demo. :-)
• Not buggy. JQM has a lot of bugs that keep biting us. Some are in the design (text input do not get the same styling, not the same with, are visually inconsistent) and some are functional (a loading spinner won't show at all if the following AJAX call takes one second, buttons continue to look after the finger has been removed from the screen).
• Performant. JQM is a bit laggy on two-year-old devices. Turning off page transitions and editing CSS to remove shadows helps somewhat, but then again ideally it would lack these shadows to begin with.

A few months ago I discovered this one: Framework7 http://www.idangero.us/framework7/ And over the solstice holiday break, I finally got to play with it and I really like it a lot. I used it to write a personal app, a calculator for playing BattleTech (a  board game from the 80s).

• It is largely based on HTML and utility CSS classes, which is perfect for our needs.
• It does not use jQuery, but their own lighter-weight DOM library with a syntax nearly identical to jQuery. It's not exactly the same, however, and lacks some features. (see below)
• Visually, it's quite lightweight. The navigation bars are white and blue by default, thin outlines, and an otherwise not-very-cluttered visual feel. This is as opposed to the somewhat-heavy toolbars and buttons used by JQM.
• When I needed to make arbitrary changes, it proved quite capable. For example, the panels are 100% wide and with no margin simply by adding a new CSS class with a margin:0, or by omitting a wrapper DIV which introduces a margin. Making the tab button 100% wide, was equally simple.
• Adding FontAwesome took literally moments. Adding FontAwesome was necessary because the framework's own CSS classes do not include a rich set of icons. So this bullet point is both a point against Framework7, then that point rewarded back again -- the framework does not come with a rich set of icons, but has no problem working with your choice of icons. This point is then awarded a second time, because icons on buttons and panels can be quite arbitrary and flexible: rather than using data-icon="" attributes on elements which specifically supported, you declare your arbitrary <i class="fa"></i> elements wherever you like. This came in handy, for example, adding a X button to the slideout panel in order to close it.
• It feels very performant and slick, even on an iPhone 4. This three-year-old phone represents the trailing edge of what we will be supporting for the next year or two. And under this framework, even this slightly obsolete hardware is plenty fast.
• The resulting application is very consistent in its look between Android and iOS platforms. For us, this is preferable over a framework which tries to "look native" on both platforms -- the designers want a consistent outcome and not stuff that "looks default". And It looks like they'll get it.

I see a lot of promise with this one. Still, I should point out the problems I have had with it as well.

• The documentation is incomplete and incorrect in parts. For example, their own "starting example" (at the time) does not render properly since they have one of the class names misspelled. The documentation for individual widgets such as checkboxes, consists of a lengthy paragraph of HTML forming an example, and it's up to you to visually tease apart which elements are the relevant ones since there are rarely any additional instructions.
• The DOM library (called Dom7) is not exactly as functional as jQuery. For example, it does not have the :selected pseudo so you cannot pick the <OPTION> element itself and pull additional data-xxx="" attributes beyond the value itself. If you need to do more complex selections like that, you would need to iterate and compare value. Also, to touch upon the documentation, the narrative component of the documentation for Dom7 consists of one sentence: "Just what you already know" followed by a snippet of what looks like jQuery code (but it's Dom7). Then follows a list of supported functions, but not a in-depth description of what sorts of selectors are and are not supported; I had to discover myself the limitation about option:selected
• Their documentation recommends that you assign $$ to Dom7, so you can act similar to jQuery with selectors such as $$('span.highlight') but not conflict with some other library which uses $. However, $$ is already defined and their advice is basically for you to override their $$ with a new $$ to Dom7. If your own assignment of $$ fails, you get some wonky behavior. The symptom here, is that $$ still returns elements but it's an array of raw DOM elements and not Dom7 object wrappers -- as a result, your call to $$('span.highlight') returns a set of <SPAN> elements, but your call to show() fails with "show is not a function" when you know perfectly well it's a function! For this reason, I recommend that you ignore their advice and assign to $ instead. At least that way, a mismatched brace somewhere in your 2000 lines, won't lead you on a wild goose chase (or is it a red herring fishing trip?) hunting for $$ results which exist but do not obey.

All told, I think we have a winner. If you are using PhoneGap or some other HTML web view type deal to write your hybrid mobile apps, you'll probably want to check this one out. Framework7 http://www.idangero.us/framework7/

Oh, right; my app

If you're interested in the BattleTech app, you can check it out over on Github:
https://github.com/gregallensworth/BattleTechCalculator

This app does not use the framework's wrapper classes for checkboxes, select elements, and so forth. This particular app is so heavy with dozens of checkboxes and a two-column layout, that we needed the most compact layout available. Although I gladly used the navbar, left slideout panel, and tab bar, this app is not representative of Framework7's decoration of form elements.

But even this is a good thing: you are not forced to use these decorated checkboxes and select elements, and this is a great scenario for we were allowed not to use them and thus achieve a more compact layout than would have been possible with JQM. So even in a case where we don't want the decor at all, Framework7 still came up a winner.