Názory k článku
Přepište historii webových stránek

Vzdyt to jde i bez toho, vsechny ty vyhody tu popsane nejsou ani v nejmensim zavisle na # ale daji se pouzit i s normalni a platnou url (dynamicky reload jen casti stranky, pohyb v historii) - viz treba pohyb po adresarich a souborech na githubu:
https://github.com/django/django/tree/master/django/conf

Github používá HTML5, které tuto možnost zavádí. Čili je to novinka, která ve starších prohlížečích nebude fungovat. Workaround s hashem byl vymyšlen dávno před tím, než tohle vzniklo.

Nechapu. Pohyb po filesystemu projektu na githubu je resen standardnimi odkazy

Zkus to ve chromu.

To co předvedl Lifehacker je odstrašující příklad, jak by se to dělat nemělo. Pro dobrou implementaci je potřeba mít solidní model pro práci se stavy v JS. Ten by měl zajistit konzistentní chování (zobrazení stránky včetně obsahu) v případech, kdy: kliknu na tlačítko zpět, dopředu, vrátím se o X kroků v historii, přejdu na úplně jiný web a pak se zase vrátím, uložím si stav do záložek a vrátím se na něj jindy, stisknu kdykoliv F5, pošlu někomu odkaz s hashem, atd.

Tady je k tomu ještě pěkné čtení: http://www.isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs

Celkově mám pocit, že je to nehezké řešení neexistujícího problému. Oproti normálním adresám je to mnohem složitější, náchylnější k chybám a méně pohodlné.

Mea culpa, mea maxima culpa. Slibuju, že příště budu číst pořádně a nepostovat duplicity.

Je to pravda a ikdyž to není úplně snadné, je to možné. Právě na takové stránce pracuju a vážně všechny tyto vlastnosti splňuje.

Tento plugin do jQuery se mi celkem osvědčil, kdyby to někomu pomohlo: http://tkyk.github.com/jquery-history-plugin/

Řešení by bylo při generování první stránky použít
http://example.com/neco/!dalsi-parametry

a až načtení všech skriptů skriptem změnit na
http://example.com/neco/#!dalsi-parametry

tímto by se prohlížeče bez js a roboti dostali na svůj obsah.

V případě některých chyb by se skript nespustil takže by odkazy byly pořád funkční.

No tam je problem s tim, ze zmenit adresu z http://example.com/neco/!dalsi-parametry na http://example.com/neco/#!dalsi-parametry znamena reload stranky a tedy nove nacitani skriptu.

Ale jinak treba s tou nefunkcnosti to ja osobne resim tak, ze vsechny stranky standardne odkazuji na http://example.com/?!parametry a teprve pri nacteni tam dam javascriptem onclick presmerovani na http://example.com/#!parametry, takze v pripade, ze v js dojde k chybe, tak web funguje normalne dal jen neajaxove (stranky s ?! jsou shodne se strankami s ?_escaped_frag­ment_).

1) Nevím, jaký mají dojem ostatní, ale můj „uživatelský prožitek“ (hrozný výraz) např. z nového Twitteru je citelně horší než z toho starého –
na to, že stránka obsahuje pár odstavečků textu a vpravo nějaké ikonky, se načítá nesmyslně dlouho.

2) V době, kdy po síti létají gigabajty porna, warezu a nesmyslných uživatelských videí atd., mi přijde trochu zbytečné řešit, jestli se nějaký kousek (X)HTML nebo CSS přenese jednou nebo X krát – stále je to totiž zlomek toho datově náročného obsahu (ať už legálního nebo nelegálního).

3) Ano, technika donačítání stránek AJAXem může pomoci, aby z toho měl uživatel lepší pocit, taky už jsem zažil stránky, které se takhle načítají a fungují velmi rychle – ale stejně tak znám jiné weby, kde se načítá vždy celá stránka, přesto je web velmi svižný – stránky jednoduše nejsou zanesené „moderním“ balastem (pozor, tím nemyslím nějaké holé HTML, kde autor zcela ignoroval formu a věnoval se jen obsahu – minimalistický/jed­noduchý/úspor­ný web není totéž co hnusný web).

4) Cílem může být ušetření práce serverům (aby nemusely sestavovat vždy celou stránku) na úkor klientů. To mnohdy dává smysl – domácí uživatel s nabušeným pécéčkem s tím nebude mít problém a serveru to citelně pomůže (server je sice taky nabušený, ale připadá na něj mnoho uživatelů – zatímco ten Pepa sedí doma u svého čtyřjádra sám). Jenže ve chvíli, kdy se chceme vydat cestou energeticky úsporných tenkých klientů nebo mobilních zařízení s dlouhou výdrží, je tahle myšlenka najednou kontrarevoluční – ulehčíme serverům na úkor klientů, jenže ta zařízení dostatečný výkon nemají resp. vede to k tomu, že i na obyčejné prohlížení webu bude zase potřeba relativně silný počítač. Nicméně tohle převalování se ze strany na stranu je asi údělem IT…

Do kamene tesat.

Navic je #! strasny opruz s NoScriptem. Treba twitter ma i non-hashbang verzi, ale je to opruz to prepisovat. Lze vytvorit greasemonkey script, co to bude prepisovat, ale je to taky opruz. Nechapu proc to zrovna twitter potrebuje. Stejne RS. Puvodni web byl stokrat lepsi a prehlednejsi.

A nešlo by to přepisovat pomocí HTTPS Everywhere? Jeho pravidla sice slouží k přepisování na HTTPS verzi, ale možná by to šlo použít i na tohle.

Jasne, slo by to s HTTPS Everywhere, ale to neni na to uplne urceno. Navic je tam porad bug, kdy se "jaksi zapomene" z cookie udelat secure cookie v nekterych pripadech.

Naklonoval jsem si i git z HTTPS Everywhere, ale mel jsem na to jenom nejakou hodku zatim, takze jsem to nenasel, proc to nastava (nemam prilis zkusenosti s debugovanim FF extensions).

S tim hashbangem by se to vic hodilo do NoScriptu, uvazoval jsem dat to jako feature-request with donation. Jednoduse by se to udelalo jako option, ze pokud site neni ve whitelistu, prepise se to jednoduse odstranenim hashbangu.

Odstraneni hashbangu funguje na mnoho sajtu, ale treba zrovna na RS ne. Proste je to celkem pruda opravovat to, protoze si kazdy sajt udela ad-hoc reseni. Je to jako hadat co si mysli nahodne orakulum v NP relativizovanem nahodnym orakulem (viz Baker-Gill-Solovay).

Asi jsem zpátečník anebo konzerva, ale nějak mi uniká, proč by crawlery měly indexovat obsah aplikací. Na webu jsou stránky buď dokumentové, kde návštěvník může najít informace (a proto je vyhledávače indexují), anebo "web 2.0 aplikace". U těch prvních nevidím ani nejmenší důvod, proč by měl být celý web v jedné stránce a obsah načítat AJAXem. Umíte si třeba představit wikipedii celou v AJAXu? Jaký by to mělo přínos? U webových aplikací, kde to dává smysl (typicky třeba mapové servery anebo třeba translate.goo­gle.com), tam ať se fragmenty používají, od toho jsou, ale tam zas nechápu, proč by to měly indexovat vyhledávače, když obsah je více-méně pokaždé jiný, často privátní a pro cizího kolemjdoucího čtenáře tam asi zřídka kdy budou užitečné informace.

Nebo mi někdo může vysvětli smysl, proč je ten lifehacker.com udělaný tak jak je udělaný? Díky.

Souhlas.

Já kupříkladu řeším tento problém: Mám mapovou aplikaci, která má jako doplňkovou část blog s články o mapě, některých jednotlivých místech v ní, nápovědou k aplikaci atd. Požadavek je, aby při otevření blogu nedošlo ke ztrátě kontextu mapy (poloha, zapnuté vrstvy, otevřený popup). Proto se blog otevírá v části stránky pomocí jQuery Overlay.

V původním návrhu měl odkaz na blog z mapy metodu onClick, které ho otevřela. Nyní je to dělané přes hash (http://example.com/#clanek=id), kdy javascript zaznamená změnu hashe, rozparsuje ho a otevře overlay. Jenže takto udělaný blog není indexovaný crawlerem, což je škoda.

Škoda, že podpora indexování AJAXového obsahu přichází prakticky až v momentě, kdy existuje mnohem lepší řešení, které se začíná i zvolna prosazovat (Chrome, Firefox 4). To řešení spočívá v metodě history.pushSta­te, pomocí které lze změnit kompletní URL, aniž by to vedlo ke znovunačtení stránky ze serveru. To je na rozdíl od manipulace s hashem stránky zcela čisté řešení už jen proto, že hash slouží pro odkázání na část stránky.

Výhody jsou očividné - stejné URL pro všechny, žádné problémy s indexováním, žádná nutnost zpracování magického parametru _escaped_frag­ment_, pěknější a smysluplnější URL.

Vyzkoušel jsem toto řešení v Admineru (bude součástí verze 3.2.0) a jsem z něj nadšen - pro uživatele všechno funguje zcela transparentně, jen je to v podporovaných prohlížečích ještě rychlejší. Pokud mi čas dovolí, tak bych se své zkušenosti pokusil sepsat do článku.

To je dobrá zpráva, ale ještě dlouho bude potřeba myslet na starší prohlížeče. Firefox 4 ještě ani nevyšel.