meine notes zur session asp.net ajax toolkit. sehr guter vortrag über die möglichkeiten ajax elemente einzusetzen in asp.net seiten, und wie diese den traffic zwischen server und client verringern.
stephenwalther.com – blog vom speaker
codeplex.com project – asp.net ajax control toolkit
vorgestellt werden 3 verschiedene asp.net web app types anhand einer demo:
- server side asp.net
- asp.net ajax server side
- client side asp.net ajax
performance tools für testing: mit fiddler2.com (best tool für ajax testing – traffic analyse), firebug für firefox (extension).
erstens: server side asp.net
- vorteile: keine browser kompatibilitäts issues
- jede programmiersprache unterstützt (egal ob c#, vb.net, c++,…)
- simpel gesagt ein sehr einfacher weg stabile web apps zu schreiben (old school)
drawbacks:
- response time bei web apps mühsam für den user (apps tauschen eine menge von daten aus)
- performance: page inhalt wird für jede site gerendert
oft 2 developer: ein asp.net developer und ein java script developer > frag beide developer wenn ein click event happens.. server and client side vermischung.
[demo]
fiddler zeigt den traffic der bei postbacks entsteht – gut um zu zeigen was auch bei simplen änderungen an traffic ensteht – beispielsweise wenn in einer kleinen tabelle nur nach einer neuen spalte sortiert wird.
in der demo app erzeugt der reload nach einem einfachen category change im datagrid um die 3500 byte an traffic.
zweitens: server side asp.net ajax
vorteile:
- es ist ein schritt nach vorn, es passieren keine postbacks mehr – sozusagen nur noch “sneaky” postbacks. kein kompletter postback mehr, nur noch der erforderliche teil. es ist nach wie vor ein “save approach” – weil auf dem client nur ein minimaler teil der seite reloaded wird.
- wieder jede sprache verwendbar
- retrofit: existierende asp.net applikationen können leicht angepasst werden bzw. sind kompatibel
nachteile:
- user muss nach wie vor auf reload des teilbereichs warten
- ist nur ein erster schritt die seite responsiver zu gestalten
bei reinem serverside wurden 3500 byte hin und hergeschickt, beim teilweisen ajax einsatz nur noch 2500 byte. (ein table auf der page). nach einer kleinen optimierung des updatebereichs schrumpft der traffic um weitere (kontrolle immer mit fiddler) 500 byte auf knapp 2000. wo geht der traffic hin? ist ja nur eine kurze table… 
zurückgesendet wird vom client der viewstate – lots of data. viewstate kann für solche dinge abgedreht werden in den control properties (enable viewstate=false). nach der de-aktivierung werden nur noch 1500 bytes ausgetauscht. im vergleich zum start mit reinem server side asp.net wurden noch mehr als doppelt soviel byte getauscht.
drittens: client side asp.net ajax (microsoft ajax library)
vorteile:
- event werden nur ausgelöst wenn sie passieren
- performance: nur noch nötiger traffic entsteht
nachteile
- browser kompatibilität: nicht risk-free
- language: nicht alles möglich – viel java script frickelei
- mixing again content and behaviour (formatierung und code)
die page wird einmal gerendert, danach sind eine menge ajax calls (kein reload, außer bei kompletten page wechsel)
[demo wird aktualisiert]
stop using windows onload (eine person im auditorium gibt zu das noch zu verwenden, die andern trauen sich nicht aufzeigen) – use page load instead. die windows onload executed erst wenn alle images geladen sind und verzögert damit enorm.
why use java script on client side? look at the performance difference with fiddler: jetzt herunten auf 650 byte, mit verwendung des ajax toolkits.
[demo wird aktualisiert - master/detail page (ein klassiker) mithilfe von client side ajax.
neue features in asp.net ajax 4.0:
- client side controls: ein sauberer weg um java script code in asp.net seiten zu verwenden
- in html kann mithilfe von {{ }} java script functions aufgerufen werden, anstatt die funktionen im template abzubilden
- das toolkit wurde mit allen browsern ab jahr 2000 getestet.
rude objections on ajax apps:
- browser back/forward button - users are still used to it... :/ ... microsoft solution: back button support in ajax tools from microsoft >> back button is covered in ajax apps
- accessibility: one approach: new standard will support ajax. second approach:
- SEO: how are ajax pages indexed?
- what if java script is disabled, or people use mobile phone without java script support
zu den letzten drei punkten von oben: wenn du ajax apps verwendest immer failover support programmieren.
mit dem ajax toolkit von microsoft lässt sich der failover support leicht einbauen - über zusätzliche abfrage über den javascript status des browsers wird gegebenenfalls ein postback ausgelöst - die funktion für das failover muss nicht extra geschrieben werden (mutmaßung meinerseits).
[demo wird aktualisiert]
asp.net ajax and asp.net mvc – da bin ich leider ausgestiegen
conclusion – embrace the client side >> for better performance and better user experience write client-side asp.net ajax apps.
wer sich für das thema interessiert, kann sich auch ein session recording von der PDC ansehen: “ASP.NET Ajax Futures“
