How should I write a Jquery Mobile app for browsers with and without javascript support?

Question

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

Answer 1

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!

Answer 2

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?