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


743

Acabo de notar que las URL largas y complicadas de Facebook a las que estamos acostumbrados ahora se ven así:

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

Hasta donde 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 hashbang ( #!), que anteriormente solo había visto en scripts de shell y scripts de Perl.

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

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

¿ #!Ahora juega algún papel especial en las URL, como para un cierto 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 URL beneficiaría de alguna manera mi aplicación web?


130
Hmm Tuve que buscar lo que shebangera ... en.wikipedia.org/wiki/Shebang_%28Unix%29
JYelton

32
FWIW, no son solo scripts de shell y perl, sino que cualquier script se ejecuta en un sistema similar a Unix. Los #! línea le dice a la concha lo que el intérprete de guión es que ... por supuesto, mi comentario no tiene nada que ver con Facebook o Twitter
bluesmoon

3
Gracias, Hacker News! (Dejándolo como un comentario para no topar mi pregunta, no veo la necesidad de hacerlo)
BoltClock

15
El hashbang se glorifica por todas las razones equivocadas, rompe las mejores prácticas y destruye la posibilidad de mejora progresiva y degradación elegante. Por favor, use las otras soluciones disponibles.
Balupton

2
¡Tenga en cuenta que en octubre de 2015, Google desaprobó el hashbang que introdujeron en 2009 ! Entonces, para nuevas aplicaciones, ya no debería tener que hacer esto para SEO. En este momento solo hay un sutil comentario en blanco en la parte superior de las páginas de especificaciones de Google: "Esta recomendación está oficialmente en desuso a partir de octubre de 2015".
Bart

Respuestas:


483

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 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=valuepara obtener una versión de contenido que no sea AJAX.


16
¿Estás seguro de que eso es todo? A menudo encuentro que la carga de la página se cuelga en una URL shebang en Facebook (incluso después de muchas recargas), pero si eliminas manualmente el # !, funciona. Sin mencionar que a menudo obtienes "1.5 URL" (es decir, la URL anterior permanece y solo se le agrega la parte nueva (es decir, photo.php? Id = ... dos veces, pero con diferentes identificadores). Sin mencionar que " #! "también se agrega a las URL de Facebook-mail, que probablemente no son (y no deberían ser) indexables. En cualquier caso, encuentro que el shebang es extremadamente molesto ya que parece ser la razón de tantas fallas en mi página lenta línea de casa.
Pedery

11
El hecho de que Facebook tenga errores no hace que esos errores sean culpa de dos caracteres en la URL. Si el sitio está codificado correctamente para comprenderlos y generarlos, las URL AJAX rastreables son bastante útiles. Muchas otras cosas en Facebook también fallan.
ceejayoz

15
@Pedery: Solo he visto ese problema con Facebook. Estoy de acuerdo, me lleva a la pared (no Facebook) todo el tiempo.
BoltClock

55
En cuanto a los motores de búsqueda, tener una URL indexable AJAX no hace que la página se indexe más que tener una URL indexable no AJAX. Facebook usa este formato de URL para algo más que el beneficio de Google: también hace que las páginas a las que se accede a través de AJAX en Facebook se puedan marcar como favoritos cuando de otra manera no lo serían.
ceejayoz

13
Para algunas advertencias interesantes, también lea este artículo: isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs
Michael Stum

215

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 porción de anclaje de una URL. Si usa 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 ancla, como:

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

https://en.wikipedia.org/wiki/Alan_Turingidentifica la página y Early_computers_and_the_Turing_testes el ancla. La razón por la que Facebook y otras aplicaciones basadas en Javascript (como mi propio Wood & Stones ) usan anclas es porque quieren que las páginas se marquen (como lo sugiere un comentario en esa respuesta) o admitan el botón de retroceso sin volver a cargar toda la página desde el servidor .

Para admitir los marcadores y el botón de retroceso, debe cambiar la URL. Sin embargo, si cambia la parte de la página (con algo parecido 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 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á que la página se actualiza desde el servidor. Ahora escriba:

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

¡Ajá! ¡No se actualiza 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 se da cuenta de que estamos en la misma página pero que solo estamos cambiando el ancla, por lo que no se vuelve a cargar. Gracias a este comportamiento, podemos tener una sola aplicación Javascript que parece estar en el navegador en una 'página' pero que tiene muchas secciones marcables que respetan el botón de retroceso. 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 de retroceso 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 tiene: las anclas proporcionan a los programadores de Javascript un mecanismo para crear aplicaciones que se puedan marcar, indexar y que sean fáciles de usar. Esta técnica tiene un nombre: es una interfaz de página única .

ps Hay un cuarto beneficio para 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, se pueden realizar más trucos como cargar ciertas partes en segundo plano bajo el control del programador.

pps Dado todo eso, el "estallido" o el signo de exclamación es una pista más para el rastreador web de Google de que se puede cargar exactamente la misma página desde el servidor en una URL ligeramente diferente. Ver Ajax arrastrándose . Otra técnica es hacer que cada enlace apunte a una URL accesible para el servidor y luego usar Javascript discreto para cambiarlo a un SPI con un ancla.

Aquí está el enlace clave nuevamente: el Manifiesto de la interfaz de página única


14
"Sin embargo, una aplicación sin esta optimización aún puede rastrearse si el rastreador web desea indexarla". Realmente no. El hash no se envía al servidor.
Chris Broadfoot

77
solo para información: self.document.location.hashproporciona el valor de este hash
Kevin

12
El hash no se envía al servidor. ¡Buena atrapada!
raganwald

36
Toda esta respuesta, aparte del párrafo único "pps" es redundante.
Carreras de ligereza en órbita el

21
@imaginonic: llego tarde, pero tan perfectamente elaborado como está, el 90% no toca el #!aspecto de mi pregunta en absoluto . Por eso dijo que es redundante. El número de votos a favor aquí probablemente se deba al alto tráfico cuando mi pregunta llegó a Hacker News junto con la longitud total de esta respuesta.
BoltClock

111

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

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

El carácter !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 extremos de interfaz de página única). Cuando el rastreador de Google encuentra una URL con #!él, sabe que existe una URL convencional alternativa que proporciona el mismo "estado" de página, pero en este caso en el tiempo de carga.

A pesar de que la #!combinación es muy interesante para el SEO, solo es compatible con Google (que yo sepa), con algunos trucos de JavaScript puedes construir sitios web SPI compatibles con SEO para cualquier rastreador web (Yahoo, Bing ...).

El Manifiesto SPI y las demostraciones no usan el formato de !hash de Google , esta notación podría agregarse fácilmente y el rastreo SPI podría ser aún más fácil (ACTUALIZACIÓN: ¡ahora! La notación se usa y sigue siendo compatible con otros motores de búsqueda).

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


3
¿Qué pasa con el principio de mejora progresiva? El sitio web no debe fallar debido a JavaScript deshabilitado. Y créanme, javascript está deshabilitado no solo en los navegadores obsoletos, sino también por muchos usuarios conscientes de la seguridad a quienes no les gusta ejecutar JS aleatorios.
Roman Royter

88

Tendría mucho cuidado si está considerando adoptar esta convención hashbang.

Una vez que hashbang, no puedes regresar. Este es probablemente el problema más difícil. La publicación de Ben presentó el punto de que cuando pushState se adopta más ampliamente, podemos dejar atrás los hashbangs y volver 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 mantienen. Para agregar a eso, las URL geniales no cambian. No queremos desconectarnos de todos los valiosos enlaces a nuestro contenido. Si ha implementado URLs hashbang en algún momento, entonces desea cambiarlas sin romper los enlaces, la única forma de hacerlo es ejecutando JavaScript en el documento raíz de su dominio. Siempre. No es temporal, estás atrapado con eso.

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


Creo que su crítica a los hashbangs es válida, pero usar solo pushState como un sustituto significa que perderíamos la capacidad de cargar contenido dentro de una aplicación de una sola página basada en la URL. Entonces, las URL no se pueden compartir.
Lucas

Tuve un problema similar en mi trabajo: utilizamos Page.js (que usa pushState) para la navegación de una sola página, donde anteriormente usábamos Hasher y Crossroads (hash-bashed). Como resultado, necesitábamos rescatar caminos como /blah#foo/feep/baz?stuff=nonsense. El nuevo equivalente de ruta sería /blah/foo/feep/baz?stuff=nonsense(nota # reemplazada por /). Lo hice simplemente teniendo una ruta en mi configuración que capturó /blahy verificó si tenía un has, si es así, agregando el contenido de ese hash después de una barra inclinada. Rescató.
Gert Sønderby

16

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.

El artículo sobre esto está aquí.


9

Siempre asumí que lo que !acabo de indicar era que el fragmento de hash que seguía correspondía a una URL, con !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 AJAX de Google le gusta de esta manera.

El hash, por supuesto, solo indica que no está ocurriendo una recarga real de la página, por lo que sí, es para fines AJAX. Editar: Raganwald hace un trabajo encantador al explicar esto con más detalle.


-2

Las respuestas anteriores describen bien por qué y cómo se usa en Twitter y Facebook, lo que me perdí es una explicación de lo que #hace por defecto ...

En una aplicación 'normal' (no una sola página) puede anclar hasha cualquier elemento que tenga identificación colocando esa identificación de elementos en la url después del hash#

Ejemplo:

(en Chrome) Haga clic F12o Rihgt MouseyInspect element

ingrese la descripción de la imagen aquí

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

/programming/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 shebang / hashbang (#!) En Facebook y nuevas URL de Twitter?

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


2
La respuesta de Raganwald contiene la explicación que dijiste que te perdiste. Aun así, no veo cómo la pregunta se beneficia de un tutorial sobre cómo funciona #: la pregunta asume que el lector ya está familiarizado con los fragmentos de URL, y que la funcionalidad no es realmente relevante aquí de todos modos, excepto por su comentario sobre el comportamiento conflictivo .
BoltClock

@BoltClock Hola BoltClock, pero sin explicar cuál es el comportamiento predeterminado diciendo que 'entrará en conflicto' no le da al lector ninguna idea de lo que está en juego, qué tipo de funcionalidad se está perdiendo potencialmente ... Simplemente me gustaría dar buenas respuestas con imágenes si Veo que falta algo que esté tan completo como pueda hacerlos ...
Matas Vaitkevicius
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.