If you're interested in an example of this behaviour Twitter do a great job. This is easy to see if you browse with the Webkit (or Firefox) developer tools network interface open.
The reasons for compromising on this initial vision are found somewhere between, "it's too complex" and "that's a bad user experience".
Not all data is created equal. Some can be accessed quickly, some can be cached and some can be slow to request yet extremely time-sensitive. In our case the last, slowly retrieved time sensitive data is a good example of the local bus real-time information provider. For example, "where is the nearest bus stop, and when is the next bus?" we can answer the first part of this query almost immediately, however the real-time information means a call to an external provider. Something we have no control over, which could respond at any time or not at all. Obviously it would be crazy to wait for this to respond before rendering a page to the user.
We find this pattern in many places in Mobile Oxford, a potentially fast initial response followed up with slow to retrieve timely data. Library availability is another example, "this book can be found in this library" can be answered quickly, however "is the book currently checked out?" is much slower to answer.
User contexts are clearly shifting so much from the simple "at desktop PC with ethernet" it's important to consider what your application could offer in terms of offline support. We're not doing much in this area for Mobile Oxford however in another project we are "bootstrapping" the client with some pre-loaded data.
Native Application Containers
There are many reasons why native applications are desirable, I won't be going into those here. If you are interested to hear more leave a comment and we'll try to write a few words on this.
Connectivity, errors and other issues
Beyond offering offline support your application should handle the case of "partial connectivity" where the user might be in an area of flaky network coverage. This might involve retrying requests (with exponential backoff) or providing UI elements for users to retry themselves.
Writing shared client and server-side code is becoming a major talking point recently. While it's clear nobody has "solved" the above problems there are some interesting projects progressing in this area:
- Rendr from Airbnb, uses conventions in structuring your application to allow for a single code base to run in both the server and client environments.
- backbone-serverside, a recent post to Mozilla Hacks on a different approach to Rendr. Instead of providing a way to structure your application this project seeks to "polyfill" specific client-side only API's allowing your application to run on the server.