JM 06.06 - AJAX

[F. Meyer]

Hallo,

natürlich hat AJAX bei bestimmten Szenarien Sinn.

Es ist aber schade, daß der Artikel nicht darauf eingeht, dass AJAX im Internet Explorer nur mit ActiveX funktioniert. Bei den Konzernkunden für unsere Anwendung sind die Browser-Einstellungen oft so restriktiv, daß schon für JavaScript argumentiert werden muß.

Aus der Praxis gesehen, bereitet die Vielfalt von Browsern (und deren Versionen) auch oft Probleme.

Ganz zu schweigen davon, daß eine oft genutzte Anwendung doch viel sinnvoller ist, wenn sie auch tatsächlich auf dem lokalen Rechner installiert ist.

Durch einen intelligenten Updater und Einsatz eines simplen Caches für den Daten-Transfer werden einige Argumente für AJAX-basierte Web-Anwendungen entkräftet.

Darüber hinaus erleben wir oft, daß die Server einiges aushalten müssen, wenn die Rechenleistung und der Speicherbedarf von zig (Hundert) Client-Rechnern an den Server delegiert wird.

Persönlich sehe ich bei vielen Anwendungsbeispielen nicht ein, warum mein leistungsfähiger Rechner nur noch als intelligentes Terminal mißbraucht werden soll und eine ständige Internetverbindung gefordert wird.

Gruß
Frank

[Björn Mülller]

Hallo Frank,

kleine Statements:

(1) AJAX im IE nur mit ActiveX: das stimmt "halb" - die gängigen AJAX Frameworks gehen auf das entsprechende ActiveX Kommunikationsobjekt. Es gibt aber auch die Möglichkeit, über hidden frames zu kommunzieren - das läuft dann ganz ohne ActiveX, auch im IE! Manche Frameworks tun das auch...

(2) Die Frage, was am Frontend laufen soll, und was hinten laufen soll, ist eine "ganz heikle". Der Trend geht definitiv nach "viel Verarbeitung hinten" - "gutes Rendering vorne". Paradebeispiel: GoogleMaps. Früher installierte man einige CDs im Client, um zumindest über deutschen Satelleitenbildern zu browsern - heute ruft man einen Link auf, die ganze Beschaffung der Bilder etc. wird komplett "hinten" gelöst. Wenn man nun in Richtung Update denkt (Aktualisierung der Bilder...), dann gehen die Vorteile immer mehr in Richtung "hinten".

(3) Prinzipiell geht AJAX (oder Rich Clients i.A.) in die Richtung Deiner Argumentation, die Power "vorne" auch zu nutzen. In klassischen Web Szenarien wird vorne nur plain HTML betrieben... Es kommt auf die Richtung an, aus der man draufguckt: aus HTML-Richtung wird die Frontend-power wesentlich mehr genutzt, aus Fat-Client-Richtung (ich glaube, da guckst Du mir von, oder?) wird sie weniger genutzt, da die Anwendungsverarbeitung "hinten" geschieht.

(4) Komplett richtig ist: AJAX mit nativer HTML/JavaScript Implementierung, ist grausam aus Blick einer Anwendungsentwicklung. Und ein klarer Rückschritt gegenüber OO-UI-Bibliotheken in Jaca/C#/... Eine Herangehensweise ohne abstrahierende Frameworks und Tools ist nicht zu empfehlen.

Summasummarum, aus meiner Sicht: AJAX ist nicht DIE Lösung für alle Probleme. Deine Argumente sind ja nicht von der Hand zu weisen. Ein CAD-Grafik-Programm wird auch noch in ein paar Jahren vorne installiert werden. Aber: AJAX bietet sich für eine Anzahl von Anwnedungen an - insbesondere im Bereich von Unternehemenssoftware. Diese Anzahl ist aus meiner Sicht sehr hoch! ;-)

Björn

Björn Müller, [email protected]

[F. Meyer]

Hallo Björn,

sicher gibt es viele sinnvolle und tolle Anwendungsbereiche für AJAX (- genauso wie für DHTML, wo CrossBrowser-Kompatibilität ja auch mit Unmengen von if-else-Orgien erreicht wird).

So gerne ich GoogleMaps und die darauf aufsetzenden Dritt-Anwendungen auch nutze, ist das ein gutes Beispiel für einen Grenzbereich. Mit GoogleEarth wurde ja extra eine Client-Implementierung geschaffen, um "Profi"-Nutzern mehr zu bieten.

Wie es bei Unternehmen, die diverse Anwendungen integrieren müssen, in der Praxis aussieht, kann ich nicht beurteilen. Aber ich werde immer etwas sensibel, wenn von Trends gesprochen wird und diverse Schlagworte als per-se-Argumente in eine technische Diskussion eingeworfen werden (ich erinnere mich, XML nur mühsam für eine reine RMI-Anwendung als Lösung wegargumentieren zu können, weil "das halt die Zukunft sei").

Bei "Hidden Frames" mußte ich lachen, wenn auch unter Schmerzen. Vor x Jahren habe ich mal einen Prototypen entwickelt, der genau so vorgegangen ist - einfach grausam.

Worauf ich aber im Ursprungsposting heraus wollte, ist die Problematik, eine sinnvolle technische Entscheidung gegenüber Kunden rechtfertigen zu können, auch wenn sie nicht (mehr) en-vogue ist.

Meine persönliche Projekt-Erfahrung läßt mich halt Richtung Client/Server-Anwendung tendieren ohne Browser, weil ich dann (genau wie du gesagt hast) diverse UI-Komponenten einsetzen kann.
Dort brauche ich mir keine Gedanken zu machen, wie denn jetzt wieder ein Kontext-Menü in Browser XY zu implementieren ist, der in der kommenden Version wieder was ganz anderes macht als gewollt, oder wie Cache-Header zu setzen und Proxies zu konfigurieren sind, damit z.B. dynamisch generierte Bilder auch individuell ausgeliefert werden. Sprich: Ich muß nicht das Rad neu erfinden.

Vielleicht vermisse ich es auch nur, offline arbeiten zu können und ein Programm zu deinstallieren, indem ich das Verzeichnis lösche (mit dem Alter kommt die Nostalgie *g*).

Als abschließende Bemerkung: Beim Thema AJAX und Browser generell geht es schließlich auch um persönliche Präferenzen und das kann immer wieder endlos diskutiert werden. Als Konsens würde ich vorschlagen, die (schon ältere) Technik AJAX einfach als Inhalt des Werkzeugkastens zu betrachten, aus dem ich mich bedienen kann.

Gruß
Fran

[Jan Gäbler]

hallo zusammen,

also mich hat ajax noch nicht wirklich überzeugt. sicher, das eine änderung ohne neuladen möglich ist, ist schön. allerdings kann ich auch heute schon genug infos in meinen jsp reinpacken, damit dann, die darauf aufsetzenden javascript funktionen es anzeigen können.
ich finde die möglichkeiten, die mir taglibs bieten phantastisch und sehe gerade mit dem kommenden/angekommenden jsf keinen echten vorteil von ajax.
denn wenn ich innerhalb meines menüs in ein andere funktion springe, dann muß ich die daten eh nachladen. nur die änderung des menüs bzw. dessen aufbaus kann ich über ajax realisieren. dies ist aber jedoch schon heut möglich, wenn ich, wie schon gesagt nur genug in meine jsp einbaue an daten (sei es auch über zusätzliche frameworks die mir das erleichtern).

oder habe ich hier einen riesen denkfehler??

der ja

[AK]

Hallo F.Meyer,

wenn ich im Internet Explorer Active X ausschalte, dann heisst dass noch lange nicht, dass meine Ajax-Anwendung nicht mehr funktioniert. Ich verwende derzeit AjaxAnywhere als "Ajax-Framework", welches bei Browsern die kein Ajax unterstützen einfach einen kompletten refresh der Seite durchführt. Die Anwendung läuft genauso wie mit funktionierendem Ajax nur eben nicht mehr so "schön". Von daher kann ich Deine Argumentation nur Bedingt nachvollziehen.

Gruß Anto

[F. Meyer]

Hallo Anton,

ja natürlich kann man das berücksichtigen - genau wie bei vorgeschalteten Flash-Detektorseiten - und wenn das per Framework automatisch geht, noch besser.

Nochmal:
a) Ich gehe von den Browsern und ihren Konfigurationen aus, die mir im Einsatz bei Unternehmen begegnen. Und diese nehmen unsere Server nicht in "Vertrauenswürdige Sites" auf und/oder verweigern ActiveX - aus welchen Gründen auch immer (Faulheit, "übertriebenes" Sicherheitsdenken usw.).
Von daher rechnen sich die Kosten einer aufgemotzen AJAX-Version nicht für die paar Prozent der Anwender, die mit Firefox / IE+ActiveX auf die Web-Anwendungen zugreifen, nur damit es etwas schicker ohne Geflicker geht.
b) Oft genutzte Anwendungen präferiere ich aus diversen Gründen als lokale Applikation (siehe vorherige Postings).
c) Grundsätzlich stelle ich Verwendung und Nutzen von AJAX nicht in Frage.

Gruß
Frank (dafür steht das "F."

[AK]

Hallo Frank,

du hast in Bezug auf die zusätzlichen Kosten einer Ajaxanwendung natürlich recht. Ich wollte aber eben anmerken, dass Ajaxanwendungen auch auf nicht ajaxfähigen Browsern laufen können, wenn man das richtige Framework nimmt.

Gruß Anto