A cosa servono gli shebang / hashbang (#!) In Facebook e i nuovi URL di Twitter?

Ho appena notato che gli URL di Facebook lunghi e contorti a cui siamo abituati ora sembrano così:

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

Per quanto posso ricordare, all'inizio di quest'anno era solo una normale stringa simile a un frammento di URL (a partire da #), senza il punto esclamativo. Ma ora è uno shebang o hashbang ( #!), che in precedenza ho visto solo negli script shell e negli script Perl.

I nuovi URL di Twitter ora presentano anche i #!simboli. Un URL del profilo Twitter, ad esempio, ora assomiglia a questo:

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

Fa #!ora giocare un qualche ruolo speciale nella URL, come per un certo quadro Ajax o qualcosa del genere dal momento che le nuove interfacce di Facebook e Twitter sono ormai ampiamente Ajaxified?
L'utilizzo di questo nei miei URL gioverebbe in qualche modo alla mia applicazione Web?

Questa tecnica è ora obsoleta .

Questo era usato per dire a Google come indicizzare la pagina.

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

Questa tecnica è stata per lo più soppiantata dalla possibilità di utilizzare l'API della cronologia JavaScript introdotta insieme a HTML5. Per un URL come www.example.com/ajax.html#!key=value, Google controllerà l'URL www.example.com/ajax.html?_escaped_fragment_=key=valueper recuperare una versione non AJAX dei contenuti.

L'ottotorpe / numero-segno / hashmark ha un significato speciale in un URL, normalmente identifica il nome di una sezione di un documento. Il termine preciso è che il testo che segue l'hash è la parte di ancoraggio di un URL. Se usi Wikipedia, vedrai che la maggior parte delle pagine ha un sommario e puoi saltare alle sezioni all'interno del documento con un'ancora, come:

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

https://en.wikipedia.org/wiki/Alan_Turingidentifica la pagina ed Early_computers_and_the_Turing_testè l'ancora. La ragione per cui Facebook e altre applicazioni basate su Javascript (come il mio Wood & Stones ) usano ancore è che vogliono rendere le pagine segnalibro (come suggerito da un commento su quella risposta) o supportare il pulsante Indietro senza ricaricare l'intera pagina dal server .

Per supportare il bookmarking e il pulsante Indietro, è necessario modificare l'URL. Tuttavia, se si modifica la porzione di pagina (con qualcosa di simile window.location = 'http://raganwald.com';) in un URL diverso o senza specificare un ancoraggio, il browser caricherà l'intera pagina dall'URL. Prova questo nella console Javascript di Firebug o Safari. Load http://minimal-github.gilesb.com/raganwald. Ora nella console Javascript, digitare:

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

Vedrai la pagina aggiornare dal server. Ora digita:

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

Aha! Nessuna pagina di aggiornamento! Genere:

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

Ancora nessun aggiornamento. Usa il pulsante Indietro per vedere che questi URL sono nella cronologia del browser. Il browser nota che siamo sulla stessa pagina ma che stiamo cambiando l'ancora, quindi non si ricarica. Grazie a questo comportamento, possiamo avere una singola applicazione Javascript che appare al browser in una 'pagina' ma che ha molte sezioni con segnalibro che rispettano il pulsante Indietro. L'applicazione deve cambiare l'ancoraggio quando un utente immette "stati" diversi e allo stesso modo se un utente utilizza il pulsante Indietro o un segnalibro o un collegamento per caricare l'applicazione con un ancoraggio incluso, l'applicazione deve ripristinare lo stato appropriato.

Quindi il gioco è fatto: Anchors fornisce ai programmatori Javascript un meccanismo per creare applicazioni con segnalibri, indicizzabili e back-friendly. Questa tecnica ha un nome: è un'interfaccia a pagina singola .

ps C'è un quarto vantaggio in questa tecnica: caricare il contenuto della pagina tramite AJAX e quindi iniettarlo nel DOM corrente può essere molto più veloce del caricare una nuova pagina. Oltre all'aumento della velocità, ulteriori trucchi come il caricamento di determinate porzioni in background possono essere eseguiti sotto il controllo del programmatore.

pps Alla luce di tutto ciò, il "botto" o il punto esclamativo è un ulteriore suggerimento per il web crawler di Google che la stessa pagina esatta può essere caricata dal server in un URL leggermente diverso. Vedi Ajax Crawling . Un'altra tecnica consiste nel fare in modo che ciascun collegamento punti a un URL accessibile dal server e quindi utilizzare Javascript discreto per modificarlo in una SPI con un ancoraggio.

Ecco di nuovo il collegamento chiave: il manifesto dell'interfaccia a pagina singola

Prima di tutto: sono l'autore del Manifesto per l'interfaccia a pagina singola citato da raganwald

Come raganwald ha spiegato molto bene, l'aspetto più importante dell'approccio Single Page Interface (SPI) utilizzato in FaceBook e Twitter è l'uso dell'hash #negli URL

Il personaggio !viene aggiunto solo per scopi di Google, questa notazione è uno "standard" di Google per la scansione di siti Web intensivi su AJAX (negli estremi siti Web con interfaccia singola pagina). Quando il crawler di Google trova un URL con #!esso sa che esiste un URL convenzionale alternativo che fornisce lo stesso "stato" della pagina, ma in questo caso al momento del caricamento.

Nonostante la #!combinazione sia molto interessante per il SEO, è supportato solo da Google (per quanto ne so), con alcuni trucchi JavaScript puoi costruire siti web SPI SEO compatibili per qualsiasi web crawler (Yahoo, Bing ...).

Il Manifesto SPI e le demo non utilizzano il formato di Google !negli hash, questa notazione potrebbe essere facilmente aggiunta e la scansione SPI potrebbe essere ancora più semplice (AGGIORNAMENTO: ora! La notazione viene utilizzata e rimane compatibile con altri motori di ricerca).

Dai un'occhiata a questo tutorial , è un esempio di un semplice sito SPI ItsNat ma puoi scegliere alcune idee per altri framework, questo esempio è compatibile con SEO per qualsiasi crawler web.

Il difficile problema è generare qualsiasi (o selezionato) "stato della pagina AJAX" come semplice HTML per SEO, in ItsNat è molto semplice e automatico, lo stesso sito è contemporaneamente SPI o pagina basata per SEO (o quando JavaScript è disabilitato per accessibilità). Con altri framework Web è possibile seguire l'approccio del doppio sito, un sito è basato su SPI e un'altra pagina basata su SEO, ad esempio Twitter utilizza questa tecnica del "doppio sito".

Sarei molto attenti se si stanno prendendo in considerazione l'adozione di questa convenzione hashbang.

Una volta che hai hashbang, non puoi tornare indietro. Questo è probabilmente il problema più difficile. Il post di Ben afferma che quando pushState viene adottato più ampiamente, possiamo lasciare gli hashbang e tornare agli URL tradizionali. Bene, il fatto è che non puoi. In precedenza ho affermato che gli URL sono per sempre, vengono indicizzati e archiviati e generalmente mantenuti in circolazione. Per aggiungere a ciò, gli URL interessanti non cambiano. Non vogliamo disconnetterci da tutti i preziosi link ai nostri contenuti. Se hai implementato URL hashbang in qualsiasi momento, allora vuoi modificarli senza interrompere i collegamenti, l'unico modo per farlo è eseguendo un po 'di JavaScript sul documento principale del tuo dominio. Per sempre. Non è in alcun modo temporaneo, ne sei bloccato.

Vuoi davvero usare pushState invece di hashbang , perché rendere i tuoi URL brutti e possibilmente rotti - per sempre - è un aspetto negativo colossale e permanente degli hashbang.

Per avere un buon seguito su tutto ciò, Twitter - uno dei pionieri degli URL hashbang e dell'interfaccia a pagina singola - ha ammesso che il sistema hashbang era lento nel lungo periodo e che hanno effettivamente iniziato a invertire la decisione e tornare a legami della vecchia scuola.

L'articolo su questo è qui.

Ho sempre supposto che il !appena indicato che il frammento di hash che seguiva corrispondesse a un URL, con! sostituendo la radice o il dominio del sito. Potrebbe essere qualsiasi cosa, in teoria, ma sembra che all'API di scansione di Google AJAX piaccia in questo modo.

L'hash, ovviamente, indica solo che non si sta verificando una vera ricarica della pagina, quindi sì, è per scopi AJAX. Modifica: Raganwald fa un ottimo lavoro spiegando questo in modo più dettagliato.

Le risposte sopra descrivono bene perché e come viene utilizzato su Twitter e Facebook, ciò che mi è mancato è la spiegazione che cosa #fa di default ...

Su un 'normale' (non una singola applicazione di pagina) puoi fare l'ancoraggio hasha qualsiasi elemento che ha id posizionando quell'elemento id in url dopo l'hash#

Esempio:

(su Chrome) Fare clic su F12o Rihgt MouseeInspect element

quindi prendi id="answer-10831233"e aggiungi all'URL come segue

/programming/3009380/whats-the-shebang-hashbang-in-facebook-and-new-twitter-urls-for#answer-10831233

e otterrai un link che salta a quell'elemento nella pagina

A cosa servono gli shebang / hashbang (#!) In Facebook e i nuovi URL di Twitter?

Usando #in un modo descritto nelle risposte sopra stai introducendo comportamenti contrastanti ... anche se non perderei il sonno su di esso ... poiché Angular è diventato in qualche modo uno standard ...