¿Para qué sirve el shebang / hashbang (#!) En Facebook y las nuevas URL de Twitter?

Me acabo de dar cuenta de que las largas y complicadas URL de Facebook que estamos acostumbrados ahora se ven así:

http://www.facebook.com/example.profile#!/pages/Another-Page/123456789012345

Por lo que puedo recordar, a principios de este año era solo una secuencia normal de fragmento de URL (comenzando con # ), sin el signo de admiración. Pero ahora es un shebang o hashbang ( #! ), Que solo he visto anteriormente en scripts de shell y scripts de Perl.

Las nuevas URL de Twitter ahora también cuentan con el #! símbolos. Una URL de perfil de Twitter, por ejemplo, ahora se ve así:

http://twitter.com/#!/BoltClock

Hace #! ahora juegan algún papel especial en las URL, como para cierto marco de Ajax o algo así, ya que las nuevas interfaces de Facebook y Twitter ahora están en gran parte Ajaxified. ¿El uso de esto en mis URL beneficiará mi aplicación web de alguna manera?

Esta técnica ahora está en desuso .

Esto solía decirle a Google cómo indexar la página.

https://developers.google.com/webmasters/ajax-crawling/

Esta técnica ha sido suplantada principalmente por la capacidad de utilizar la API de historial de JavaScript que se introdujo junto con HTML5. Para una URL como www.example.com/ajax.html#!key=value , Google verificará la URL www.example.com/ajax.html?_escaped_fragment_=key=value para obtener una versión que no sea AJAX de los contenidos.

El octothorpe / number-sign / hashmark tiene un significado especial en una URL, normalmente identifica el nombre de una sección de un documento. El término preciso es que el texto que sigue al hash es la parte de anclaje de una URL. Si utiliza Wikipedia, verá que la mayoría de las páginas tienen una tabla de contenido y puede saltar a secciones dentro del documento con un delimitador, como por ejemplo:

https://en.wikipedia.org/wiki/Alan_Turing#Early_computers_and_the_Turing_test

https://en.wikipedia.org/wiki/Alan_Turing identifica la página y Early_computers_and_the_Turing_test es el ancla. La razón por la que Facebook y otras aplicaciones basadas en Javascript (como mis propios Wood & Stones ) utilizan anclas es que quieren hacer que las páginas sean favoritas (como sugiere un comentario en esa respuesta) o respaldar el botón de retroceso sin volver a cargar toda la página. servidor .

Para admitir marcadores y el botón Atrás, debe cambiar la URL. Sin embargo, si cambia la parte de la página (con algo como window.location = 'http://raganwald.com'; ) a una URL diferente o sin especificar un ancla, el navegador cargará toda la página desde la URL. Prueba esto en Firebug o en la consola de Javascript de Safari. Carga http://minimal-github.gilesb.com/raganwald . Ahora en la consola de Javascript, escriba:

 window.location = 'http://minimal-github.gilesb.com/raganwald'; 

Verá la actualización de la página desde el servidor. Ahora escribe:

 window.location = 'http://minimal-github.gilesb.com/raganwald#try_this'; 

Aha! ¡Sin actualización de página! Tipo:

 window.location = 'http://minimal-github.gilesb.com/raganwald#and_this'; 

Todavía no hay actualización. Use el botón Atrás para ver que estas URL se encuentran en el historial del navegador. El navegador se da cuenta de que estamos en la misma página, pero simplemente cambia el ancla, por lo que no se recarga. Gracias a este comportamiento, podemos tener una sola aplicación de Javascript que aparezca en el navegador para estar en una ‘página’ pero que tenga muchas secciones de marcadores que respeten el botón Atrás. La aplicación debe cambiar el delimitador cuando un usuario ingresa diferentes ‘estados’, y del mismo modo si un usuario usa el botón Atrás o un marcador o un enlace para cargar la aplicación con un delimitador incluido, la aplicación debe restaurar el estado apropiado.

Así que ahí lo tienes: los anclajes proporcionan a los progtwigdores de Javascript un mecanismo para crear aplicaciones que sean bookmarkable, indexables y amigables con el botón de retroceso. Esta técnica tiene un nombre: es una interfaz de una sola página .

ps Hay un cuarto beneficio de esta técnica: cargar contenido de la página a través de AJAX y luego inyectarlo en el DOM actual puede ser mucho más rápido que cargar una página nueva. Además del aumento de velocidad, se pueden realizar otros trucos como cargar ciertas partes en el fondo bajo el control del progtwigdor.

pps Teniendo en cuenta todo eso, el ‘bang’ o signo de admiración es una pista más del rastreador web de Google que la misma página se puede cargar desde el servidor en una URL ligeramente diferente. Ver Ajax Crawling . Otra técnica es hacer que cada enlace apunte a una URL accesible para el servidor y luego usar un discreto Javascript para convertirlo en un SPI con un anclaje.

Aquí está el enlace clave de nuevo: el manifiesto de la interfaz de una sola página

Primero que nada: soy el autor del Manifiesto de interfaz de página única citado por Raganwald

Como Raganwald ha explicado muy bien, el aspecto más importante del enfoque de Interfaz de página única (SPI) utilizado en FaceBook y Twitter es el uso de hash # en las URL

El personaje ! se agrega solo para fines de Google, esta notación es un “estándar” de Google para rastrear sitios web intensivos en AJAX (en los sitios web de la Interfaz de página única extrema). ¡Cuando el rastreador de Google encuentra una URL con #! sabe que existe una URL convencional alternativa que proporciona el mismo “estado” de página, pero en este caso, el tiempo de carga.

¡A pesar de #! La combinación es muy interesante para SEO, solo es compatible con Google (hasta donde sé), con algunos trucos de JavaScript puedes construir sitios web SPI compatibles con SEO para cualquier rastreador web (Yahoo, Bing …).

¡El Manifiesto SPI y las demos no usan el formato de Google ! en hashes, esta notación podría agregarse fácilmente y el rastreo de SPI podría ser aún más fácil (la notación UPDATE: now! se usa y sigue siendo compatible con otros motores de búsqueda).

Eche un vistazo a este tutorial , es un ejemplo de un sitio ItsNat SPI simple pero puede elegir algunas ideas para otros marcos, este ejemplo es compatible con SEO para cualquier rastreador web.

El problema difícil es generar cualquier (o seleccionado) “estado de página AJAX” como HTML simple para SEO, en ItsNat es muy fácil y automático, el mismo sitio es en el mismo tiempo SPI o página basada en SEO (o cuando JavaScript está deshabilitado para accesibilidad). Con otros frameworks web, puede seguir el enfoque de doble sitio, un sitio es SPI y otro basado en SEO, por ejemplo, Twitter utiliza esta técnica de “doble sitio”.

Sería muy cuidadoso si está considerando adoptar esta convención hashbang.

Una vez que hashbang, no puedes volver atrás. Este es probablemente el problema más complicado. La publicación de Ben plantea el punto de que cuando pushState se adopte más ampliamente, entonces podemos dejar atrás hashbangs y volver a las URL tradicionales. Bueno, el hecho es que no puedes. Antes mencioné que las URL son para siempre, se indexan y archivan y, en general, se mantienen. Para agregar a eso, las URL geniales no cambian. No queremos desconectarnos de todos los enlaces valiosos a nuestro contenido. Si ha implementado URL hashbang en cualquier punto y luego desea cambiarlas sin romper enlaces, la única forma en que puede hacerlo es ejecutando JavaScript en el documento raíz de su dominio. Siempre. No es de ninguna manera temporal, estás atrapado con eso.

Realmente desea utilizar pushState en lugar de hashbangs , porque hacer que sus URL sean feas y posiblemente rotas para siempre es una desventaja colosal y permanente para hashbangs.

Para tener un buen seguimiento de todo esto, Twitter, uno de los pioneros de la URL de hashbang y la interfaz de una sola página, admitió que el sistema de hashbang fue lento a largo plazo y que en realidad han comenzado a revertir la decisión y volviendo a enlaces de la vieja escuela.

El artículo sobre esto está aquí.

¡Siempre asumí el ! simplemente indicó que el fragmento de hash que siguió correspondía a una URL, con ! tomando el lugar del sitio raíz o dominio. Podría ser cualquier cosa, en teoría, pero parece que a la API de rastreo AJAX de Google le gusta de esta manera.

El hash, por supuesto, solo indica que no está realizándose una nueva recarga de la página, así que sí, es para propósitos de AJAX. Editar: Raganwald hace un trabajo encantador al explicar esto con más detalle.

Las respuestas anteriores describen bien por qué y cómo se usa en Twitter y Facebook, lo que extrañé es una explicación de lo que # hace de forma predeterminada …

En una aplicación ‘normal’ (no en una sola página) puede anclar con hash a cualquier elemento que tenga id, colocando esa identificación de elementos en url después de hash #

Ejemplo:

(en Chrome) Haga clic en F12 o Rihgt Mouse e Inspect element

enter image description here

luego tome id="answer-10831233" y agregue a url como sigue

https://stackoverflow.com/questions/3009380/whats-the-shebang-hashbang-in-facebook-and-new-twitter-urls-for#answer-10831233

y obtendrás un enlace que salta a ese elemento en la página

¿Para qué sirve el shebang / hashbang (#!) En Facebook y las nuevas URL de Twitter?

Al usar # de la manera descrita en las respuestas anteriores, se está introduciendo un comportamiento conflictivo … aunque no me perdería el sueño … ya que Angular se convirtió en algo así como un estándar …