[whatwg] window.onhashcange not considered harmful

Bjartur Thorlacius svartman95 at gmail.com
Sun Nov 22 13:45:48 PST 2009


On 11/22/09, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Sat, Nov 21, 2009 at 3:33 PM, Bjartur Thorlacius
> <svartman95 at gmail.com> wrote:
>> Could you please explain to me (forgive me, I haven't got much
>> experience on this topic) why "webapps" can't either have a specific
>> element for <inbox> and <sent mail>, or even different pages? Why is
>> it so terrible to navigate to another page to fetch another mail
>> folder? They have to fetch the data from the server anyway.
>
> Thomas Broyer already pointed out that just fetching particular bits
> of the page can be much faster than pulling down the whole page.  In
> addition, apps with significant javascript state can avoid having to
> throw away and rebuild the entire thing every pageload, which can be
> extremely significant.

Ok, fetching
<title>Inbox</title>
<ol>
<li data-datetime=...><a href=...>[ITEM]</a>
...
</ol>

plus links to heavy (cacheable) CSS and contact lists is of course
more time consuming than fetching:
[
[ '[ITEM]', 'datetime' ]
...
]
but if you send only <title> <link> and <a> elements, the size is
pretty low. But there'd still be a difference. But there would also be
a difference if the app used short relative URIs (as some apps do)
rather than long absolute ones with embedded instructions and state.

But if the webapp must for some reason reside one one page,
document.hashchange might be the best solution. But IMO apps should
span multiple pages where they can.



More information about the whatwg mailing list