Introduction

The web's existing history API is problematic for a number of reasons, which makes it hard to use for web applications. This proposal introduces a new window.appHistory API, which is more directly usable by web application developers to address the use cases they have for history introspection, mutation, and observation/interception.

The proposed API layers on top of the existing API and specification infrastructure, with well-defined interaction points. The main differences are that it is scoped to the current origin and frame, and it is designed to be pleasant to use instead of being a historical accident with many sharp edges. Some notable features:

• Allow easy conversion of cross-document navigations into single-page app same-document navigations, without fragile hacks like a global click handler.
• Provide a uniform way to signal single-page app navigations, including their duration.
• Provide a reliable system to tie application and UI state to history entries. (Better than the existing history.state.)
• Provides reliable events for notifying the application about navigations through the list of history entries, which they can use to synchronize application or UI state. (Better than the existing popstate and hashchange events.)

Read the complete Explainer.

Feedback

We'd love to hear from the community of developers as to whether this sounds like a worthwhile direction to explore, and in particular whether we should migrate it to the WICG for further discussion in its own dedicated repository.

For any general feedback or questions on the idea, especially any support for developing the idea, please use this thread. For specific technical questions or suggestions on the API, file issues on WICG/app-history where we can work through them in more detail. (Hopefully such questions can move to a dedicated WICG repository once we get general support.)