jQuery - Wert wieder löschen

[Bernd]

Hallo,

warum werden die Checkboxen nicht gelert? Ich habe gelesen, dieses könnte man mit

$(".group1").removeAttr('checked');

umsetzten, leider kein Erfolg. Das ganze Script

    $(".group1").prop("disabled", true);

		$(':radio[name=druck]').click(function(){
			    
			if($(this).val() == '1'){
			    $(".group1").prop("disabled", false);
			}

			else{
			   $(".group1").prop("disabled", true);
			   $(".group1").removeAttr('checked');
				}
			
		});

[Bernd]

Ok, es muss diese Zeile hinzugefügt werden

$(".group1").filter(':checkbox').prop('checked',false);

Das ganze sieht dann so aus

    $(".group1").prop("disabled", true);

		$(':radio[name=druck]').click(function(){
			    
			if($(this).val() == '1'){
			    $(".group1").prop("disabled", false); 
			}

			else{
			   $(".group1").prop("disabled", true);
			   $(".group1").filter(':checkbox').prop('checked',false);
				}
			
		});

[Gunnar Bittersmann]

@@Bernd

warum werden die Checkboxen nicht gelert? Ich habe gelesen, dieses könnte man mit

$(".group1").removeAttr('checked');

umsetzten

Geht problemlos. Du machst etwas falsch.

Zum Beispiel: deine fragliche Seite nicht zu verlinken.

LLAP 🖖

[Bernd]

Hallo,

Geht problemlos. Du machst etwas falsch.

bei mir leider nicht. Ich musste diese Variante nutzen

$(".group1").filter(':checkbox').prop('checked',false);

[MudGuard]

Hi,

		$(':radio[name=druck]').click(function(){

:radio? Ist das was jquery-spezifisches? Oder gibt es das in CSS (wäre mir neu)? Denn normalerweise ist doch in $() ein CSS-Selektor zu finden …

Gleiche Frage zum später erwähnten :checkbox.

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@MudGuard

		$(':radio[name=druck]').click(function(){

:radio? Ist das was jquery-spezifisches? Oder gibt es das in CSS (wäre mir neu)? Denn normalerweise ist doch in $() ein CSS-Selektor zu finden …

♫ jQuery spills the :radio star ♫

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

♫ jQuery spills the :radio star ♫

Da hab ich hach einem Reim auf kills gesucht …

Steht doch da, dass man :radio nicht verwenden sollte:

Because :radio is a jQuery extension and not part of the CSS specification, queries using :radio cannot take advantage of the performance boost provided by the native DOM querySelectorAll() method. For better performance in modern browsers, use [type="radio"] instead.

Also doch: ♫ jQuery kills the :radio star ♫

LLAP 🖖

[MudGuard]

Hi,

Steht doch da, dass man :radio nicht verwenden sollte:

Because :radio is a jQuery extension and not part of the CSS specification, queries using :radio cannot take advantage of the performance boost provided by the native DOM querySelectorAll() method. For better performance in modern browsers, use [type="radio"] instead.

Seltsame Begründung. Die bräuchten doch nur vor dem Aufruf von querySelectorAll das ':radio' im String durch '[type="radio"]' ersetzen. Ob's vorhanden ist, müssen sie ja sowieso prüfen, um zu entscheiden, ob querySelectorAll aufgerufen wird oder anderer Code.

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@MudGuard

Seltsame Begründung. Die bräuchten doch nur vor dem Aufruf von querySelectorAll das ':radio' im String durch '[type="radio"]' ersetzen.

Ja, hab ich mich auch gefragt …

Wie auch immer – TL;DR: jQuery ist arschlangsam, wenn man nicht genau weiß, was man da tut.

Und wenn man weiß, was man tut, braucht man kein jQuery.

“Vanilla JS selectors are much faster than libraries. document.getElementById() is about 3.4 times faster than jQuery selectors. @AaronGustafson #aeadenver” —@authorbrandong

LLAP 🖖

[Bernd]

Guten Morgen,

Und wenn man weiß, was man tut, braucht man kein jQuery.

also baust du lieber Funktion händisch nach die jQuery von Haus aus liefert? OK, ist deine Entscheidung, zahlt denn auch dein Kunde wenn du ihm sagst ich bau die Funktion lieber händisch nach, dafür muss ich dir 3 Stunden extra berechnen?

Du kennst doch bestimmt den Spruch "Zeit ist Geld"?

[Gunnar Bittersmann]

@@Bernd

also baust du lieber Funktion händisch nach die jQuery von Haus aus liefert?

Welche Funktion genau soll das sein, die jQuery von Haus aus liefert, JavaScript aber nicht? Viele Dinge, die jQuery einst groß machten (beachte die Vergangenheitsform!) gibt es längst in JavaScript – und das besser als es in jQuery je war.

zahlt denn auch dein Kunde wenn du ihm sagst ich bau die Funktion lieber händisch nach, dafür muss ich dir 3 Stunden extra berechnen?

Muss er nicht, weil gar nicht 3 Stunden extra im Raum stehen. Nicht einmal 3 Minuten.

Du kennst doch bestimmt den Spruch "Zeit ist Geld"?

Ja. Es ist die Zeit der Nutzer, die Geld kostet. Wenn die nämlich die Seite verlassen, weil sie viel zu langsam ist.

“One of the most startling numbers we found in the study was that 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load.” —Mustafa Kurtuldu, Designing for Mobile Performance im Adventskalender 24 ways

LLAP 🖖

[Mitleser]

Wie auch immer – TL;DR: jQuery ist arschlangsam, wenn man nicht genau weiß, was man da tut. “Vanilla JS selectors are much faster than libraries. document.getElementById() is about 3.4 times faster than jQuery selectors. @AaronGustafson #aeadenver” —@authorbrandong

Im Kommentar der verlinkten Seite ist sogar von "It's 34 times faster" die Rede. Kann ich unter Win7 FireFox, Chrome und IE 11 null nachvollziehen. Wenn ich auf der verlinkten Seite 10 Testreihen von "1000 x getElementById" vs "1000 x jQuery" fahre, dann erhalte ich schwankende Ergebnisse.

Ja, getElementById ist da durchweg fixer, mal mehr, mal weniger. Wenn man aber mal die absoluten Werte für die Aufgabe "tausend(!) mal getElementById" betrachtet, stellt sich schon die Frage, was der Vergleich überhaupt soll. Im Chrome (Testsieger, wie zu erwarten) kommt man letztlich zu der Erkenntnis, dass die 1000 Durchläufe z.B. nativ 0,1ms und via jQuery 0,9ms brauchen können.

Das wäre also 9x so schnell! Hammer! Aber letztlich sind es 0,9ms(!) für 1000(!) Durchläufe. Irgendwie fehlt mir da die Relevanz.…

[Rolf B]

Hallo Mitleser,

getElementById war hier nicht die Frage, sondern querySelectorAll("type[radio]") vs $(":radio"). Gibt's dafür auch Vergleiche?

Rolf

[Mitleser]

getElementById war hier nicht die Frage,

Gunnars Link samt Kommentar "arschlangsam" bezog sich darauf.

sondern querySelectorAll("type[radio]") vs $(":radio"). Gibt's dafür auch Vergleiche?

Bau Dir einen. Habe folgendes gemacht, das sollte sich schnell anpassen lassen:

var myTimer = function () {

	var i, none;

	console.time("jQuery");
	for (i = 1; i <= 1000; i++) {
		none = $('#doc').get(0);
	}
	console.timeEnd("jQuery");

	console.time("native");
	for (i = 1; i <= 1000; i++) {
		none = document.getElementById('doc');
	}
	console.timeEnd("native");

}

for (var i = 1; i <= 10; i++) {
	myTimer();
}

[Gunnar Bittersmann]

@@Mitleser

Bau Dir einen. Habe folgendes gemacht, das sollte sich schnell anpassen lassen:

var myTimer = function () {

	var i, none;

	console.time("jQuery");
	for (i = 1; i <= 1000; i++) {
		none = $('#doc').get(0);
	}
	console.timeEnd("jQuery");

	console.time("native");
	for (i = 1; i <= 1000; i++) {
		none = document.getElementById('doc');
	}
	console.timeEnd("native");

}

for (var i = 1; i <= 10; i++) {
	myTimer();
}

Ich traue deinem Vergleich kein bisschen. Eine Schleife, die 1000× dasselbe tut – das sollte die JavaScript-Engine wegoptimieren. Am Ende misst du damit den Zeitunterschied bei einem Schleifendurchlauf, nicht bei 1000.

LLAP 🖖

[Mitleser]

Ich traue deinem Vergleich kein bisschen. Eine Schleife, die 1000× dasselbe tut – das sollte die JavaScript-Engine wegoptimieren. Am Ende misst du damit den Zeitunterschied bei einem Schleifendurchlauf, nicht bei 1000.

Absolute plausible Kritik. Im Gegensatz zu dem von Dir verlinktem Ding aber immer noch besser, als es ohne Beweisführung einfach zu behaupten.

Wir können aber auch gerne ein praxisnäheres Beispiel bauen, was genau einmal z.B. 100 Elemente anhand ihrer ID aus dem Dom fischt.

Schätzt Du, das Ergebnis wird damit relevanter, weil z.B. der Chrome dann nativ 0,003ms statt mittels jQuery 0,010ms braucht?

[Mitleser]

Schätzt Du, das Ergebnis wird damit relevanter, weil z.B. der Chrome dann nativ 0,003ms statt mittels jQuery 0,010ms braucht?

Also. 1000 Elemente dynamisch auf dem von Dir verlinktem Twitterpost erzeugt und danach per Zufallsprinzip (um es besser nachvollziehbar zu halten, Code steht weiter unten, kann 1:1 via Konsole ausgeführt werden) entweder nativ oder via jQuery aus dem DOM gefischt. Chrome bleibt Testsieger, die Proportionen bleiben aber auch im FF / IE 11 vergleichbar. Nativer Zugriff ist grob zwischen 2x und 3x so schnell wie jQuery. Der IE 11 performte am miesesten, braucht bei Ausreißern ca. 3ms mit jQuery und ca. 1,5ms nativ.

Chrome performed bei mir ca. 0,5ms nativ und ca. 1,5ms via jQuery. Wenn ich auf 100 Elemente runtergehe, liegt der Unterschied bei mir an der Messbarkeitsgrenze. Messung erfolgte stets nach frischem Reload der Seite. Your turn!

var elementCount = 1000;

for (var i = 1; i <= elementCount; i++) {
	var elementId = 'testdiv_' + i;
	var newDiv = document.createElement('div'); 
	var newContent = document.createTextNode(elementId); 
	newDiv.appendChild(newContent);
	newDiv.setAttribute('id', elementId);
	document.body.appendChild(newDiv);
}

var testNative = (Math.random() >= 0.5);
var testLabel = testNative ? 'native' : 'jQuery';
var none, elementId;
console.time(testLabel);
for (var c = 1; c <= elementCount; c++) {
	elementId = 'testdiv_' + c;
	if (testNative) {
		none = document.getElementById(elementId);
	}
	else {
		none = $('#' + elementId).get(0);
	}
}
console.timeEnd(testLabel);

[Mitleser]

Ich traue deinem Vergleich kein bisschen. Eine Schleife, die 1000× dasselbe tut – das sollte die JavaScript-Engine wegoptimieren. Am Ende misst du damit den Zeitunterschied bei einem Schleifendurchlauf, nicht bei 1000.

Nachtrag: Das kommt auf die Schleife drauf an. In dem Fall wäre ich mir da nicht so sicher, wie Du. Spätestens, wenn Du einen Reflow auslöst, wird das schwierig mit der Wegoptimierung.

[Rolf B]

Hallo,

jetzt habe ich Gelegenheit zum nachmessen...

Ich traue deinem Vergleich kein bisschen. Eine Schleife, die 1000× dasselbe tut – das sollte die JavaScript-Engine wegoptimieren.

Das lässt sich ebenfalls messen.

Hier mein Test:

let i=0;

for (i=1; i<=100; i++) {
   let ii = i.toString().padStart(3, '0');
   $("body").append("<fieldset id='fs"+ii+"'><label>Input "+ii+"-1<input type='radio' name='rb"+ii+"' value='11'><label>Input "+ii+"-2<input type='radio' name='rb"+ii+"' value='22'><label>Input "+ii+"-3<input type='radio' name='rb"+ii+"' value='33' checked><label>Input "+ii+"-4<input type='radio' name='rb"+ii+"' value='44'></fieldset>")
}

let v1,v2,v3,v4, max=100;
console.time("Empty Loop");
for (i=1; i<max; i++) {
}
console.timeEnd("Empty Loop");

console.time("jQuery :radio");
for (i=1; i<max; i++) {
  v1 = $(":radio[name='rb099']:checked").val();
}
console.timeEnd("jQuery :radio");

console.time("jQuery [type=radio]");
for (i=1; i<max; i++) {
  v2 = $("[type=radio][name='rb099']:checked").val();
}
console.timeEnd("jQuery [type=radio]");

console.time("native");
for (i=1; i<max; i++) {
  let s = document.querySelector("[type=radio][name='rb099']:checked");
  v3 = s.value;
}
console.timeEnd("native");

console.time("nativeAll");
for (i=1; i<max; i++) {
  let s = document.querySelectorAll("[type=radio][name='rb099']:checked");
  v4 = s[0].value;
}
console.timeEnd("nativeAll");

console.log("jq1: " + v1 + ", jq2: " + v1 + ", na1:" + v3 + ", na2:" + v4);

Ausgabe mit max=100:

Empty Loop: 0.01318359375ms
jQuery :radio: 138.073974609375ms
jQuery [type=radio]: 18.42822265625ms
native: 13.638916015625ms
nativeAll: 9.412841796875ms
jq1: 33, jq2: 33, na1:33, na2:33

Ausgabe mit max=1000:

Empty Loop: 0.03173828125ms
jQuery :radio: 658.901123046875ms
jQuery [type=radio]: 107.217041015625ms
native: 92.0048828125ms
nativeAll: 84.259033203125ms
jq1: 33, jq2: 33, na1:33, na2:33

Gemessen mit Chrome 63 unter Windows 7, auf einer virtuellen Maschine unbekannter Leistungsfähigkeit. Die Zeiten können also auch je nach Host-Belastung etwas schwanken.

Man erkennt, dass V8 die Schleifen nicht wegoptimiert. Aber man erkennt auch, dass die Messung sehr unscharf ist, die Zahlen verhalten sich nicht 1:10 für 100 und 1000 Durchläufe. Ich muss das nochmal auf einer nichtvirtuellen Maschine wiederholen, habe ich gerade nicht zur Hand.

Die Erkenntnis ist aber: :radio ist deutlich langsamer als [type=radio], und [type=radio] ist in jQuery unwesentlich langsamer als querySelector.

Merkwürdig finde ich nur, dass querySelectorAll konsistent 10% schneller ist als querySelector. Da ich einen Radio-Button ganz am Ende suche, sollten die beiden in etwa gleich schnell sein.

Das ändert sich, wenn ich rb019 suche, dann bekomme ich bei max=1000 diese Werte:

Empty Loop: 0.032958984375ms
jQuery :radio: 630.801025390625ms
jQuery [type=radio]: 108.5830078125ms
native: 18.47314453125ms
nativeAll: 76.590576171875ms
jq1: 33, jq2: 33, na1:33, na2:33

D.h. querySelector ist im Mittel schneller als querySelectorAll, weil es einfach nach dem 1. Treffer aufhört.

Tjaaa, und der hier

console.time("qid");
for (i=1; i<max; i++) {
  v5 = $("#fs099 input[name=rb099]:checked").val();
}
console.timeEnd("qid");

console.time("nid");
for (i=1; i<max; i++) {
  v6 = document.getElementById("fs099").querySelector("[type=radio]:checked").value;
}
console.timeEnd("nid");

läuft natürlich viel schneller durch 😀. Mit max=1000 die jQuery-Variante in 19ms, die native-Variante in 1,5ms. Hier macht sich der jQuery-Initialaufwand massiv bemerkbar. D.h. die beste Peephole-Optimierung nützt nichts, wenn man den falschen Algorithmus hat. Aber das wussten wir ja schon vorher. Allerdings ist auch document.querySelector("#fs099 [type=radio][name='rb099']:checked") nur minimal langsamer (1,7ms vs 1,5ms) als die nid Version. Die Trennung lohnt also nicht.

Und dass die GANZE Nummer nicht lohnt, wenn man nur einen Radiobutton sucht, ist auch offenkundig. Es wird nur ganz wenige Seiten geben, auf denen sich der Unterschied spürbar bemerkbar macht.

Rolf

[1unitedpower]

jetzt habe ich Gelegenheit zum nachmessen...

Ich traue deinem Vergleich kein bisschen. Eine Schleife, die 1000× dasselbe tut – das sollte die JavaScript-Engine wegoptimieren.

Das lässt sich ebenfalls messen.

Eine Bitte an euch alle, erstellt eure Benchmarks doch bei jsPerf, dann können wir auch damit rumprobieren 😉