Ajax / Javascript Fallback

Thomas 'PointedEars' Lahn wrote:

Wolfgang Fellger wrote:
Natürlich ist bei einem einzigen Vorkommen der zusätzliche Code zum
Registrieren des Ereignis-Handlers länger, keine Frage. Dafür wird aber so
ein Client ohne Javascript mit Null Javascript belästigt.

Falsch. Wie schon angedeutet, muss der Client, wenn Script unterstützt
wird, in jedem Fall immer das gesamte verändernde Script herunterladen.
Und das ist schon allein deshalb mehr als bei einem Ansatz, der einfach
HTML-Attributwerte verwendet, weil dieses Script zusätzlich verschiedene
DOMs berücksichtigen *muss*. Die paar Zeichen zusätzlich durch den
Methodenaufruf im Event-Handler-Attribut sind dann nicht mehr relevant.

Und damit mir hier nicht wieder ein Neunmalkluger einen vermeintlichen
Widerspruch in der Argumentation unterstellen kann, stelle ich hiermit klar:

Die (undeutlicher formulierte) Aussage, dass ein Client ohne aktivierten
Script-Support bei "Unobtrusive JavaScript" keinen Script-Code herunterladen
muss, ist richtig.

Falsch ist jedoch die darauf begründete Argumention, dass "Unobtrusive
JavaScript" aus diesem Grund signifikant besser als der herkömmliche Ansatz sei.

Sie ist deshalb falsch, weil bei dem herkömmlichen Ansatz ebenso nur das
Script, in welchem sich die Methodendeklarationen befinden, heruntergeladen
wird, wenn Script-Support aktiviert ist.

Wird es heruntergeladen, ist dieses jedoch, da aufgrund der an die Methoden
übergebene Objektreferenz (meist `this') nur selten eine Unterscheidung
zwischen verschiedenen DOMs nötig ist, tendenziell signifikant kleiner als
ein "Unobtrusive JavaScript".

Die zusätzlichen Bytes für den blossen Aufruf der Methoden, die natürlich
beim herkömmlichen Ansatz immer heruntergeladen werden müssen (die Bytes
für den Aufruf, nicht die Methoden selbst), sind im Vergleich dazu nicht
signifikant.

Weiterhin wird ein UA, bei dem kein aktivierter Script-Support vorliegt,
die Event-Handler-Attributwerte ignorieren. Von einer "Belästigung mit
JavaScript" kann daher nicht die Rede sein.

Zusammenfassend:

Der herkömmliche Ansatz des DOM-Scriptings mit Event-Handler-Attributen
bietet bei Anwendung mit Sinn und Verstand (Methodenaufrufe, Event Bubbling)
bei tendenziell geringerer Downloadgrösse, grösserer Robustheit und höherer
Effizienz (sowohl was die Laufzeit- als auch Speichereffizienz betrifft) die
gleiche Funktionalität wie "Unobtrusive JavaScript", und ist deshalb
Letzterem auf jeden Fall vorzuziehen.


PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7 (AT) news (DOT) demon.co.uk>

Thomas 'PointedEars' Lahn schrieb:

Thomas 'PointedEars' Lahn wrote:
Wolfgang Fellger wrote:
Und damit mir hier nicht wieder ein Neunmalkluger einen vermeintlichen
Widerspruch in der Argumentation unterstellen kann, stelle ich hiermit klar:

Der Punkt ist, dass du dich gerne als zehnmalkluger hinstellst und
Kritik auch Grundsätzlich als persönlichen Angriff wertest oder die
Antowrten darauf zumindest so ausschmückst als ob es für dich einer
wäre, insofern ist die obige, leicht weinerlich klingende Bemerkung
gerade von dir belustigend.

Die (undeutlicher formulierte) Aussage, dass ein Client ohne aktivierten
Script-Support bei "Unobtrusive JavaScript" keinen Script-Code herunterladen
muss, ist richtig.

Das halte ich im zusammenhang dieser Diskussion für völlig unbedeutend.
Natürlich kann man darauf achten, dass unnötige Sachen nicht geladen
werden müssen. Aber der Punkt beim Unobtrusive Javascript ist ein anderer.

Weiterhin wird ein UA, bei dem kein aktivierter Script-Support vorliegt,
die Event-Handler-Attributwerte ignorieren. Von einer "Belästigung mit
JavaScript" kann daher nicht die Rede sein.

Es geht nicht um Belästigung, sondern um die Trennung verschiedener
funktionalitäten. Mit deiner Argumentation spricht auch nichts gegen die
Verwendung von CSS Inlinestyles. Unter gewissen Vorrausetzungen, kann
man das machen. Aber sobald das Projekt größer wird, sollte man (und
wird es auch) alles voneinander trennen was nichts miteinander zu tun hat.

Ein kleines Beispiel. Ich verwende im Rahmen einer Webanwendung
Tooltipps, die mit JS angezeigt werden. Die erreiche ich dadurch, dass
die entsprechenden Elemente eine CSS-Klasse 'tooltipp' erhalten. Dies
wird in einem zentralen Template gemacht und fertig.
Das JS sucht sich die entsprechenden Elemente und fügt gegebenenfalls
den onmouseover und onmouseout-event hinzu.

Auch gehört dazu, dass eine Anwendung globale Variabeln vermeidet, z.b.
durch Kapselung mit einer anonymen Funktion, was durchaus auch sinnvoll
ist.

Zusammenfassend:

Der herkömmliche Ansatz des DOM-Scriptings mit Event-Handler-Attributen
bietet bei Anwendung mit Sinn und Verstand (Methodenaufrufe, Event Bubbling)
bei tendenziell geringerer Downloadgrösse, grösserer Robustheit und höherer
Effizienz (sowohl was die Laufzeit- als auch Speichereffizienz betrifft) die
gleiche Funktionalität wie "Unobtrusive JavaScript", und ist deshalb
Letzterem auf jeden Fall vorzuziehen.

Die tendenziell geringe Donwloadgröße müßte noch bewiesen werden und
dürfte von stark schwanken - bei meinem Beispiel mit den Tooltipps,
dürfte deine Aussage eher nicht zutreffen.
Die Robustheit ist aber geringer bei inline Eventaufrufen, da du sobald
du die Funktion änderst oder löscht und sei es nur versehen,
Fehlermeldungen bekommst, im anderen Fall passiert einfach gar nichts.
Und was die Laufzeit betrifft, kannst du bei Unobtrusiven JS eher auf
Browserspezifische Eigenschaften eingehen, was dir unter Umständen das
ständige Überprüfen, mit wem du es eigentlich zu tun hast, ersparen kann.

Ausserdem ist die Wiedervertbarkeit bei Unobtrusive Javascript größer,
da die Kopplung an ein Element nicht so eng ist und auch die oben
erwähnte Kapselung kann den Einsatz erleichtern, wenn du mal
verschiedene Skripte miteinander verknüpfen musst.

Alles in allem ist dies ein guter Ansatz, der den Einsatz von JS
erleichtert.

Struppi.

J. Strübig wrote:

Thomas 'PointedEars' Lahn schrieb:
Thomas 'PointedEars' Lahn wrote:
Wolfgang Fellger wrote:
Die (undeutlicher formulierte) Aussage, dass ein Client ohne aktivierten
Script-Support bei "Unobtrusive JavaScript" keinen Script-Code herunterladen
muss, ist richtig.

Das halte ich im zusammenhang dieser Diskussion für völlig unbedeutend.
Natürlich kann man darauf achten, dass unnötige Sachen nicht geladen
werden müssen. Aber der Punkt beim Unobtrusive Javascript ist ein anderer.

Obiges war Wolfgangs Argument.

Weiterhin wird ein UA, bei dem kein aktivierter Script-Support vorliegt,
die Event-Handler-Attributwerte ignorieren. Von einer "Belästigung mit
JavaScript" kann daher nicht die Rede sein.

Es geht nicht um Belästigung, sondern um die Trennung verschiedener
funktionalitäten.

Ja, es wird Code auseinandergerissen, der zusammengehört (DOM-Scripts
operieren auf spezifischem Markup). Und das soll dann angeblich auch
noch die Wartbarkeit verbessern.

Mit deiner Argumentation spricht auch nichts gegen die
Verwendung von CSS Inlinestyles.

Wie schon geschrieben: das ist ein Vergleich von Äpfeln und Birnen. Bei
CSS gibt es keine Funktionseinschränkung durch das Auslagern in eine
Style-Ressource, es gibt kein Stylesheet-Bubbling und nicht zuletzt ist
auch die Spezifizität der CSS-Regeln eine andere. Und ...

Unter gewissen Vorrausetzungen, kann man das machen. Aber sobald das Projekt größer wird, sollte man (und
wird es auch) alles voneinander trennen was nichts miteinander zu tun hat.

Der Punkt ist, dass die Code-Teile hier noch viel mehr miteinander zu tun
haben als bei Stylesheets.

Ein kleines Beispiel. Ich verwende im Rahmen einer Webanwendung
Tooltipps, die mit JS angezeigt werden. Die erreiche ich dadurch, dass
die entsprechenden Elemente eine CSS-Klasse 'tooltipp' erhalten. Dies
wird in einem zentralen Template gemacht und fertig.
Das JS sucht sich die entsprechenden Elemente und fügt gegebenenfalls
den onmouseover und onmouseout-event hinzu.

Da sowohl der mouseover- als auch der mouseout-Event in allen DOMs bubblen,
ist diese Lösung mindestens ineffizienter als eine mit Event Bubbling. Sie
ist im Vergleich auf jeden Fall fehlerträchtiger und der Footprint sowohl
des Codes als auch des damit alloziierten Speichers ist grösser.

Auch gehört dazu, dass eine Anwendung globale Variabeln vermeidet, z.b.
durch Kapselung mit einer anonymen Funktion, was durchaus auch sinnvoll
ist.

Globale Variablen sind für eine herkömmliche Lösung nicht erforderlich.

Zusammenfassend:

Der herkömmliche Ansatz des DOM-Scriptings mit Event-Handler-Attributen
bietet bei Anwendung mit Sinn und Verstand (Methodenaufrufe, Event Bubbling)
bei tendenziell geringerer Downloadgrösse, grösserer Robustheit und höherer
Effizienz (sowohl was die Laufzeit- als auch Speichereffizienz betrifft) die
gleiche Funktionalität wie "Unobtrusive JavaScript", und ist deshalb
Letzterem auf jeden Fall vorzuziehen.

Die tendenziell geringe Donwloadgröße müßte noch bewiesen werden und
dürfte von stark schwanken - bei meinem Beispiel mit den Tooltipps,
dürfte deine Aussage eher nicht zutreffen.

Du irrst. Quickhack:

<head>
<meta http-equiv="Content-Script-Type" content="text/javascript">
<script type="text/javascript">
function tooltip(e, bShow)
{
var t = e.target || e.srcElement;
if (t && /\btooltip\b/i.test(t.className))
{
if (bShow)
{
// show tooltip
}
else
{
// hide tooltip
}
}
}
</script>
</head>

<body onmouseover="tooltip(event, true)"
onmouseout="tooltip(event, false)">
...
</body>

Die Robustheit ist aber geringer bei inline Eventaufrufen, da du sobald
du die Funktion änderst oder löscht und sei es nur versehen,
Fehlermeldungen bekommst, im anderen Fall passiert einfach gar nichts.

Ja. Bei Tooltips ist das Fehlen der Funktionalität aber auch nicht kritisch.

Und was die Laufzeit betrifft, kannst du bei Unobtrusiven JS eher auf
Browserspezifische Eigenschaften eingehen, was dir unter Umständen das
ständige Überprüfen, mit wem du es eigentlich zu tun hast, ersparen kann.

Ja. Das wird entweder erkauft mit der Beschränkung auf wenige DOMs oder
im Falle der erzielten Universalität (die so aber nicht mal ansatzweise
erreicht werden kann) durch zahlreiche Fallunterscheidungen, die, wenn sie
konsequent und damit weitestgehend sicher gemacht werden, insgesamt die
Implementation des Features (hier: Tooltip) verlangsamen. Womit wir wieder
bei der inhärenten Fehlerträchtigkeit und Ineffizienz dieses Ansatzes wären.

Ausserdem ist die Wiedervertbarkeit bei Unobtrusive Javascript größer,
da die Kopplung an ein Element nicht so eng ist und auch die oben
erwähnte Kapselung kann den Einsatz erleichtern, wenn du mal
verschiedene Skripte miteinander verknüpfen musst.

Genau das bestreite ich. DOM-Scripting ist *immer* an den Dokumentbaum
gebunden. Die Möglichkeiten zur Wiederverwendung eines solchen DOM-Scripts
sind somit sehr eingeschränkt.

Alles in allem ist dies ein guter Ansatz, der den Einsatz von JS
erleichtert.

Er bürdet lediglich *dem Benutzer* *voraussehbare* Probleme auf, weil *der
Entwickler* *unfähig ist*, serverseitiges und clientseitiges Scripting
richtig und mithin benutzerfreundlich einzusetzen.


PointedEars

Thomas 'PointedEars' Lahn schrieb:

Genau das bestreite ich. DOM-Scripting ist *immer* an den Dokumentbaum
gebunden.

Es ist immer an Teile des DOM-Baumes gebunden.

Die Möglichkeiten zur Wiederverwendung eines solchen DOM-Scripts
sind somit sehr eingeschränkt.

Solange diese Teile vorhanden sind, sind sie wiederverwendbar.
Wenn dem nicht so wäre, gäbe es diverse (GUI)Frameworks und Plugins und
Libs nicht.

Alles in allem ist dies ein guter Ansatz, der den Einsatz von JS
erleichtert.

Er bürdet lediglich *dem Benutzer* *voraussehbare* Probleme auf, weil *der
Entwickler* *unfähig ist*, serverseitiges und clientseitiges Scripting
richtig und mithin benutzerfreundlich einzusetzen.

Das ist eine Behauptung deinerseits. Mich würde interessieren, wie du zu
dieser Behauptung kommst und in welchem deiner Projekte in Live-Betrieb
und mit mehr als 3.000 loc (selbst geschrieben) du diese Meinung
gefunden hast.

br | rb
--
Sie freuten sich riesig, wenn eine Maschine nach sechs Stunden etwas
fertig brachte, wozu jeder Mensch auf der Straße für 2 Cent fähig
gewesen wäre. Anschließend ließen sie sich Bananen- und Sushi-Pizza
kommen und schliefen vor der Tastatur ein. [aus T.P., Heiße Hüpfer]

Thomas 'PointedEars' Lahn schrieb:

J. Strübig wrote:
....

Obiges war Wolfgangs Argument.

ooops, da hab ich was falsches stehen gelassen :-(

Weiterhin wird ein UA, bei dem kein aktivierter Script-Support vorliegt,
die Event-Handler-Attributwerte ignorieren. Von einer "Belästigung mit
JavaScript" kann daher nicht die Rede sein.
Es geht nicht um Belästigung, sondern um die Trennung verschiedener
funktionalitäten.

Ja, es wird Code auseinandergerissen, der zusammengehört (DOM-Scripts
operieren auf spezifischem Markup). Und das soll dann angeblich auch
noch die Wartbarkeit verbessern.

Das seh ich anders, wieso operieren Skripte auf spezifischen Markup?
Ich kann Skripte völlig lösgelöst von einem Markup entwickeln, sie
müssen nur aufgerufen werden, aber selbst das kann das Skript selbst
erledigen und ein Element mit der entpsrechenden Funktionalität in den
Baum einfügen.
Eher gehört das CSS zum spezifischem Markup

Mit deiner Argumentation spricht auch nichts gegen die
Verwendung von CSS Inlinestyles.

Wie schon geschrieben: das ist ein Vergleich von Äpfeln und Birnen. Bei
CSS gibt es keine Funktionseinschränkung durch das Auslagern in eine
Style-Ressource, es gibt kein Stylesheet-Bubbling und nicht zuletzt ist
auch die Spezifizität der CSS-Regeln eine andere. Und ...

Ja, z.b. #menu ul li, das gehört ganz klar zu einem Markup, aber
if(element.className == 'tooltipp') { ..... } nicht.

Und um das Bubbling kümmert sich das Skript. Mir ist auch nicht ganz
klar wo du da die Probleme siehst.

Unter gewissen Vorrausetzungen, kann man das machen. Aber sobald das Projekt größer wird, sollte man (und
wird es auch) alles voneinander trennen was nichts miteinander zu tun hat.

Der Punkt ist, dass die Code-Teile hier noch viel mehr miteinander zu tun
haben als bei Stylesheets.

Also das ist in meiner Erfahrung eine andere, bei Stylesheets muss man
teilweise höllisch aufpassen, welche Eigenschaft vererbt werden welche
nicht und wenn man mehrere externe Stylesheets verwendet, kann es
schnell zu nicht gewollten Effekten kommen. Im gegensatz dazu sollten
Skripte die konsequent unobtrusiv entwickelt wurden sich nicht in die
Quere kommen.

Auch gehört dazu, dass eine Anwendung globale Variabeln vermeidet, z.b.
durch Kapselung mit einer anonymen Funktion, was durchaus auch sinnvoll
ist.

Globale Variablen sind für eine herkömmliche Lösung nicht erforderlich.

Es gibt Fälle bei denen es manchmal schwierig ist, sie zu vermeiden.
gerade wenn Objekte zu verschiedenen Events durchgereicht werden müssen.

Die tendenziell geringe Donwloadgröße müßte noch bewiesen werden und
dürfte von stark schwanken - bei meinem Beispiel mit den Tooltipps,
dürfte deine Aussage eher nicht zutreffen.

Du irrst. Quickhack:
.....

body onmouseover="tooltip(event, true)"
onmouseout="tooltip(event, false)"

OK, das geht so. Ist aber nur unbedeutend weniger als:

document.onmouseover = function(e) {tooltip(e||event, true); };
document.onmouseout = function(e) {tooltip(e||event, false); };

(besser ist noch eine Funktion die addEvent o.ä. nutzt)

Nur - wenn die Funktion tooltip() nicht mehr da ist, wirst du mit
Fehlermeldungen beglückt, während im anderen Falle einfach nichts passiert.

Und was die Laufzeit betrifft, kannst du bei Unobtrusiven JS eher auf
Browserspezifische Eigenschaften eingehen, was dir unter Umständen das
ständige Überprüfen, mit wem du es eigentlich zu tun hast, ersparen kann.

Ja. Das wird entweder erkauft mit der Beschränkung auf wenige DOMs oder
im Falle der erzielten Universalität (die so aber nicht mal ansatzweise
erreicht werden kann) durch zahlreiche Fallunterscheidungen, die, wenn sie
konsequent und damit weitestgehend sicher gemacht werden, insgesamt die
Implementation des Features (hier: Tooltip) verlangsamen. Womit wir wieder
bei der inhärenten Fehlerträchtigkeit und Ineffizienz dieses Ansatzes wären.

Jetzt weiß ich nicht ob wir nicht aneinander vorbei reden. Aber so wie
ich das meine, musst du die Fallunterscheidungen in der klassischen
Variante immer machen, im Falle eines unobtrusiven Skriptes kann eine
dauerende Fallunterscheidung leichter verhindert werden.

z.b.

if(document.getElementById) {
document.onmouseover = function(e) {tooltip(e||event, true); };
document.onmouseout = function(e) {tooltip(e||event, false); };
}

So musst du nie in der tooltip Funktion überprüfen ob du einen NS 4 vor
dir hast und es wir auch nie ein Event aufgerufen.

Ausserdem ist die Wiedervertbarkeit bei Unobtrusive Javascript größer,
da die Kopplung an ein Element nicht so eng ist und auch die oben
erwähnte Kapselung kann den Einsatz erleichtern, wenn du mal
verschiedene Skripte miteinander verknüpfen musst.

Genau das bestreite ich. DOM-Scripting ist *immer* an den Dokumentbaum
gebunden. Die Möglichkeiten zur Wiederverwendung eines solchen DOM-Scripts
sind somit sehr eingeschränkt.

Und das bestreite ich. Wieso sollte ein Skript an den Dokumentenbaum
gebunden sein?

Alles in allem ist dies ein guter Ansatz, der den Einsatz von JS
erleichtert.

Er bürdet lediglich *dem Benutzer* *voraussehbare* Probleme auf, weil *der
Entwickler* *unfähig ist*, serverseitiges und clientseitiges Scripting
richtig und mithin benutzerfreundlich einzusetzen.

Gerade durch unobtrusive JS vermeidest du vorhersehbare Probleme und
bist dabei noch auf der sicheren Seite wenn es um Erweiterungen geht.

Struppi.

P.S. ich muss hier noch positiv erwähnen, dass du - trotz meiner
leichten Provokation am Anfang - nicht deinen sonst üblichen Postingstil
einsetzt. Es ist wesentlich angenehmer sachlich und in einem
freundlichen Ton zu diskutieren, als ständig auf Verunglimpfungen
eingehen zu müssen. Die oft nicht nötig wären, zumal alle hier Wissen,
das deine fachliche Kompetenz nicht bestreitbar ist. Auch wenn wir hier
anderer Meinung sind.
Danke.