it-swarm-es.tech

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

Acabo de notar que las largas y complicadas URL de Facebook a las que estamos acostumbrados ahora son 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 cadena normal similar a un fragmento de URL (comenzando con #), sin el signo de exclamación. Pero ahora es un Shebang o un hashbang (#!), que anteriormente solo había visto en los scripts de Shell y en los scripts de Perl.

El nuevo Twitter URL ahora también presenta los símbolos #!. Una URL de perfil de Twitter, por ejemplo, ahora se ve así:

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

¿El #! ahora desempeña algún papel especial en las URL, como para un determinado marco de Ajax o algo así, ya que las nuevas interfaces de Facebook y Twitter ahora están en gran parte Ajaxified? ¿Usar esto en mis URLs beneficiaría a mi aplicación web de alguna manera?

735
BoltClock

Esta técnica está ahora en desuso .

Este usado para 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 usar 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 no AJAX de los contenidos.

479
ceejayoz

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 ancla de una URL. Si utiliza Wikipedia, verá que la mayoría de las páginas tienen una tabla de contenido y puede saltar a las secciones dentro del documento con un ancla, como:

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 controladas por Javascript (como la mía Wood & Stones ) usan anclas es que quieren que las páginas se puedan marcar como favoritos (como sugiere un comentario en esa respuesta) o admitir el botón de retroceso sin volver a cargar toda la página desde el servidor .

Para admitir los 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 la consola de Javascript de Firebug o Safari. Cargar 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';

Jajaja No hay actualización de la 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 están en el historial del navegador. El navegador advierte que estamos en la misma página pero que solo cambiamos el ancla para que no se vuelva a cargar. Gracias a este comportamiento, podemos tener una única aplicación de Javascript que parece que el navegador está en una 'página' pero que tiene muchas secciones que se pueden marcar y que respetan el botón Atrás. La aplicación debe cambiar el ancla cuando un usuario ingresa diferentes "estados", y de la misma manera si un usuario usa el botón Atrás o un marcador o un enlace para cargar la aplicación con un ancla incluida, la aplicación debe restaurar el estado apropiado.

Así que ahí lo tienen: los anclajes proporcionan a los programadores de Javascript un mecanismo para crear aplicaciones aptas para marcadores, indexables y compatibles con el botón de retroceso. Esta técnica tiene un nombre: Es una Interfaz de página única .

pD. Hay una cuarta ventaja en esta técnica: cargar el 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 nueva página. Además del aumento de velocidad, otros trucos como cargar ciertas partes en el fondo pueden realizarse bajo el control del programador.

p.p.s. Dado todo eso, el 'bang' o el signo de exclamación es otra sugerencia para el rastreador web de Google de que la misma página se puede cargar desde el servidor en una URL ligeramente diferente. Ver Ajax Rastreo . Otra técnica es hacer que cada enlace apunte a una URL accesible al servidor y luego usar un Javascript discreto para convertirlo en un SPI con un ancla.

Aquí está nuevamente el enlace clave: El Manifiesto de la Interfaz de una sola página

215
raganwald

En primer lugar: soy el autor del Manifiesto de interfaz de una sola página citado por raganwald

Como ha explicado muy bien raganwald, 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 carácter ! se agrega solo para los fines de Google, esta notación es un "estándar" de Google para el rastreo de sitios web con uso intensivo de AJAX (en el extremo de los sitios web de interfaz de página única). Cuando el rastreador de Google encuentra una URL con #!, sabe que existe una URL convencional alternativa que proporciona la misma página "estado" pero, en este caso, en el tiempo de carga.

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

El SPI El manifiesto y las demostraciones no utilizan el formato ! de Google en hashes, esta notación se podría agregar fácilmente y SPI el rastreo podría ser aún más fácil (ACTUALIZAR: ¡ahora se usa la notación! compatible con otros buscadores).

Eche un vistazo a este tutorial , es un ejemplo de un sitio simple ItsNat SPI 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 está al mismo tiempo SPI o página basada para SEO (o cuando JavaScript está deshabilitado por accesibilidad). Con otros marcos web, puede seguir el enfoque de sitio doble, un sitio está basado en SPI y otra página basada en SEO, por ejemplo, Twitter utiliza esta técnica de "sitio doble".

111
jmarranz

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

Una vez que hashbang, no puedes volver. Este es probablemente el problema más pegajoso. La publicación de Ben expuso el punto de que cuando pushState se adopte más ampliamente, podemos dejar atrás los hashbangs y regresar a las URL tradicionales. Bueno, el hecho es que no puedes. Anteriormente dije que las URL son para siempre, se indexan y archivan y generalmente se guardan. Para agregar a eso, las URL frescas no cambian. No queremos desconectarnos de todos los enlaces valiosos a nuestro contenido. Si ha implementado las URL de hashbang en algún momento, entonces desea cambiarlas sin romper los enlaces, la única forma de hacerlo es ejecutando un poco de JavaScript en el documento raíz de su dominio. Siempre. No es de ninguna manera temporal, estás atrapado con eso.

Realmente quieres usar pushState en lugar de hashbangs , porque hacer que tus URL sean feas y posiblemente dañadas - para siempre - es un inconveniente colosal y permanente para los hashbangs.

84
Jeff Atwood

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

Artículo sobre esto está aquí.

16
kingmaple

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

El hash, por supuesto, solo indica que no se está produciendo una recarga de la página real, así que sí, es para AJAX propósitos. Edit: Raganwald hace un trabajo encantador explicando esto con más detalle.

9
Alan H.