jQuery vs native DOM Zugriff

[Elma]

Hi.

Was ist eigentlich besser, wenn man mit JavaScript das DOM einer einzelnen Seite verändern möchte?
Es sollen regelmäßig neue Nachrichten in ein mehrzeiliges Textfeld bzw in ein Div hinzugefügt werden.

Würdet ihr es nativ mit den entsprechendne Javascript Funktionen machen, also z.B. document.getElementById("id");
Oder würdet ihr dann schon jQuery nehmen?

Welche Vorteile und welche Nachteile würde die Verwendung von jQuery bringen?

 

[mikdoe]

http://forum.jswelt.de/allgemeine-d...ms-internet/62588-inspiration-gegen-libs.html

das ist wie eine religion

 

[Elma]

Momentan greife ich direkt mit vanilla js auf das DOM zu, alleine schon aus Lernzwecken.
Ob ich dann auf jQuery gehe, hab ich noch nicht entschieden.

Momentan mache ich den Output in einem <div> Container.
Für jede message füge ich dem div folgendes hinzu:
<msg id="msg-nr" at="null">Nachricht</msg>

Das ist also ein eigenes HTML Element, statt jede Nachricht als DIV zu erstellen.
Sieht schicker im Quellcode aus und funktioniert. Ich kann es über document.getElementById('msg-nr'); auch recht einfach ansteuern.
In dem eigenen Attribut at werden Begleitinformationen zur Nachricht gespeichert um diese mit js auszuwerten (z.B. Timestamp oder ähnliches, zur Zeit noch nicht benutzt)

 

[mikdoe]

Sieht schicker im Quellcode aus

dort siehst du doch höchstens den js code und nicht die dynamisch hinzugefügten elemente. oder schaust du dir das in der konsole an?

 

[kkapsner]

Ich würde für so etwas alleine noch nicht jQuery mit an Bord nehmen, aber wenn du es später (oder auch schon jetzt) an Bord hast, kannst du es auch jetzt gleich schon verwenden. Der Overhead ist bei sowas ziemlich vernachlässigbar.

In dem eigenen Attribut at

Das ist aber nicht valide. Genau für solche Fälle gibt es die data-*-Attribute. Mach' einfach ein "data-at" daraus uns alles ist valide.

 

[Elma]

Hi.

Ja, ich schau mir das in der Konsole an. Und da finde ich das mit dem eigenen HTML Element msg schöner als mit divs.
Außerdem liefere ich die Seite schon mit ein paar Messages aus, die später ersetzt werden.
Das Attribut habe ich nun auf data-x geändert.
Außerdem nutze ich nun auch die Meta Angaben zum Abspeichern von Informationen wie z.B. User ID.

Ich werde nun jQuery mal testen und dann entscheiden ob ich es mit oder ohne jQuery mache.

Bei Vanilla JS Dom Zugriffen muss ich ja 5 Schritte machen um einen Message Knoten zu erstellen und sichtbar zu machen.
1. createElement
2. setAttribute
3. createTextNode
4. appentNode auf das soeben erzeugte Element
5. appendNode um das fertige Element in das Dom einzufügen.

hier mein Quelltext

function erstellen() {
i++;
var el=document.createElement('msg');
el.setAttribute('id', i);
el.setAttribute('data-x', "0");
var txt=document.createTextNode ('Dies ist ein Text, Nummer: ' + i);
el.appendChild (txt);
A.appendChild(el);

P.S.:
Am Anfang des Scriptes mach ich noch folgendes:
var A = document.getElementById('messagebox');
Ich weiß dass man dafür keinen einzelnen Großbuchstaben nehmen sollte, da es nicht der Konvention entspricht, jedoch ist es dann in der Entwicklerkonsole dann schön weit oben und ich muss nicht scrollen.


Mal sehen ob jQuery einfacher ist als vanilla JS DOM Zugriffe.
Momentan ist alles noch relativ einfach gehalten aber es könnte ja mal mehr werden so dass jede Vereinfachung im Handling durchaus willkommen ist.

 

[kkapsner]

Und da finde ich das mit dem eigenen HTML Element msg schöner als mit divs.

Woah... das hatte ich oben ja ganz übersehen. Dann ist dein HTML natürlich komplett invalide. Das solltest du auf keinen Fall machen, nur damit das dann "schöner" in der Konsole aussieht. Wenn du unbedingt selbst Tags definieren willst, musst du schon einen Namespace verwenden und die Definitionsdatei erstellen/einbinden.

2. setAttribute

Die Standardattribute kannst du direkt durch Zuweisung setzen und die data-*-Attribute lassen sich über NODE.dataset setzen.

3. createTextNode
4. appentNode auf das soeben erzeugte Element

Kann man über eine Zuweisung an textContent vereinfachen:

function erstellen() {
	i += 1;
	var el = document.createElement("span");
	el.className = "msg";
	el.id = i;
	el.dataset.x = 0;
	el.textContent = "Dies ist ein Text, Nummer: " + i;
	A.appendChild(el);
}

jedoch ist es dann in der Entwicklerkonsole dann schön weit oben und ich muss nicht scrollen.

Du hast wirklich seltsame Kriterien für deine Entwicklungsentscheidungen.

PS: globale Variablen mit Namen i und A sind nicht wirklich dein Ernst...

 

[Elma]

Naja das mit den globalen Vaiablen ist nur für den Moment fürs Basteln. Produktiv würde ich es natürlich anders machen. Da würde ich wahrscheinlich camelCase nehmen und alles auch kapseln damit der globale Space frei bleibt.

Das mit dem "msg" statt div ist natürlich so ne Sache. Wenn der Aufwand, das Valide zu bekommen, zu hoch wird, würd ich natürlich ehr auf DIVs umschwenken.

 

[mikdoe]

Da würde ich wahrscheinlich camelCase nehmen und alles auch kapseln damit der globale Space frei bleibt.

was hat denn das eine mit dem anderen zu tun?

 

[Elma]

Hi.

Direkt miteinander zu tun hat es nicht. Es ist jedoch so, dass man für Variablen aussagekräftige Namen nehmen sollte. Am Besten camelCase Schreibweise und nicht nur einen einzelnen Buchstaben, damit man später auf einen Blick erkennt, wozu sie gut ist. Ausnahme sind gängige Zählvariablen wie z.B. i.
Zum Testen bin ich hier aber davon abgewichen und hab die Variable A genannt, weil sie dann in den Entwicklertools ganz oben steht.
Das werde ich aber noch ändern, sobald es über kleine Versuche hinausgeht.

Ansonsten wäre es natürlich auch noch gut, wenn ich einen "namespace" erschaffe, z.B. per Objektliteral oder Selbstausführender Kapselfunktion. Damit der globale Namespace nicht zugeknallt wird.
Den eigenen Namespace könnte ich natürlich A nennen, damit er in den Entwicklertools "ganz oben" erscheint, oder spricht da etwas dagegen?

 

[mikdoe]

Den eigenen Namespace könnte ich natürlich A nennen, damit er in den Entwicklertools "ganz oben" erscheint, oder spricht da etwas dagegen?

wie sieht das dann als code aus?

 

[Elma]

Moin.

Ich hab folgenden Code:

var A = (function A (){
	var foo="bar"
	//... //
}());

Das komplette Script würde man nun im Bereich von //... // hineinschreiben.

Alle Variablen bleiben dann innerhalb des Bereichs und gehen nicht in den globalen Bereich.
Lediglich A ist dort sichtbar. A hat den Vorteil, dass es "Ganz oben" steht.

Es gibt zwar auch die Variante mit der anonymen self-invoking funktion aber die findet man im debugger nicht auf den ersten Blick.

 

[mikdoe]

hmmmm
sieht seltsam aus. hab ich noch nie gesehen. was soll das werden?

 

[kkapsner]

Den eigenen Namespace könnte ich natürlich A nennen, damit er in den Entwicklertools "ganz oben" erscheint, oder spricht da etwas dagegen?

Einen eigenen "Namespace" (das ist nicht wirklich ein Namespace, sondern einfach nur eine globale Variable, die deine Sachen enthält) zu machen ist eine gute Idee - den dann "A" zu nennen eher weniger. Denn für Namespace gilt ja um so mehr:

aussagekräftige Namen

Es gibt zwar auch die Variante mit der anonymen self-invoking funktion

Was du da geschrieben hast ist eine benannte "self"-invoking function, was aber hier so gut wie keinen Unterschied macht...

hab ich noch nie gesehen.

Sicher nicht? Ich verwende sowas dauernd, wenn ich aus dem Funktionsscope ein paar Funktionen global verfügbar machen muss.

 

[mikdoe]

Sicher nicht? Ich verwende sowas dauernd, wenn ich aus dem Funktionsscope ein paar Funktionen global verfügbar machen muss.

das hab ich in der tat bisher nicht gebraucht. war da mal dran aber dann war es ein strukturfehler und hat sich dadurch erledigt.
komme da sicher bald mal hin.

 

[kkapsner]

das hab ich in der tat bisher nicht gebraucht.

War auch kein Vorwurf - du hattest nur geschrieben, dass du das noch nie gesehen hast, was mich gewundert hat, da ich das dauernd verwende und auch hier schreibe.

 

[mikdoe]

sieht dann wohl doch anders aus mit diesem großen A

 

[Elma]

@mikdoe also wenn man die self invoking funktion benennt, findet man sie halt besser in der Entwicklerkonsole. Das ist der Grund warum ich es gemacht habe.
Ansonsten kann es auch eine anonyme Funktion sein, wie man es in vielen Beispielen sieht.



Was jQuery vs Vanilla JS DOM betrifft:

Ich habe nun beides mal ausprobiert.
jQuery vereinfacht den DOM Zugriff ganz enorm.
Man muss nicht sowas machen:

var msgbox = document.getElementById("msg");
var el=document.createElement("div");
el.setAttribute('id', i);
el.innerHTML="Some Text";
msgbox.appendChild(el);

Sondern in jQuery reicht:

$("#msg").append('<div id=' + i + '>Some Text</div>');

Wenn man dann nicht über eine ID zugreift, sondern z.B. über den Name, nutzt man die gleiche Syntax und braucht nicht, wie bei Vanilla JS einen Extra Befehl wie GetElementsByName

Und wenn bei mehreren Divs etwas ändern will, wirds noch einfacherer im Vergleich zu Vanilla JS.
Man muss nicht erst über eine Schleife und NextSibling arbeiten, sondern jQuery macht auch das mit einer Zeile.

Man kann auch relativ leicht und Bequem Click Events, MouseOver Events usw zuweisen über jQuery.

Es gibt aber auch Grenzen von jQuery. Zum Beispiel ist es mir nicht gelungen, ein Mouse Over Element an document oder window zuzuweisen mit jQuery. Da muss man dann doch wieder mit Vanilla JS ran.


Ich denke, ich werde jQuery verwenden auch wenn ich es bei weitem nicht voll ausnutze.

 

[kkapsner]

also wenn man die self invoking funktion benennt, findet man sie halt besser in der Entwicklerkonsole.

Eine self invoking function wird man nie in der Entwicklerkonsole finden, außer man schreibt sie da explizit rein. Aber solche Funktionen zu benennen ist trotzdem gut, da es die Fehlersuche erleichtert.

Sondern in jQuery reicht:

Wenn du ds HTML unbedingt sebst zusammensticken willst, kannst du das auch mit nativem JS in einer Zeile machen:

document.getElementById("msg").insertAdjacentHTML("beforeEnd", '<div id=' + i + '>Some Text</div>');

Aber natürlich ist ein Framework dazu gedacht, dass es dir die Arbeit erleichtert.

Es gibt aber auch Grenzen von jQuery. Zum Beispiel ist es mir nicht gelungen, ein Mouse Over Element an document oder window zuzuweisen mit jQuery. Da muss man dann doch wieder mit Vanilla JS ran.

Das geht auch definitiv mit jQuery. Was hast du denn da probiert?

 

[Elma]

Moin.
Mit Entwicklerkonsole meine ich nicht nur die Ausgabe, die man mit console.log machen kann sondern auch die Ausgabe des Objektes (mit console.dir). Und das geht eben einfacher, wenn man einen Namen hat, den man angeben kann.
Ansonsten kann man es auch in den Entwicklertools von von Hand rauspicken wenn man einen Breakpoint gesetzt hat. Auch da macht ein Name das Auffinden leichter.



Ich habs nun auch geschafft mit jQuery auf Document und Window zuzugreifen. Im Gegensatz zu HTML Elementen wie z.B. "p" darf man das aber nicht in Anführungszeichen setzen.
Aber ich werde auf window und document wahrscheinlich trotzdem direkt zugreifen um herauszufinden ob das Dokument sichtbar ist und der User "aktiv" ist. Da bringt mir jQuery eh keinen solchen Vorteil wie bei der DOM Manipulation.