[whatwg] No interface flicker across page loads, without JavaScript

[Aryeh Gregor]

On Sun, Oct 18, 2009 at 5:19 AM, Ian Hickson <ian at hixie.ch> wrote:
> Why can't we just use AJAX, and not reload the page at all, for this?

1) AJAX is more difficult to set up, as far as I understand it.  I
can't say for sure, since I haven't ever tried to set up AJAX from
scratch.

2) Getting bookmarkable/sharable URLs right requires extra effort with
AJAX.  Without HTML5 scripted history traversal (pushState, etc., IIRC
-- I haven't looked at that yet, you know what I mean), it's not even
possible to do it in a way that interoperates with non-JS UAs, like
search engines following links that users have posted to forums.  You
have to store state in hashes, and reconstruct it using JS.

3) Getting fallback to non-JS UAs right requires you to write
everything twice, pretty much.  Or create a complicated framework that
will automatically generate everything twice.  In particular, search
engines don't work well with AJAX at all.

All I can say is that in practice, I've never even bothered looking at
AJAX for page-reload situations (as opposed to performing actions
within the current page) because it seems too complicated to do right.
 A simple method that would automatically fall back to full page
retrieval would be much more attractive to me.

> It's not clear to me why GMail would get rid of the AJAXness -- what
> problem would we be solving? Also, with AJAX you can do things like
> transitions, which you couldn't do with page loads.

I don't think Gmail specifically would get rid of AJAX.  The feature
described here is only useful for simple cases.  It's not clear to me
at this point whether it's a good enough tradeoff between simplicity
and power to get significant uptake at all, let alone in sites with
much more complicated needs.

> On Fri, 16 Oct 2009, Aryeh Gregor wrote:
>>
>> So, here's a preliminary description of a use-case.  I'm not sure it's
>> sane yet.
>>
>> Use Case: A page should be able to instruct that when a user follows a
>> link, only part of the page is reloaded, while the rest stays fixed.
>
> That's not a use case, it's a feature description. The use case is the
> _why_ -- what is the problem being solved?

I'm not *entirely* sure, since I've never seen the need to use
anything like this myself.  The desired features seem to include:

a) Avoiding flickering and jumping on page load.
b) Saving bandwidth.
c) Being able to preserve state of some parts of the page (e.g.,
navigation collapse state) when others change (e.g., new content
loaded).

Is the desirability of those three things clear enough for them to
qualify as use cases?  I don't know if the list is exhaustive.

(a) seems to have some people (at least Tab) interested in the feature
proposal for its sake alone.  It's possible that (a) could best be
solved by general adjustments to how browsers lay out pages, perhaps
opt-in, but that's way beyond my field of expertise.  The basic
problem seems to be that on the one hand, browsers need to do
progressive rendering so that the page is usable as quickly as
possible; but on the other hand, this means they need to clear away
the whole page, including parts that won't actually change.  Some way
of hinting that certain parts shouldn't be cleared away, or should be
cleared away in a different manner, but *without* changing what will
show up when the page is finally loaded, might be a better solution
here.  It might affect only presentation and be invisible even to
scripts.

(b) is probably the least important of the three features, and can be
addressed by other means that might be more useful overall (like
SDCH).  Some of the proposals have incidentally included some features
in this direction because they seemed simple to tack on.

(c) looks like the part that really needs to be solved by something
along the lines of the given proposals, if AJAX and frames (and saving
state in cookies and recreating it on page load, etc.) are
unacceptable for whatever reason.  Frames have problems that are very
well recognized.  AJAX has at least the problems mentioned above.
Saving and recreating state on page load is a pain, I guess, and it
would be nicer if it were automatic.

I'm not the best person to ask here, though.  All I can say personally
is that if a good, robust mechanism were developed along the lines I
and others have described, that doesn't create the potential for scary
random errors of various stripes, then I *might* use it.  I wrote my
proposal based on the discussion about frames -- "use AJAX" didn't
seem acceptable to a lot of people in the discussion, for whatever
reason.  I'm not personally all that interested in this feature.