Nachtrag: Da lobt man Partyguide ausserordentlicher Weise für einmal, und eine Stunde später so was … *tz*
Nachdem es eMeidi.com vorgemacht hatte, beschreitet nun auch meine Lieblings-Party-Site Partyguide den „asynchronen JavaScript/XML-Weg“. Entdeckt habe ich die Neuerung letzte Woche:
Die Frischzellenkur tut gut – dies hängt sehr wahrscheinlich mit einem neu zum Team hinzugestossen Entwickler zusammen (unbestätigter Rumor).
Vorteile von AJAX
Anstelle also bei einer Suche gleich den ganzen Inhalts des Frames neu zu laden, beschränkt man sich neuerdings darauf, nur noch den dynamisch-variablen Teil, die Tabelle mit den Suchresultaten, gemäss den Such-Parametern auszuwechseln.
Endlich bleiben die Suchparameter also im Formular stehen! Ich hatte mich bisher immer grün und blau geärgert, dass ich die Suchparameter bei jeder Suche wieder von vorne eingeben musste. Manchmal möchte man die bestehenden Angaben ja beibehalten, und nur eine Option (z.B. „Nur User mit Foto anzeigen“ aktivieren resp. deaktiveren).
Leider, leider hat man meinen Ratschlag vom Dezember 2005 immer noch nicht beherzigt: Damals schlug ich vor „Sich wiederholenden HTML-Code [zu] vereinfachen“. Nichts ist seit her geschehen.
Die von user.php zurückgegebene JavaScript-Variable enthält immer noch die fürchterliche, zig-fach redundante HTML-Tabelle. Mit einem wenig Bytes grossen CSS-File zur Formatierung der Tabelle könnte die grösse der AJAX-Antwort drastisch reduziert werden …
Schade übrigens, dass HTML-Code zurückgeliefert wird. XML hätte mir besser gefallen, denn dann hätte ich mir eine auf meinem Server laufende Suchfunktion gebastelt – mit schickem HTML/CSS. Bis zur Partyguide-API ist es wohl aber noch ein weiter Weg.
Framework
Das im Einsatz stehende JavaScript-Framework stammt von Modern Method und nennt sich Simple AJAX Toolkit. Auf eMeidi.com habe ich dagegen Prototype im Einsatz. Was besser ist? Keine Ahnung. Hauptsache, es funktioniert.
Nachteil von AJAX
Der Nachteil des momentanen AJAX-Booms: Die Libraries sind sehr umfangreich, Prototype bspw. knapp 50KB. Dies macht sich deutlich bemerkbar, wenn die Site mit einer langsamen Verbindung abgerufen wird. Aber auch schnellere Leitungen bringen nicht viel, da die Browser den Code auch noch interpretieren müssen. Kaum verwunderlich, dass Sites wie Digg (49 Page-Requisites, darunter 7 JavaScript-Dateien, die je über 10KB wiegen) oder Flickr (40 Page-Requisites, darunter zwei JavaScript-Files mit 32.6KB und 28.8KB, aber auch ein 60KB (!) grosses CSS-File) beim ersten Aufruf eine deutliche Ladeverzögerung aufweisen.
Partyguide-Implementation
Wieso der Entwickler von Partyguide den JavaScript-Code direkt in das HTML/PHP-File eingefügt hat, verstehe ich nicht.
Auch beim Konkurrenten tilllate findet man immer wieder CSS-Styles, die nicht über ein globales CSS-File includiert werden, sondern direkt im HTML-Quelltext stehen.
Würden diese Angaben konsequent in eigenständige Dateien ausgelagert, könnten diese lokal oder auf dem zwischengeschalteten Proxy gecached werden und müssten nicht jedes mal neu Übertragen werden (Stichwort: HTTP 304). Aber anscheinend ist das Transfervolumen nebensächlich.
Weitere Verbesserungen bei PG
Übrigens: Auch die in Partyguide – ach Wunder – lahmt kritisierte Ladeverzögerung an Sonntagen gehört der Vergangenheit an. Nur wenige Tage nach meiner Kritik hat man einen neuen, professionellen Load-Balancer (Hersteller unbekannt) installiert, der die fehleranfällige und langsame Apache/mod_proxy-Lösung ablöste. Nun lädt die Page auch flott bei über 4000 gleichzeitigen Besuchern.
Weiterführende Links
(Fast) alle auf think eMeidi erschienene Artikel über Partyguide.
