Archief - Ajax website

Ik ben al een tijdje bezig met het onderzoeken van een manier om een kleine website te maken via
bijvoorbeeld het facebook principe.
Dus dat de meeste inhoud via ajax wordt geladen en hierbij ook de url's worden aangepast zodat ze te bookmarken zijn, etc..

Nu was ik terechtgekomen bij vikingspots.com waar ook deze techniek gebruikt wordt, maar nu vraag ik mij enkele zaken af, mss dat iemand hier ze weet.


Bij de search wordt hetvolgende gedaan:

<!-- search -->
<form class="search" action="/nl/ajax/" method="get">
<div class="input text">
<input name="q" id="search" type="text" value="" data-autocomplete-url="/nl/ajax/autocomplete/" placeholder="Search…"/>
</div>
<div class="input submit">
<input type="submit" value="Zoeken"/>
</div>
</form>
<!-- /search -->

Maar omdat in de url #!/nl/ajax natuurlijk niet mooi staat wordt dit #!/search/keyword

Waar gebeurt dit precies? Ik begrijp niet op welke plaats deze url wordt aangepast?

Dan vroeg ik mij ook nog af waarom dit wordt gedaan?

<span class="hidden urls"
data-static-url="/s/v-d35f2a80/"
data-search-url="/nl/ajax/"
...

Dus de urls die in de effectieve ajax calls worden gebruikt worden uit een hidden span gehaald. Waarom wordt dit gedaan?


Alvast bedankt

Ik vermoed dat ze een soort van fallback hebben. Dus wanneer javascript niet wordt ondersteund door de browser, dan worden er gewoon submits gedaan naar /nl/ajax. Wanneer JS wel wordt ondersteund gaan ze hoogstwaarschijnlijk het click event van de knop opvangen, en de form data verwerken.

De url aanpassen achter de # kan gewoon met javascript. Dus ze vangen het klik event op, veranderen de url naar #/search/keyword en tonen de content.

Die span zal waarschijnlijk door één of andere functie in hun Javascript gebruikt worden, je zou alles moeten gaan uitvlooien om erachter te komen wat dat is (en daar heb ik geen zit in). Het feit dat het allemaal data attributes zijn bevestigt dat. T is zo'n beetje de gewoonte tegenwoordig om HTML5 data attributes te gebruiken/verkrachten om serverside data rechtstreeks in je view te verwerken en dan door Javascript code te laten ophalen.

Nu, effe terug naar je URL vraag. Je moet goed begrijpen wat die hash in de URL wil zeggen. Dat is iets dat al van in de jaren stilletjes bij browsers bestaat en nu eigenlijk misbruikt wordt om clientside rendering te sturen.

Voorbeeld:


De pagina die effectief aan de server wordt opgevraagd is in dit geval:


De Javascript op die pagina gaat uit de URL het anker halen (dat vroeger werd gebruikt om naar een bepaalde sectie in de pagina te springen, het enige echte gebruik van anchors dus) en zal aan de hand daarvan iets doen. In het geval van je voorbeeld zal die bv de search functie aanroepen, die op zijn beurt een AJAX request naar de server zal sturen met als parameter "keyword".

De ganse redenering hierachter is dat die ankers mee gebookmarkt worden en je op die manier dus clientside interacties kunt gaan reproduceren via een bookmark. Het heeft echter ook nadelen.

In het geval dat het anker geen AJAX requests triggert ligt het probleem erin dat je een groot deel van de rendering naar een onbekende factor verplaatst: de computer van de eindgebruiker. Zeker met iets complexere sites kan dat behoorlijk wat workload daarop zetten. En veel optimalisatie kan je al niet gaan doen.
Als je nog eens met AJAX requests daarbovenop zit, dan vergroot je het probleem alleen maar. Je stuurt eerst een request voor de main page (met al z'n headers en connection establishment etc) en direct daarop stuur je nog eens een AJAX request om data met alweer die headers en andere overhead. Je zit met meer data en meer server hits.

De twee bovenstaande redenen (er is ergens een uitgebreid artikel over) waren mede verantwoordelijk voor het feit dat Twitter van die techniek afgestapt is en nu weer het meeste serverside doet, buiten de feed update (maar daar doen ze ook iets speciaals, maar dat doet niet terzake).

Als je echt naar een goeie manier wil gaan moet je het eigenlijk zoals op github doen: via browser pushState. Dat laat toe van via javascript je url te veranderen zonder de pagina effectief te verversen. Je krijgt echte URLs die bookmarkable zijn, je kan (en moet) er serverside voor zorgen dat de ganse pagina in één keer gerenderd wordt en de browser niet meer moet doen dan hem interpreteren. Het nadeel van pushState is dat je wel rekening moet houden met het feit dat sommige oudere browsers dat niet ondersteunen. Je kan in dat geval kiezen voor die hash-based fallback of voor gewone HTML requests.

Anchorbased URL tagging is aan het uitsterven, en laat het dat ook maar doen. Het heeft z'n nut gehad, nu zijn er betere, juistere, performantere en meer betrouwbare methodes.

Artikels in kwestie:

Twitter Engineering: Improving performance on twitter.com
isolani - Javascript: Breaking the Web with hash-bangs

Push/popstate Github:
https://github.com/blog/760-the-tree-slider

Interessante artikels bealzebub

Interessant allemaal in ieder geval, bedankt voor jullie info, ga zeker de artikels eens grondig doornemen.