In the process of developing an internal dashboard for my website specifically designed for users who are logged in and not meant to be indexed or crawled by search engines. This dashboard primarily functions as a single-page application and does not prioritize having aesthetically pleasing URLs. In case JavaScript is disabled, the dashboard loses its functionality without progressive enhancement.
Essentially, what I require is the capability to navigate between different states within the dashboard using the back/forward buttons, such as different modal windows being open. It's crucial that I can also provide external links directly to a specific state within the dashboard (e.g., indicating if Modal A was open), like sending links via emails to users to access the dashboard.
Given these requirements, should I opt for the traditional hash bangs (#!) method or utilize HTML5 pushState? Considering that pushState would necessitate implementing history.js for compatibility with older browsers. From an architectural standpoint, if the dashboard is accessible through the following URL:
http://example.com/dashboard
wouldn't the process of determining a particular modal state be almost identical whether utilizing pushState or onhashchange? In other terms:
http://example.com/dashboard#!modalA/state1
or
http://example.com/dashboard/modalA/state1
both scenarios would involve parsing client-side (handled by a framework) to determine how to display the current state of the dashboard. Regardless, my backend controller would still map all dashboard URLs to /dashboard/* since the client takes care of handling all state-related matters.
Is there something crucial that I may be overlooking? Although it may not have a significant impact, I am currently using CanJS, which supports both hash events and pushState functionalities.
Note: This question doesn't pertain specifically to Google's hashbang proposal but covers the general use of # signifying onhashchange events.