¿Cuál es mejor pushstate o location.hash?

window.location.hash vs HTML5 history.pushstate . ¿Cuál de estos sería mejor para cumplir con la url con la solicitud de ajax y por qué? Gracias.

location.hash tiene un mejor soporte que el método history.pushState .
La ventaja del método pushState es que puede vincular un estado a la entrada del historial.
Si no necesita este objeto de estado, le recomiendo usar la propiedad location.hash para tener una mejor compatibilidad con los navegadores más antiguos.

 location.hash = 'new-hash'; console.log(history.state); // null or undefined history.pushState({extraData: "some state info"}, '', 'new-hash'); //<--- console.log(history.state); // [object Object] = {"extraData": "some state info"} 

Pushstate es el futuro. Es mejor porque:

  1. Se ve más limpio.
  2. Al volver a visitar un enlace profundo, puede visualizar datos reales del servidor para respaldar cosas como SEO y Facebook Open Graph (ambos envían arañas para raspar el html de su página).
  3. Los servidores no tienen acceso a los datos de las tags hash, por lo que no los ve en los registros de su servidor, por lo que ayudan a algunos con los análisis.
  4. Ayuda a corregir problemas de tags hash. Por ejemplo, tuve una reescritura Nginx para redirigir a los usuarios que visitan mi aplicación a la misma url https. Funciona en todos los navegadores, pero Safari te redirigirá al dominio sin el hash (¡tan molesto!).
  5. En realidad, puede usar la etiqueta hash para lo que se pretendía, enlaces profundos a secciones de páginas largas.
  6. Puede recurrir a las solicitudes de back-end HTTP reales para el navegador que no admiten el estado push O puede recurrir a la utilización de la etiqueta hash. Ambos requieren una implementación adicional, pero son fácilmente realizables con un poco de trabajo.

Vea esta charla del diseñador de Github para obtener más información: http://warpspire.com/talks/responsive/

history.pushState es mejor que location.hash . pero es una característica HTML5. así que siempre es mejor tener un método alternativo como el siguiente.

 if (typeof(window.history.pushState) == 'function') { window.history.pushState(null, path, path); } else { window.location.hash = '#!' + path; } 

Estoy de acuerdo con las otras respuestas, pero aquí hay algunos argumentos a favor de location.hash :

  • funciona en todos los navegadores, incluido Internet Exploder TM
  • history.pushState es un estándar en desarrollo, y la API puede cambiar en el futuro
  • si los usuarios abren un enlace en una nueva ventana / pestaña, un hash-URL se asegura de que no haya una solicitud del servidor necesaria para cargar la página (si se configuran los encabezados de almacenamiento en caché correctos)
  • La configuración del servidor es fácil, ya que todo el servidor que ve es la URL sin hash-part

editar: Olvidé uno

  • con hashtags, puede usar enlaces reales ( a href ). Por lo tanto, no tiene que configurar escuchas por clic, lo que mejora el rendimiento y reduce el tamaño del código.

Las ventajas / desventajas de window.location.hash frente a HTML5 history.pushstate están determinadas en gran medida por la forma exacta en que desea que su página se degrade.

Aquí, puede estar interesado en la degradación elegante en dos escenarios diferentes:

El primero es un cliente que no tiene javascript habilitado, o un bot / crawler automatizado que visita su sitio. Esto es particularmente importante desde una perspectiva de SEO. Si su página web / aplicación web usa hash-urls, el contenido que está disponible a través de estos enlaces no está disponible para estos usuarios finales. Esto es definitivamente un problema si está haciendo secciones de contenido disponibles solo a través de hash-urls sin inconvenientes. Sin embargo, definitivamente no es un problema si está usando enlaces hash-tag para modificar el estado de la aplicación que simplemente no conserva el significado si la página se degrada.

Como ejemplo, considere un escenario en el que tenga una página con tres secciones de texto disponibles en tres tabs en un widget de diseño con tabs. Ahora hay dos escenarios posibles: en el primero, estaría cargando todo el contenido durante la carga de la página, y el widget con tabs simplemente servirá para ocultar otras secciones y mostrar una sección en particular. Por lo tanto, si usa hash-urls en los enlaces que usa para construir los pulgares de las tabs, los está usando solo para cambiar el estado de la aplicación del lado del cliente. Cuando javascript está desactivado / no está disponible, simplemente el javascript utilizado para construir el diseño con tabs no se ejecuta, y todo el contenido está disponible de forma inmediata: un repliegue elegante y razonable. Los diferentes estados de aplicación simplemente no existen en este caso, por lo que los hash-urls se degradan de nuevo a solo apuntando a anclajes en html, el propósito previsto. En lugar de hash-urls si usaras html5 pushstate en este caso, sería una mala idea. La razón por la que un usuario puede marcar el enlace a una pestaña en particular. Porque su servidor debería tomar esa url y presentar al usuario el estado del lado del cliente que está esperando. Esto no es bueno para una architecture de servidor delgado donde el lado del cliente debe encargarse de la administración de su propio estado. Por supuesto, puede ignorar ese aspecto en el lado del servidor y dejar que el cliente verifique la url justo al comienzo al cargar la página y luego cambiar al estado de aplicación apropiado. Pero todavía no es una buena idea porque su sistema de enrutamiento del lado del servidor está preocupado con la sobrecarga de fragmentos de URL adicionales que debe ignorar, mientras que no debería preocuparse por ese fragmento en absoluto desde una perspectiva estética. Esto se corresponde exactamente con el requisito para el cual se diseñaron las direcciones hash y se recomienda encarecidamente utilizarlas. Si, en cambio, en las tres secciones, el texto se carga dinámicamente cuando se hace clic en un tabulador en particular, entonces no es una buena idea utilizar hash-urls. El motivo es que el usuario simplemente no tendrá forma de acceder al contenido vinculado si JavaScript no está disponible. Esto es particularmente malo para SEO. En este escenario, si maneja las direcciones URL (lo que en el escenario normal sería “secuestrado” y “ajaxificado”) en el servidor para hacer que el contenido esté disponible en general, es excelente tanto desde el punto de vista de la experiencia del usuario final como de SEO.

El segundo escenario es un cliente que tiene un navegador anticuado que no admite html5 pushstates. Si bien los puntos anteriores aún se mantienen, además, también argumentaría que forzar a los usuarios sin empuje con el mismo nivel de degradación que no-JavaScript no es justificable. Muchos usuarios finales simplemente no tendrán idea de por qué están recibiendo una versión degradada.

Le recomendaría que no se identifique con la motivación dogmática de usar la última tecnología siempre, y decida la mejor opción para su escenario de uso.

Personalmente prefiero pushState porque hace que las URL se vean mejor y creo que es importante para la experiencia del usuario.

Puede usar history.pushState con una recuperación de hash utilizando el archivo polyfill history.js si desea usar pushState, pero no desea tener problemas con la compatibilidad anterior con el navegador.

Actualmente, pushState es compatible con todos los navegadores modernos. Por pushState tanto, pushState es mejor que location.hash , pero es una función HTML5.

Entonces, location.hash no está muerto, de hecho estará disponible por mucho, mucho tiempo.

Una buena forma de usar esto es con una lib que sea compatible con pushState , pero también se degrada graciosamente a usar location.hash .
Ejemplohttps://github.com/browserstate/history.js

Además location.hash seguirá siendo útil para saltar a anclas con nombre. pushState será una gran ayuda en la construcción de aplicaciones web. Espero con ansias usarlo.

Esta es una pregunta bastante antigua (5 años + en el momento de esta respuesta) pero muchos comentarios sobre las respuestas existentes piden una actualización basada en el estado “actual” de las cosas.

Aquí está el trato:

HTML5 pushState es compatible con todos los principales navegadores. Si también está soportando navegadores antiguos, history.js proporciona un gran polyfill que le permite usar pushState de forma nativa y hacer que vuelva fácilmente a las URL heredadas para navegadores más antiguos. Ahora que pushState tiene soporte nativo no significa, sin embargo, que definitivamente sea el camino a seguir.

Hay un punto muy importante que no surgió en ninguna de las respuestas anteriores y es que las URL hash y las URL pushState no solo son diferentes en la forma en que aparecen, sino que también son diferentes en la forma en que funcionan. Esta diferencia fundamental entre los dos podría llevarlo a elegir uno sobre el otro.

pushState es más bonito y más limpio y se puede utilizar para falsificar por completo la navegación en su sitio / en su aplicación. Por ejemplo, GitHub lo usa para reemplazar toda la navegación de forma invisible. Cuando hace clic en cualquier enlace de su sitio, javascript se usa para interceptar ese clic y convertirlo en una solicitud AJAX que actualiza el contenido de la página sin cargar una página nueva, mientras que la URL en la barra de ubicación cambia para coincidir con el contenido a buscar Esto es lo que significaba que se usaba el estado de empuje .

En el caso de GitHub, http: // mysite / page1 y http: // mysite / page2 son ambas URL válidas. Son enlaces “reales” con contenido “real”, y al visitar inicialmente cualquiera de las páginas pasa por el enfoque MVC tradicional. GitHub utiliza pushState para la navegación en los navegadores modernos, pero no lo requiere, es decir, pushState se utiliza como un “complemento de funciones” para (en su opinión) llevar a una mejor experiencia de usuario en lo que respecta a la navegación. Cuando copia el enlace en la barra de direcciones del navegador, está copiando un enlace que se formó a través de javascript y pushState, pero un enlace que, no obstante, es real y válido.

Sin embargo, si estás empezando desde cero y creando una aplicación de una sola página y no estás usando un framework MVC, lo más probable es que solo tengas una sola página, especialmente si no estás utilizando un backend dynamic (es decir, todo el contenido se recupera mediante javascript , nunca generado por un servidor). En este caso, si usa pushState sobre las direcciones hash, tendrá que manejar el caso de que la URL en el navegador no sea la URL real. Lo ilustraré

El usuario carga su aplicación de una sola página: http: // mysite / mainpage

En este punto, la barra del navegador contiene el enlace real a su aplicación y llevará al usuario a la misma vista que ve actualmente: la página principal. Ahora hacen clic en un enlace que los llevará a una “página” que muestra los detalles de alguna actividad. En este punto, desea actualizar la barra de ubicación para indicar el cambio de estado. O bien utiliza una URL hash y su barra de direcciones se ve como http: // mysite / mainpage # charts / 1 o usa pushState y lo engaña para que se convierta en http: // mysite / mainpage / charts / 1

Si usó pushState, ese no es un enlace real . Navegar a través de los botones atrás / adelante del navegador funcionará bien y el usuario pasará de la página principal a la página de detalles en la barra de ubicación y en la aplicación (suponiendo que maneje el cambio de estado correctamente), pero si el usuario lo marca como favorito o copia y pega el enlace para compartirlo, se requerirá vudú adicional en el servidor.

Tendrá que redirigir las solicitudes a / mainpage / charts / 1 a / mainpage y luego usar JS para resolver la URL real y llevar a cabo la operación de cambio de estado deseada. Un redireccionamiento del servidor es absolutamente necesario. No puede alojar esta página en AWS o en su disco local sin un servidor http con secuencias de comandos.

Ahora bien, si usaba direcciones hash, su URL que el usuario habría visto e interactuado con ella habría sido http: // mysite / mainpage # / charts / 1 y esa es una url válida y real . Los navegadores entienden que solo hay una página, y si el usuario copia y pega el enlace o lo marca, solo tiene que manejar el estado de hash en javascript y no necesita ninguna magia del servidor para que todo funcione.

Lo que nadie parece mencionar es que los enlaces pushState y hash no son mutuamente excluyentes . pushState es solo una API para manipular la ubicación del navegador que es visible para el usuario e implementar una navegación hacia atrás / adelante confiable en los navegadores modernos. No dice nada sobre cómo debería ser su esquema de URL.

En 2017, Google y casi todos los demás robots aptos para JS entienden las URL hash y las atraviesan sin problemas. Google quiere que uses el #! abominación para fines de optimización SEO, pero incluso si no lo hace, su sitio será navegable muy bien.

La respuesta correcta es usar lo que mejor se adapte a sus necesidades. Si tiene URL reales y quiere falsificar la navegación entre ellas, use pushState y continúe (opcionalmente con un relleno policial para navegadores más antiguos). Pero si tiene una aplicación de una sola página, no pretenda no hacerlo (a menos que tenga una muy buena razón). Use las URL hash para hacer su vida más fácil y no introduzca problemas innecesarios y luego use pushState para manipular esas URL hash para aprovechar mejor el respaldo / retroceso .