The reason that some developers do not encounter this weakness is that they are generating their content on the server and sending it down to the client. This enables the jQM engine to kick in and 'enrich' the markup.
However, when you consider that many developers will want to package their applications up as 'native' apps using tools like PhoneGap, the application at that point must be resident on the device. (This is a significant factor, for various reasons - not least because the Apple AppStore won't accept an app that opens a WebView and points it to a webserver.)
At present the best current solution I have yet to come across in jQM is this:
Of course, we should not have to delve into the generated page source to find out what jQM has decorated the markup with and add all that js code to emulate it. (Try adding a button! Ouch!) I have read in this thread that the jQM team is exposing a method so that you can basically just do something like this in the next release (see Todd Parker's responses in that thread):
Note that in the example above, I'm adding to the markup at runtime in exactly the same way as I would if authoring the markup at design time. Much more intuitive.
- var listItem = new ListItem('Fred');
- listitem.iconSize=small; //or iconHeight = 16; - you get the idea
I can understand that this final suggestion is a tall order, and may be a fairly large addition to the library. Having it as an optional extension for 'client-resident' applications however, would be a great addition to the framework as it matures, IMO.
I see great potential for this framework, but it's definitely a little green behind the gills right now. But as an alpha it's already quite capable. Production ready for dynamic client-resident apps that would pass as native? Not sure about that...still a way to go.
I'll be watching JQuery Mobile with great interest...