Allgemeine Frage: jQuery lieber immer benutzen?

[JavaScriptFrager]

Hi,

ich habe eine kleine Seite geschrieben, bei der ich auch ein wenig dynamische DOM-Manipulation mache. Das ganze ist banaler JavaScript code. Jetzt habe ich angefangen ein paar hübsche Animationen mittels jQuery einzuarbeiten und stelle dabei fest, dass vieles was ich direkt gecoded habe auch damit machbar wäre (z.B. .append oder .insertBefore sowie ein wenig AJAX).

Könnt ihr euch hinreichend plausible Gründe überlegen, warum ich funktionierenden Code durch die entsprechenden jQuery-Funktionen ersetzen sollte?

MfG

[LX]

Hi!

Könnt ihr euch hinreichend plausible Gründe überlegen, warum ich funktionierenden Code durch die entsprechenden jQuery-Funktionen ersetzen sollte?

Mit jQuery wird der Code meistens kleiner und manchmal auch besser wartbar. Außerdem kannst Du, wenn Du ohnehin schon daran basteln willst, Deine jQuery-Kenntnisse vertiefen. Zudem bringt jQuery reichlich Browser-Abstraktion für den Fall mit, dass bestimmte Objekte nicht verfügbar ist, damit bist Du auch relativ zukunftssicher.

Andererseits musst Du Dir die Arbeit nicht wirklich machen, wenn Du nicht willst.

Gruß, LX

[Malcolm Beck´s]

مرحبا

Mit jQuery wird der Code meistens kleiner und manchmal auch besser wartbar.

Du kennst dich ja mit JQuery aus, wie ist es eigentlich mit dem onload-Event von JQuery ($(document).ready(function(){}))?
Ich binde Javascripte immer am ende meiner Dokumente ein, vor den schliessenden </body></html>, hier könnte ich doch eigentlich auf onload verzichten, oder wie Handhabe ich das?

Ich hatte bei einigen Animationen Fehldarstellungen, wenn ich diese ohne $(document).ready aufgerufen habe, bei anderen wiederum nicht, aber woher weiss ich, wann onload, und wann nicht? Wenn die Javascripte zum schluss eingebunden werden, ist das Dokument ja schon geladen.

mfg

[Der Martin]

Hallo,

Ich binde Javascripte immer am ende meiner Dokumente ein, vor den schliessenden </body></html>, hier könnte ich doch eigentlich auf onload verzichten, oder wie Handhabe ich das?

da gibt's aber einen wichtigen, manchmal entscheidenden Unterschied.

Wenn die Javascripte zum schluss eingebunden werden, ist das Dokument ja schon geladen.

Ja, aber andere eingebundene Ressourcen wie etwa Bilder noch nicht unbedingt; auch externe Stylesheets sind in diesem Moment möglicherweise noch nicht interpretiert und angewendet worden. Dagegen wird onload (bzw. das Äquivalent von jQuery) so lange verzögert, bis alle diese Haushaltsarbeiten auch erledigt sind.
Man muss im Einzelfall überlegen, was wichtiger ist: Reicht es, dass das DOM vollständig ist? Kann ich akzeptieren, dass das Dokument für einen Augenblick so angezeigt wird, wie es ohne den JS-Eingriff halt aussieht?

So long,
 Martin

[Malcolm Beck´s]

مرحبا ChrisB und Martin,

onload heisst, *alle* externen Ressourcen sind fertig geladen - Bilder, CSS, ...
document.ready hingegen heißt nur, das HTML-Dokument ist fertig geladen und das DOM komplett aufgebaut.

Ja, aber andere eingebundene Ressourcen wie etwa Bilder noch nicht unbedingt;

Ah, diese unterscheidung war mir nicht ganz bewusst. Ich hatte immer nur gelesen, dass es besser sei, bei JQuery einfach nur document.ready zu nutzen, statt onload, ohne dass die Unterschiede erwähnt wurden; Danke euch für die Erklärung.

mfg

[ChrisB]

Hi,

Ich hatte bei einigen Animationen Fehldarstellungen, wenn ich diese ohne $(document).ready aufgerufen habe, bei anderen wiederum nicht, aber woher weiss ich, wann onload, und wann nicht?

onload heisst, *alle* externen Ressourcen sind fertig geladen - Bilder, CSS, ...
document.ready hingegen heißt nur, das HTML-Dokument ist fertig geladen und das DOM komplett aufgebaut.

Letzteres ist fein, wenn du mit JavaScript DOM-Element manipulieren willst - leg' los.

Aber gerade Sachen wie Animationen sind oftmals darauf angewiesen, dass Elementmaße/-positionen bekannt sind - also müssen Bilder fertig geladen und/oder das CSS bereits angewendet worden sein, sonst stimmen die Werte, die dyanmisch ausgelesen werden, nicht.

MfG ChrisB

[molily]

Aber gerade Sachen wie Animationen sind oftmals darauf angewiesen, dass Elementmaße/-positionen bekannt sind - also müssen Bilder fertig geladen und/oder das CSS bereits angewendet worden sein, sonst stimmen die Werte, die dyanmisch ausgelesen werden, nicht.

Die Ausführung von Scripten wartet auf das Herunterladen von Stylesheets. Bei DOM ready sind gemäß HTML5-Parsing auch immer alle Stylesheets geladen. Das ist in allen Browsern außer Opera auch schon der Fall.
Details: http://molily.de/weblog/domcontentloaded

Mathias

[Ole.]

Hi

$(document).ready()

Prüft ob das DOM vollständig geladen wurde. In den meisten Fällen HTML + CSS

$(window).load()
Ist das Pendant zum onload Event-Handler. Wird also erst ausgeführt, wenn alle Ressourcen geladen wurden.

Gruß
Ole

[Kai345]

[latex]Mae  govannen![/latex]

Könnt ihr euch hinreichend plausible Gründe überlegen, warum ich funktionierenden Code durch die entsprechenden jQuery-Funktionen ersetzen sollte?

Ich persönlich finde jQuery furchtbar und würde natürlich eher dagegen raten, aber das bringt dich wohl nicht weiter.

Also: es kommt ganz einfach darauf an, wie viel "herkömmliches" JS du bisher hast und was genau das macht. Du mußt abwägen:

Einheitlicher (jQuery)Stil gegen Komplexität/Performance/Kompatibilität bei Browsern/Aufwand des Neuschreibens/andere Kriterien. Üblicherweise ist die Verwendung der JS- Methoden performanter (jQuery macht auch nix anderes als diese Funktionen aufzurufen, allerdings über weitere Methoden). Ich würde nicht unbedingt alles umschreiben, wenn das bisherige JS gut funktioniert. Schließt sich ja auch nicht gegenseitig aus. Wie oben geschrieben - es kommt halt darauf an, wie wichtig dir bestimmte Kriterien sind, das kannst auch nur du entscheiden.

Cü,

Kai

[Klawischnigg]

Hi there,

Könnt ihr euch hinreichend plausible Gründe überlegen, warum ich funktionierenden Code durch die entsprechenden jQuery-Funktionen ersetzen sollte?

Nein, ausser Deine bisherige Seite lädt Dir zu schnell...

[hotti]

Moin,

Könnt ihr euch hinreichend plausible Gründe überlegen, warum ich funktionierenden Code durch die entsprechenden jQuery-Funktionen ersetzen sollte?

Nein, ausser Deine bisherige Seite lädt Dir zu schnell...

Richtig! Sehe ich genauso ;-)

Ne mal ernsthaft, jQuark ist schon der Hammer. Andererseits ist abzuwägen, ob da wirklich alles gebraucht wird. Wir leben zwar im Zeitalter der Breitbandanschlüsse, aber kurze Ladezeiten sind aktueller denn je. Schlanke Seiten, schlanker Code ist da bei mir angesagt. Ich baue mein eigenes Framework, Stück für Stück, und nur das, was ich tatsächlich gerade brauche, wird da eingebunden. Wenn ich eine Axt brauche, kaufe ich doch auch nicht gleich ein ganzes Sägewerk.

Z.Z. bin ich dabei, Scripts mit Datenbankanbindungen abzubauen, bzw. umzubauen auf Binaryfiles als Datenquelle, auch das Forum, an dem ich gerade schreibe. Die Performance ist elegant. Nurmalso nebenbei...

Hottü

[offline]

Hallo,

Wir leben zwar im Zeitalter der Breitbandanschlüsse, aber kurze Ladezeiten sind aktueller denn je.

Bezieht man sich die JQuery-Quellen zb vom Google-Server, so kann man davon ausgehen, dass ein nicht gerade geringer Anteil der Benutzer die Bibliothek bereits im Browser-Cache vorliegen hat.

Schlanke Seiten, schlanker Code ist da bei mir angesagt.

Das schlieszt JQuery nicht per se aus. Und schlank geht auch nur, wenn die Komplexitaet und Anforderungen recht ueberschaubar sind.

Ich baue mein eigenes Framework, Stück für Stück, und nur das, was ich tatsächlich gerade brauche, wird da eingebunden. Wenn ich eine Axt brauche, kaufe ich doch auch nicht gleich ein ganzes Sägewerk.

Zum privaten Zeitvertreib vielleicht recht spaszig. Aber von Eigenbroedeleien ist in dem meiszten aller Faelle abzuraten (auszer man hat ordentlich Manpower und einen Investor, der gerne Geld aus dem Fenster schmeisst).

Z.Z. bin ich dabei, Scripts mit Datenbankanbindungen abzubauen, bzw. umzubauen auf Binaryfiles als Datenquelle, auch das Forum, an dem ich gerade schreibe. Die Performance ist elegant. Nurmalso nebenbei...

Oha. Ich nehme an, der Performance wegen, befinden sich die Binary-Files auf dem selben Rechner wie die Quellen?

offline

[hotti]

Hallo,

»».. Die Performance ist elegant. Nurmalso nebenbei...
Oha. Ich nehme an, der Performance wegen, befinden sich die Binary-Files auf dem selben Rechner wie die Quellen?

Freilich gehts um Performance, und wie! Zum Thema Anbindung einer DB über Ethernet (danke für den Link):

* UA Request an Webserver, Besucher will eine Seite sehen
* Webserver startet einen CGI-Prozess
* Webserver schickt Anfrage an MySQL Server, dabei wird auch ein Regelwerk einer Firewall durchlaufen
* MySQLd schickt Response an Webserver zurück, auch über Ethernet, Regelwerk...
* Webserver baut die Seite zusammen
* Webserver schickt die Response zum UA

Und das alles wegen bischen Hypertext. Gehts noch!?

Tut mir leid, wenn wir das hier nicht zur Neige ausdiskutieren können, am Besten ists, Du machst Deine eigenen Erfahrungen. Ich gebe hier schon genug knowhow weiter (hehe, aber nicht ALLEs).

Schönes Wochenende,
Hotti

[offline]

Hallo Hotti,

du behauptest, dass eine Datenhaltung in Binaerdateien performanter sei, als die Daten in einer Datenbank zu halten*.
Aehm.. du bist dir aber schon im klaren darueber, wie eine DB ihre Daten letzten Endes haelt?

Zum Thema Anbindung einer DB über Ethernet

Geht es dir jetzt um einen Vergleich zwischen DB und Nicht-DB, oder um die Verteilung der Datenbank auf verschiedenen Servern? Ersteres ergebe wohl keinen Sinn, zu letzterem hat dir Chris schon einige Stichwoerter genannt.
Sagt dir das ganze ueberhaupt etwas - oder hast du es dir zumindest mal angeschaut?

Und das alles wegen bischen Hypertext.

Oha, aber ein paar groeszeren Projekten warst du schon mal beteiligt, ja?

Ich gebe hier schon genug knowhow weiter (hehe, aber nicht ALLEs).

Und das ist sicher auch besser so.

offline

* »» Eine sehr performante Alternative zur Datenhaltung sind Binärdateien.

[LX]

Nein, ausser Deine bisherige Seite lädt Dir zu schnell...

JS-Frameworks sind immer Kompromisslösungen. Bildet man alle möglichen Aufgaben ab, werden sie groß und schwerfällig, reduziert man sie auf die wesentliche Aufgaben, muss man Kompromisse in Hinblick auf Bequemlichkeit oder sogar Browser-Kompatibilität in Kauf nehmen.

jQuery ist mit gepackt 24kb noch eines der kleinsten Frameworks und verlangsamt Seiten vergleichsweise wenig (wenn man beispielsweise YUI, prototype oder gar Scriptacolous zum Vergleich gegenüberstellt). Weil mir das noch zu groß war, habe ich mir selbst ein Framework namens tiny.js geschrieben, welches debugbar gepackt lediglich 3,8kb benötigt.

Es stimmt: Reines JS wird üblicherweise kleiner und performanter sein, dafür aber auch schwerer und langsamer zu entwickeln. Gerade bei großen Projekten mit vielen Mitarbeitern sind Frameworks daher durchaus praktisch, besonders, wenn sie wie jQuery die Entwicklung des eigentlichen Codes deutlich beschleunigen können.

Gruß, LX

[JavaScriptAntworter]

Könnt ihr euch hinreichend plausible Gründe überlegen, warum ich funktionierenden Code durch die entsprechenden jQuery-Funktionen ersetzen sollte?

Bibliotheken wie JQuery decken mit ein- und derselben Methode grundsätzlich mehr Browser ab, einschließlich ihrer Feinheiten, Eigenheiten, Fehler und Erweiterungen. Würdest du nur getElementById() verwenden oder dich auf deinen eigenen Browser beschränken, wäre das natürlich ziemlich wurscht, nutzt du hingegen komplexere Methoden oder schreibst du Webseiten für eine breitere Öffentlichkeit, hast du mit einer Javascript/DOM-Bibliothek durchaus Vorteile.

Wie vorteilhaft das theoretisch sein könnte, hängt von der Breite der Öffentlichkeit ab. Wie vorteilhaft das in der Praxis ist, wirst du nie erfahren, weil Besucher quasi immer kommentarlos auf Nimmerwiedersehen verschwinden, wenn etwas nicht funktioniert, anstatt sich bei dir über deinen selbstgestrickten Code zu beschweren.

[JavaScriptFrager]

Danke, allein schon die Browserkompatibilität ist für mich Grund genug nochmal alles umzuschreiben. Denke das jQuery da gründlicher testet als ich, der nichtmals den IE installiert hat...

Thx!