2

I'm trying to wrap my head around jQuery Mobile. My aim is to build a very fast application with a look and feel as close as possible to a native app (at least for modern devices).

I understand there are two ways of navigating between pages:

  1. Loading each page as a separate page and linking to other pages with regular html anchors.

  2. Putting all (or many) pages on one single web page and navigating between them by means of javascript ($.mobile.changePage (method) and similar api functions.

The first approach should work on all browsers, but performs quite poorly since there is a delay between each page transition.

The second looks like it should be much faster, so I would definitely prefer this approach. But how would that work for mobile device browsers without javascript support? It certainly seems to violate jQuery Mobile's aim to provide a gracefully degraded experience for C-grade browsers.

It looks to me like I need to implement my app twice, once optimized for browsers with javascript support, once for browsers without? Using may be another option, but that looks even more messy.

What's the recommended way to approach this dilemma? Is there anything I have not noticed?

Thanks,

Adrian

Adrian Grigore
  • 33,034
  • 36
  • 130
  • 210
  • 1
    What mobile browsers don't support Javascript? – SLaks Jan 07 '11 at 01:00
  • I'd imagine there are quite a lot that don't, I have a samsung U900 (retired but still own it), it's only a couple of years old and IIRC it doesn't support javascript. There are also a lot of countries in the world where the average person just plain doesn't have a smart phone. – PottyBert Jan 07 '11 at 01:44
  • do it with javascript support. – Jason Jan 07 '11 at 01:51
  • @SLaks: There are actually quite a lot of them. See this matrix: http://jquerymobile.com/gbs/ – Adrian Grigore Jan 07 '11 at 09:57
  • And for the sake of the facts - all browsers in that GBS table (and many more) support a subset of javascript, which some people call "supports javascript" ;) – naugtur Jan 07 '11 at 11:22

2 Answers2

2

First of all: Your point2 is wrong.

See Local, internal linked "pages" in here and read it carefully. A link href="#pageelementid" will work just fine AND will work in any HTML4 capable browser too [might require <a name="pageelementid"> in some cases, I'm not sure anymore] with the only difference being that all the pages are visible at once.

Second thing is that if you use the way number 1 it will look quite nice too. It will load, yes, but in javascript-enabled browsers it's loaded with AJAX and there's no nasty blink between pages. Also - a "loading" popup shows up.

jQuery Mobile is supposed to let you create an application with some pure and simple html without any JS. JQM itself takes on the enhancement of the page so that it looks good and uses AJAX. Try to create an application that would work in every browser possible (my inspiration: lynx) and use JQM markup for that. Any javascript you are willing to write should work as an enhancement - making it better instead of making it work at all.

good luck with that!

naugtur
  • 16,827
  • 5
  • 70
  • 113
  • Thanks about pointing out my mistake - Now I see clearer how this is supposed to work. jQuery Mobile is even much better than I anticipated! :-) – Adrian Grigore Jan 07 '11 at 10:08
0

The current thinking on supporting lesser browsers is to not degrade gracefully, but to enhance. If you build the website from the ground up to work without javascript then enhance it afterwards, then you pretty much know that the site will work (rather than having to fix it or build a secondary site).

As regards the two options you've specified, number one would be my preference as a mobile user if I had a limited bandwidth and also a lot of people have a restricted download amount per month.

Lumping all the pages into one large file may seem like a good idea (downloaded already), but you may well run into memory limitations on certain phones. And what if all they want to do is visit two pages, why should they be forced to download the entire website to do so?

PottyBert
  • 1,902
  • 1
  • 13
  • 14
  • I understand the point you are trying to make, but it doesn't quite apply to my scenario. I'm working on a SaaS website for time tracking, not a regular website (like weather info or a map). It's purpose is to offer people a very fast way of tracking their work time on a day to day basis. Most of our clients use it several times a day. Therefore speed is of the essence. Ideally we'd like to implement native apps for mobile phones, but we don't (currently) have the resources to do this for each plattform that our clients are using. – Adrian Grigore Jan 07 '11 at 10:14
  • You won't need native apps when your JQM app is done. Google for `phonegap` – naugtur Jan 07 '11 at 11:19
  • @naugtur: I am aware of phonegap, but we'll still need native apps. Even if properly implemented, a JQM website isn't remotely comparable to a real app in terms of speed and therefore usability. It's a nice workaround for the time being and for those devices that we can't support natively though. – Adrian Grigore Jan 09 '11 at 17:21
  • Time tracking has to be accurate in terms of seconds, not miliseconds, that's why I expected it'd be enough. I wouldn't recommend it for a shooter game ;) – naugtur Jan 10 '11 at 08:27