AJAX mal so, mal so

Klar, AJAX durchzieht heutzutage Webanwendungen und Websites. Die Fülle der möglichen Patterns, Libraries und Frameworks ist dabei verdammt groß.

Man sollte also wissen, wann man was einsetzt, wenn man das typische Hammer-Nagel Problem vermeiden will.

Good Pattern: Server Side Templating

Der einfachste aller AJAX Ansätze besteht weiterhin darin, das HTML Server-seitig zu generieren und im Client lediglich in ein DOM-Element einzusetzen.

Der größte Vorteil liegt in der Einfachheit. Ein Nachteil ist, dass die HTML Präsentation eventuell etwas mehr Netzwerkverkehr benötigt.

Wenn die GUI eine große Interaktivität aufweist, stößt dieses Pattern jedoch schnell an seine Grenzen.

Good Pattern: Client Side Templating

Wenn die zu übertragende Datenmenge sehr groß ist, kann ein Client-seitiges Templating die Performance verbessern. Wichtig ist: Client-seitig wird weiterhin ein Text erzeugt und dann auf einmal in ein DOM-Element eingesetzt!

Client-seitiges Templating ist tendenziell aufwendiger, wobei das eigentliche Templating im JavaScript mit Engines wie handlebars sehr einfach ist. Zusätzlich zum Template müssen jedoch Server-seitig JSON-Daten generiert werden.

Wenn die GUI eine große Interaktivität aufweist, stößt dieses Pattern jedoch ebenso wie Server Side Templating an seine Grenzen!

Good Pattern: Client Side Binding

Falls eine GUI sehr komplex ist, benötigt man eine ausgewachsene JavaScript Library mit Binding Unterstützung, um das Rendering der Daten von anderen Aktionen zu entkoppeln.

Ein solches Pattern sollte man für sehr einfache Anwendungen und vor allem Websites tunlich vermeiden und auch erwägen, ob Server-Roundtrips wirklich so schlimm sind.

Wenn man sich aber gegen Server-Roundtrips entscheidet, dann gibt es keine Alternative zu Binding, oder man landet bei verwurstetem JavaScript, was man am liebsten wieder löschen würde.

Bad Pattern: Client Side DOM-Manipulation

Falls man auf die Idee kommt, Client-seitig mittels DOM-Manipulationen eine komplexe UI zusammenzubauen, z.B. so… (Pseudocode)

$box = $('<div>...</div>')
if(someCond) $box.find('.someClass).append('<div>stuff</div>')

… dann hilft wirklich nur Schreien und Wegrennen. Nicht nur dass das Rendering à la Windows Forms anno 2003 passiert, das JavaScript für die Interaktivität ist dann meist auch irgendwie zusammengekrautet, am Besten noch mit mehrstufigen anonymen Handlern:

$box.find('.btnDelete).click(function(){
  // 100 lines of js
  $box.find('.someStuff').click(function(){

  }
});

Argh…

Ganz nebenbei scheinen so massive DOM-Manipulationen mit jQuery eher nicht so performant zu sein, wie das Einsetzen eines großen HTML Blocks.

Fazit

Es gibt gar nicht so viele grundsätzliche Ansätze, wie man AJAX-Anwendungen bauen kann. Leider ist es in der Praxis gar nicht so einfach, diese Ansätze klar zu erkennen. Beispielsweise kann eine Anwendung erst einmal eine Client-seitige Templating Engine benutzen (positiv!), dann aber durch viel Interaktivität diese ad Absurdum führen. Und natürlich kann man auch mit Kanonen auf Spatzen schießen und ein Binding-basiertes Framework wie Knockout.js einsetzen, wo die Aufgabe mit Server-seitigem Rendering ein 5-Minuten Job gewesen wäre.