Tab Atkins Jr.
jackalmage at gmail.com
Sun Oct 18 12:38:12 PDT 2009
On Sun, Oct 18, 2009 at 1:00 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> 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
I intend to solve a combination of (a) and (c) (b might be an
ancillary benefit, however).
Basically, there are two classes of websites who I think will benefit from this.
1. Fairly ordinary sites which have heavy widgetry in their skeleton.
These might be js-based (good semantic scripting often involves
sending something over the wire that's simple and accessible, then
substantially transforming it with js on the client to something more
useful/dynamic), flash-based, or something else entirely. The idea is
that there are things which are expensive to initialize (in cpu, time,
whatever) that are present on every page.
2. Relatively simple single-page apps. Something on the scale of
gmail probably won't be able to use this, and that's fine; they're
already making a significant js investment and can afford a bit more
to handle their single-pageness themselves, plus html5 will add
several features to make this easier. However, a simpler mail client
may benefit significantly from this, as it eliminates a big chunk of
necessary js. Other apps that have complex scripts that should
maintain their state may benefit too. The idea here is similar in
that there may be a significant blob of js state that is expensive to
initialize or reload.
Really simple sites with static sections that are *actually* static
won't really see much benefit (the decrease in flickering may be
useful, but it's such a minor benefit that it's not worth engineering
towards). As well, very complex js-driven applications will have more
complex requirements than can be met by this mechanism, and so won't
benefit from it. But the middle ground I outlined above has
significant ability to grow, and I think is currently being held back
by the architecture of the web (where every page is a completely
independent resource) and the difficulty/expense of routing around it
More information about the whatwg