Re: Proposal: Navigation of JSON documents with html-renderer-script link relation

On 2/11/2011 6:55 AM, Anne van Kesteren wrote:
> On Fri, 11 Feb 2011 14:48:26 +0100, Kris Zyp <kris@sitepen.com> wrote:
>> Increasingly, web applications are centered around JSON-based content,
>> and utilize JavaScript to render JSON to HTML. Such applications
>> (sometimes called single page applications) frequently employ changes to
>> the hash portion of the current URL to provide back/forward navigation
>> and bookmarkability. However, this is largely viewed as an awkward hack,
>> and is notoriously problematic for search engines (Google has a hash to
>> query string conversion convention, which is also highly inelegant). We
>> need support for first class navigation of JSON documents, while still
>> leveraging HTML rendering technology.
>
> What is wrong with the more generically applicable history.pushState()?
>
>
This proposal is about creating a proper causal link between URLs,  that
return JSON representations, and the correct associated rendering. The
pushState proposal doesn't create handling for JSON data, it just
aliases URLs once a page is loaded. The pushState function adds URL
aliases as JS-handled history entries, but this does nothing to help the
situation if I send someone a link to a state that doesn't have that URL
aliased in the browser. By allowing the page entry point to be the
underlying JSON data, we have a solid and sound starting point for
building a view, without having to create intermediate HTML pages that
serve no purpose but to load the associated JSON and try to recreate
history entries so it can hang on to the DOM. The pushState API is
definitely useful, but this proposal is about starting in the right
place, and if the core content/data of your application is JSON, that's
the correct entry point, using pushState to emulate that just devolves
to a hack.

Thanks,
Kris

Received on Friday, 11 February 2011 14:14:27 UTC