jQuery Forum

Bottom line from one developer to another - it's not simple.
Remember, jQuery Mobile is a cross-platform solution across many disparate mobile devices.
You might say "but it's all HTML5, and HTML5 is a standard, right?"
The complexities come from different qualities of implementation from different implementers.
On the surface the browsers may pass HTML5 compliance tests, but here the devil really is in the details.
This may help you understand why:
Brad Frost's Report on fixed positioning in mobile devices

I've been involved in a very high profile project which has delivered an HTML5 solution for a major carrier.

We achieved fixed headers and footers, but not without much re-work and compromise. I feel for the jQuery Mobile team, because they are going through the same pain, and to their credit are being quite transparent about it.

The solution we used (and are still looking to refine further) uses a jQM header, a central scrollable area, and a bottom navbar. (One view replaces the central scollview with an AJAX map control.) To cut a long story short, I ended up having to write a layout function to size all the elements correctly for different devices in both orientations. Our biggest problem was the appalling implementation of the Android browser with respect to responsiveness (including lack of reliable hardware acceleration support for CSS3 transforms), form rendering glitches especially within a scroll view and unreliable reporting of device property parameters through standard Javascript functions.

I was frustrated and asked jQuery Mobile team when they would be improving the scroll view component. The answer: they had given up on it - it was a dead-end solution on Android, and therefore could not be delivered as part of their truly cross-platform framework. This current release is their next best attempt on achieving the 'holy grail' of fixed headers and footers cross-platform.

I published this blog post which may help you to understand some of the challenges:
http://red-3.blogspot.com/2011/11/layout-strategies-for-iphone-android.html
(Other posts on my blog may also help you understand why things are not as straightforward as we wish they really ought to be.)

While I understand and appreciate the challenge, the fact remains that JQM is becoming increasingly less useful to mobile developers. It works great on modern desktop browsers, though, so perhaps the developers should step back, re-think, and re-purpose.

The specific features and performance areas most wanted by mobile developers are being delivered by competing platforms, and seemingly without the same level of difficulty. Of course, as you point out, most of these do not have to support desktop platforms, as they are targeting mobile-only.

A developer needs to apply multiple work-arounds to JQM to get acceptable performance when using JQM in a webview frontend for, say, an iPhone or Android app. Not jumping through these hoops risks non-acceptance of the app in the Apple App Store, or, at least, embarrassment at the poor achievable quality and user dissatisfaction.

I would contend that you can't release a decent mobile app with JQM without at least patching-in iScroll4 (fortunately, not difficult) and some "fast click" solution (quite difficult).

What I don't understand is why it isn't possible to support both sets of developers. Not EVERY JQM site/app has to support EVERY platform. It would be way useful to be able to throw JQM into "mobile mode".

It is particularly frustrating when JQM throws out a feature in a new release that used to exist. Then you have to make the decision whether to stay back with the older version and forgo new features, or move "forward" while accepting further performance or feature degradation.

I concur. And I share some of your frustrations. jQuery Mobile's mission statement is quite ambitious in wanting to support all platforms. What's the phrase they use? "Seriously cross-platform".

Many 'other frameworks' are more specific in their targets, leaving some platforms out in the cold. Which is OK if conformance is stated up front. And is probably a more sensible and achievable goal.

Unfortunately the wider you spread your net, the more problems are inevitable without much stricter HTML5 compliance standards on all platforms. (Not just 'can you do fixed-positioning?' but 'can you do it properly?')

Seriously cross-platform means a lowest common denominator approach, or lots of patch code to utilize the strengths of each individual platform. In a recent statement on this forum, Todd Parker made it clear that they are throwing out a lot of patch code and so we can expect that they're going along the pure lowest common denominator route with 'graceful degradation', which I imagine will leave most developers and users feeling a bit thread bare...

The challenges are pretty enormous and growing with every new release of every mobile OS. We might be left thinking at some future day: "Cross-platform? Seriously? What were they thinking?"

Hi,

I totally agree with watusiware!
When I first heared about JQM, I thought that it would be THAT solution to build mobile apps to which I've
been waiting for because I like jquery to build websites. I thought that all the problems which exist in JQM until now would be go away when JQM gets older (new JQM releases). But with the new release 1.1.0rc some problems came up again, which I resolved in 1.0.1 with some extra work. I hoped these problems should be fixed in the new release. In this post I've wrote about these problems.

To get real fixed toolbars in 1.0.1 I've used the experimental scrollview from jqm and disabled ontouchmove like this document.ontouchmove = function(e){ e.preventDefault(); }. This works for me really good on my iPhone 4S and my galaxy tab. Like watusiware said you could also use iScroll4 to get the real fixed toolbars. With the new release 1.1.0rc I can't get the newly implemented "out-of-the-box" real fixed toolbars to work. They are flickering and jumping around. See my other post above.

Like watusiware said JQM becomes day to day more useless to me to build mobile apps. Maybe for mobile websites accross modern browsers JQM is a nice solution but for me JQM is a mobile framework to build mobile apps and all things I build with this framework dosen't have to work on EVERY paltform.

Hi all -

If you want a pixel accurate iOS app that attempts to feel native but is built with web tech, there are tons of narrowly-compatible options out there so I'm wondering why you're not using iUI, Sencha Touch, Kendo UI, etc.

Well, for one, RhoMobile made the mistake of standardizing on JQM, moving from JQTouch. Some community members are working on adapting Rhodes to jq.mobi, but currently you are on your own if you want to use it.

It isn't just a matter of choosing one Javascript UI framework or another when you are building native apps. There is some considerable effort to do the adaptations to tie-in the UI framework with the native app framework.

As well, JQM is one of the three Javascript frameworks that are supported by PhoneGap, and the other choices are not great, IMO. So, again, the developer is on their own to adapt some other framework such as jq.mobi.

Both RhoMobile and PhoneGap made what now turn out to have been poor decisions, based on where they thought the JQM project was going. It clearly is no longer going there.

 @Todd: On re-reading my post, I hope it did not come across as being a personal attack or as nay-saying. I'm trying to acknowledge that the mobile landscape is a minefield - not unlike the PC landscape in its infancy. And it's going to be a real challenge to deliver a one size fits all solution across the board.

Thanks for your detailed response Todd!

After I've read your post I think I've misunderstood what JQM really is.
Thanks for making this clear to me!

I've searched for a way to create mobile apps which perform nearly like native apps with a single codebase (HTML5/JS) for the most available platforms out there. I also know that there are some other great tools/frameworks to do this but as I'm working every day with jquery for building websites, I thought I go with JQM. And I thought it's a really great framework to do this even it's a young framework.

When I visit the JQM website and read the part under "Seriously cross-platform with HTML5" I thought that JQM is also very good for building apps beside websites that works on most popular devices. If we put those applications in an phongap "wrapper" or not is secondarily. These apps firstly should work in the mobile browsers out there. But without such things like totally fixed toolbars, good scrolling experience and well performing "normal" transitions (see my other post) I can't build applications for mobile browsers, at least with JQM, even without using phonegap. I thought that JQM 1.1 would resolve many problems I had before with the two main new features true fixed toolbars and smooth transitions. Sadly they dosen't. See my other post linked above.

Everywhere in the web JQM is compared with frameworks like Sencha Touch, jQTouch or jqMobi and because of that I thought JQM is a good solution for me to build "simple" mobile apps which later will be covered with phonegap to work on a variety of devices. Also the jquery background in developing apps and the great companys backing up JQM was a reason to go with JQM.

I do believe that it is very difficult and hard work to build a framework which covers such a variety of platforms
than JQM do. And thats really great! Also I believe that's very hard to get the best out of all those platforms without compromises. JQM dosen't have to work everywhere perfect. For me personally a perfect crossplatform framwork with HTML5/JS has to mainly perform well on iOS and Android (maybe Blackberry and Windows) and all other platforms are nice to haves. I thought JQM would cover these requirements for me.

As you said, JQM seems not the right solution for me now. When I have a website which should work on most mobile devices I go with JQM and when I want to build mobile apps (HTML5/JS) with nearly native experience then I go with some of the other frameworks. After this clarification I think I finish my current projects with JQM as best as I/JQM can and then I'm looking for another framework which more covers my need, building mobile apps with HTML5/JS mainly for iOS and Android (and maybe Blackberry and Windows).


Thanks again for your response!

Cheers
Daniel

Sorry if I misinterpreted your original question, but I think whether the central area scrolls or not, my first answer to your question stands, and my blog post gives valuable hints and tips.

I think that a lesson that should be learned here is that you cannot (or at least should not) degrade or remove a feature that was available in a previous point release. You can improve on it, sure. But just because you think that a feature is not up to scratch in 1.0, you can't just remove it in 1.1. We developers expect some backward compatibility might break in a major release, but not a point release. By doing this yu may have prevented some people who were relying (and were even satisfied) with that previous implementation from upgrading. And that's a bad place to leave them.

At least when Lucy pulls the football, we know it's just a children's cartoon, and can laugh about it.

RhoMobile contributed monetarily to the JQM project and adopted it as their standard UI layer. Now RhoMobile developers are stuck with something that produces amateurish results, with the "forward" path only degrading further, and we are scrambling to come up with an acceptable alternative.

"free" != "no responsibility to users".

And, while the product is free, the project is not entirely a volunteer effort. Several companies made what I would presume to be some fairly substantial monetary contributions to the project, which presumably went to pay for developer's time, marketing, etc.

I don't know what - if any - quid-pro-quo there was - but it is certainly disappointing that what we now have is increasingly un-useful for some of those partners and their customers. Of course, it is up to the management of those companies to take this up with the JQM team - I don't presume to speak for them.

I perceive an unsettling dictatorial style that is not in keeping with the spirit of open-source projects. It seems clear that whatever process is used to decide on new features and direction is not being done in the open. I suppose that is the prerogative of the JQM team. I hope I am wrong, and that the JQM team really means it when they say they are listening. If 1.1 is unleashed as it now stands, you haven't heard the start of it. The vast majority of developers, who generally wait for releases, will be blind-sided.

I am only trying to raise awareness that JQM seems to be moving in a direction that is not going to satisfy the needs of a large number of it's users who were previously reasonably satisfied, and hopeful that the few remaining major issues would be solved. Now, it appears it may have been a poor choice to get on this boat.

We have every team meeting on Thursday in a public google plus hangout that's posted online and in the irc channel.

First I've heard of this, so thanks for the information. A URL would be helpful, as a Google search doesn't reveal where this is, nor do I find anything on the "Resources" page here, where I might expect to find it. I had assumed that the seldom-used "Jquery Mobile Development" forum here (along with bug reports and pull requests) was the only public place for discussion of direction. Bug reports and pull requests aren't necessarily the best place for that.

I’m actually enjoying these posts!

Lots of resemblance with the heated debates on Native vs Web apps, which you see all around the web. Right now because of the app mania, like Todd likes to say, it’s seems that native is more in demand. But JQM took a decision, more than a year ago, and I’m not sure they could easily change directions. And why should they, most mobile framework, are already focused on native “primarily”.

I realize that some folks may not be happy with us switching gears on our technical approach on fixed toolbars, especially when this means that iOS 4 and some other older platforms now just fall back to toolbars scrolling with the document. It wouldn't be that difficult for someone to slot in the older, dynamic re-positioning behavior for iOS4 but we don't feel comfortable supporting this because it frankly didn't perform that well because of browser limitations. If you look at our tracker, there are a ton of issues related to the older fixed header style that can't be fixed and we heard pretty loud and clear that that wasn't good enough so we went with a much better approach that yields much better results. At this stage, iOS 5 is already at roughly 75% use so iOS 4 is quickly fading away. The quirkiness and overhead of supporting the older fixed toolbars isn't something we can commit to doing.

Todd - thanks for the very informative response.

@mokesmokes:

JQM runs on all desktop browsers, so I'm perfectly fine doing a layout that looks smooth on mobile, tablet and desktop using only Jquery Mobile.

There are some nice add-ons available to also do more complex layouts or adaptive elements, such as:

adaptive layout grids 1140
adaptive layout gris 960
adaptive images
adaptive tables - JQM version
...

So you can pretty much set up a Jquery Mobile web app, that looks great across all devices, both mobile and desktop.

If you look at the new windows8 preview, which seems akward being all-touch-for-desktop-screens, I bet it won't be too long before desktops become touchable as well. Woudn't you be happy having done your site in Jquery Mobile then :-) ?
 

I agree with frequent i think windows 8 is going to be the beginning of bluring the lines between what we now consider mobile and desktop. There is already a Huge market trend away from desktops towards tablet and laptops. I think windows 8 will continue this bringing full windows to "mobile devices" is a huge step forward. I think tablets and laptops that convert to tablets will be the new norm and JQM perfectly addresses this trend.

I agree with frequent i think windows 8 is going to be the beginning of bluring the lines between what we now consider mobile and desktop. There is already a Huge market trend away from desktops towards tablet and laptops. I think windows 8 will continue this bringing full windows to "mobile devices" is a huge step forward. I think tablets and laptops that convert to tablets will be the new norm and JQM perfectly addresses this trend.

One of the primary drivers for adopting JQuery Mobile was flexibility in an uncertain world.
Todd, we realize there are many who are under the delusion that native simulation is achievable with HTML5, and I respect the reality check.

However, there is are other major advantages of HTML5 adoption - let's not get hung up on the pure 'performance is king' topic. Please bear the following in mind, and don't lose sight of the fact that users of HTML5 frameworks will EXPECT to host them in native wrappers. I'm glad that you cited that it is a secondary aim of jQM to support the Hybrid model of deployment.

1. Flexibility
1a. Adaptability
2. Consistent looks across platforms
3. True cross-platform "write once run anywhere" potential
4. Future proofing
5. Fast track adoption of new platforms

1. Flexibility
Building in HTML5 gives them the option to deploy as a web app, support HTML5 off-site installation (i.e. install to home screen) or use a native wrapper solution to get into the app stores. There may be many reasons that a solution builder may not already know their deployment strategy, not least because they are unsure that they will be pass compliance with an app store's ever changing policies.
(My personal situation is a case in point - we deploy our HTML5 app on Android as a Hybrid but were unable to reach agreement with the AppStore, and so deploy for iPhone on a web server with the option to install as an HTML5 application.)

1a. Adaptability
Another strong potential has been mentioned above. The potential to reach across formats with one adaptable solution is a very strong one, even if it is not front and center of people's minds at the present time. Frameworks like jQM have the potential to change the face of tradition site design by adopting and supporting a unified, adpatable interface across phones, tablets, netbooks, laptops and desktops. The advent of touch gestures and interfaces has revolutionized even the way people now expect to use their mouse.

2. Consistent look across platforms
Whereas the platform providers recommend certain style guidelines for apps built for their platform, some companies also have their own standards of usage and l&f. HTML5 apps can be styled to the unified standards of the company, not the platform provider.

3. True cross-platform "write once run anywhere" potential
By doing an HTML5 app, I am writing to a cross-platform standard. I have one code base, and have the potential to reach many platforms. My alternative? Invest in teams to develop the same app multiple times, or make a decision that only certain platforms are important to me, and shun the others.

4. Future proofing
So I have an HTML5 app. It doesn't work well on platform X. The trend towards HTML5 standard compliance means that someday it will work on that platform (and someday after that it may even work well!)

5. Fast-track adoption of new platforms
Getting my existing HTML5 app working on a new or future platform will be far less work than re-writing it in their proprietary native language. And if new providers are not on the HTML5 train, they might as well not be in the game.

I hope that the jQM team will realize that these are valid and achievable goals for HTML5 mobile developers, and decide not to leave anyone behind. We're passionate because we care! :P

Hi all, 

Thanks for listening, Scott.

I look forward to trying it out when it's up.

The branch preview is loading, but it doesn't contain the fix. I'll toss it up on another server until the branch previews are working again. Standby

All really great points @redthree - the idea of building a widely accessible, future-proof, branded experience is really what we're all about. Thanks for the support and contributions @arschmitz - glad to hear we're being consistent with our message and you see the blurriness we see. We're really trying to "skate to where the puck will be" here and that means a very fluid and fuzzy continuum between phones, readers, tablets and desktops with lots of user input methods and resolutions/DPIs. The best way to cope is by embracing flexibility and web standards.

I posted the latest version of the iOS4.3 polyfill in a Github Gist and updated the docs to explain how to use it and link to the code and demos.

So i know this thread has gone WAY WAY off topic and i was a part of this but i have a potential solution for the original posters problem / suggestion for future releases.

@arschmitz

I tried to make my own approach at this using a custom "viewport" that would always be the right width/height regardless of the device - and would respond to any changes to the device orientation or width/height changes.