Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Entwicklung & Design

Natives JavaScript statt jQuery – So machst du deine Webprojekte schlanker

    Natives JavaScript statt jQuery – So machst du deine Webprojekte schlanker

jQuery ist klasse, aber nicht immer die beste Lösung. (Screenshot: jquery.com)

Die JavaScript-Bibliothek jQuery erleichtert uns zweifellos das Leben als Entwickler. Der enorme Funktionsumfang und die vergleichsweise hohe Dateigröße stehen bei manchen Projekten aber nicht im Verhältnis zum Nutzen. Wir zeigen dir, wie du typische jQuery-Aktionen mit JavaScript ersetzt.

jQuery-Funktionen mit der JavaScript-API des Browsers realisieren

Die jQuery-Bibliothek ist unbestritten eines der beliebtesten JavaScript-Frameworks und erleichtert täglich vielen Entwicklern die Arbeit. Kein Wunder, dass mittlerweile „beinahe jede“ Webseite das Framework einsetzt und alle Funktionen mit Hilfe der jQuery-Bibliothek realisiert. Die API ist einfach zu bequem.

Dabei bringt jQuery Unmengen von Funktionen mit – viele davon werden meist gar nicht in den Projekten genutzt. Dennoch muss die komplette Bibliothek zu den Clients übertragen werden. Je nach Version (komprimiert oder Entwicklungsversion) und Servereinstellung (Kompression, Cache) muten wir unseren Besuchern so bis zu 270 Kilobyte zu, noch bevor auch nur ein Byte unserer eigentlichen Inhalte übertragen wurde. Dabei sind viele der jQuery-Funktionen, die für die tägliche Arbeit benutzt werden müssen, unkompliziert mit der nativen JavaScript-API des Browsers zu realisieren. Einige native Äquivalente zu jQuery-Funktionen, haben wir für dich zusammengestellt.

Ohne jQuery Elemente mit JavaScript selektieren

// jQuery
var els = $('.el');
// Nativ
var els = document.querySelectorAll('.el');
// jQuery Ersatz
var $ = function (el) {
return document.querySelectorAll(el);
}
var els = $('.el');

Elemente erzeugen

// jQuery
var newEl = $('<div/>');
// Nativ
var newEl = document.createElement('div');

Event Listener

// jQuery
$('.el').on('event', function() {});
// Nativ
[].forEach.call(document.querySelectorAll('.el'), function (el) {
el.addEventListener('event', function() {
}, false);
});

Attribute holen und setzen

// jQuery
$('.el').filter(':first').attr('key', 'value');
$('.el').filter(':first').attr('key');
// Nativ
document.querySelector('.el').setAttribute('key', 'value');
document.querySelector('.el').getAttribute('key');

Klassen hinzufügen, entfernen und togglen

// jQuery
$('.el').addClass('class');
$('.el').removeClass('class');
$('.el').toggleClass('class');
// Nativ
document.querySelector('.el').classList.add('class');
document.querySelector('.el').classList.remove('class');
document.querySelector('.el').classList.toggle('class');

jQuery.append();

// jQuery
$('.el').append($('<div/>'));
// Nativ
document.querySelector('.el').appendChild(document.createElement('div'));

jQuery.clone();

// jQuery
var clonedEl = $('.el').clone();
// Nativ
var clonedEl = document.querySelector('.el').cloneNode(true);

jQuery.remove();

// jQuery
$('.el').remove();
// Nativ
remove('.el');
function remove(el) {
var toRemove = document.querySelector(el);
toRemove.parentNode.removeChild(toRemove);
}

jQuery.parent();

// jQuery
$('.el').parent();
// Nativ
document.querySelector('.el').parentNode;

jQuery.prev(); und jQuery.next();

// jQuery
$('.el').prev();
$('.el').next();
// Native
document.querySelector('.el').previousElementSibling;
document.querySelector('.el').nextElementSibling;

AJAX-Anfragen

// jQuery
$.get('url', function (data) {
});
$.post('url', {data: data}, function (data) {
});
// Nativ
// get
var xhr = new XMLHttpRequest();
xhr.open('GET', url);
xhr.onreadystatechange = function (data) {
}
xhr.send();
// post
var xhr = new XMLHttpRequest()
xhr.open('POST', url);
xhr.onreadystatechange = function (data) {
}
xhr.send({data: data});

Weitere Quellen zum Thema jQuery und JavaScript

Das sind nur einige Äquivalente von JavaScript-Funktionen, die die jQuery-API ersetzen kann. Im Prinzip ist es selbstverständlich möglich, die komplette Funktionalität durch natives JavaScript zu ersetzen. Hier gilt es aber wie immer, sich zwischen Kosten und Nutzen beziehungsweise Dateigröße und Zeitersparnis zu entscheiden. Nicht zuletzt ist die Cross-Browser-Kompatibilität ein wichtiger Faktor, warum ein Framework wie jQuery trotz JavaScript zum Einsatz kommen sollte.

In der „MDN API Reference“ kannst du viele weitere Informationen zur nativen JavaScript-API finden. Bei Microjs findest du schlanke Frameworks als Alternative zu jQuery.

via blog.romanliutikov.com

Finde einen Job, den du liebst zum Thema JavaScript, Webdesign

10 Reaktionen
Thytos
Thytos

Ich habe bei vielen Projekten immer wieder angefangen, auf jQuery zu verzichten, nur um schließlich doch jedes Mal festzustellen, dass es keinen Sinn hat, das zu tun.
jQuery ist bis zum Limit optimiert, hat extrem breiten Browsersupport, unterstützt die Wartbarkeit dank lesbaren Codes, ist kleiner als so manche Bilddatei, und wenn man es von einem CDN lädt, sofort da.
Wenn man mehr als nur ein paar Zeilen Code braucht, ist es einfach nicht sinnvoll, auf Bibliotheken wie jQuery zu verzichten. Man würde sie dann im Grunde nur neu schreiben — allerdings ohne die vielen Optimierungen, die über Jahre in jQuery geflossen sind.

Antworten
Moritz

Interessanter Beitrag. Unsere Entwickler sehen im Nativen JavaScript wenig Vorteile und haben das in unserem Blog mal zusammengefasst:

http://blog.softwaredemo.de/2014/02/04/natives-javascript-statt-jquery-ist-weniger-wirklich-mehr/

Antworten
Dani Belz

Ich will mal etwas provozierend die These in den Raum stellen, dass es fast schon belustigend wirkt, in Zeiten von Webdesigns mit großflächigen Hintergrundbildern oder sogar Hintergrundvideos resp. animated GIFs bei 95 KB (für JQuery 1.11.0 minimiert) optimieren zu wollen... =)

Antworten
Dani Belz

Scheint wohl grad ein Hype zu sein =)
Eine noch umfangreichere Sammlung findet Ihr hier (zum Bookmarken):
http://youmightnotneedjquery.com/

Antworten
Olaf

Stimme Frank zu. Die Beispiele oben funktionieren auch nicht alle in alle Browsern, vor allem nicht in Älteren (z.B. document.querySelectorAll). Außerdem produzieren sie im Falle des fehlenden Elementes Fehlermeldungen was die Javascript-Ausführung abbricht. jQuery ignoriert diese. Und vor allem das Erstellen/Bearbeiten von DOM-Objekten ist oben im Beispiel nur sehr verkürzt (ein leeres Div) dargestellt. Wenn man Attribute und Inhalte dazu tut, wird es in nativem Javascript doch sehr schnell umfangreich und fehleranfälliger. Deshalb greift man ja zu Bibliotheken, die das vereinfachen.

Antworten
ewfwef
ewfwef

eher nicht. die zeit der universalframeworks/libraries ist vorbei. der trend geht in richtung microjs.

Antworten
Ludwig
Ludwig

Da wäre doch mal Zepto.js eine Lösung...

Antworten
michsch
michsch

Grundsätzlich ist der Artikel natürlich nicht falsch. jQuery bietet aber zudem den Vorteil, dass es besser mit Projekten vereinbar ist, die dynamisch wachsen. Für ein wenig JavaScript ist die native Lösung sicherlich der richtige Weg. Hier lohnt sich auch ein Blick auf kleine Bibliotheken, wie beispielsweise minifiedjs.com, die mit weniger als 8kb echte Leichtgewichte sein können. Sehr schön sind auch Plugins, die so entwickelt werden, dass sie über einen Adapter mit mehreren Bibliotheken oder auch nativ nutzbar sind. History.js ist dafür ein gutes Beispiel. Natürlich ist das in der Entwicklung aufwändiger, weil man noch einen zusätzlichen Layer, den Adapter, benötigt.

Antworten
tchvj
tchvj

Ersetze javascript-api durch dom-api. Is fehlt noch der hinweis, das queryselectorall kein array zurück liefert.

Antworten
Frank

Das ist halt wie im richtigen Leben die Medaille mit zwei Seiten.
Wenn man nur eine kleine Funtkion von jQuery braucht, scheint es übertrieben zu sein, ein Framework zu installieren, dann passt der Artikel zu dem Fall.
Wenn aber im Laufe der Arbeit mehr Wünsche dazu kommen (meist von Kunden), man könnte ja noch dieses und jenes machen, ist es mit jQuery Framework natürlich leichter* oder schneller, das umzusetzen als alles nativ neu zu programmieren.
Prinzipiell finde ich es aber gut, beides zu können, ein Framework wie jQuery und die native Programmierung.
Ich entwickle bei PHP ja auch auf CMS (quasi das Framework) und native Projekte, je nachdem was günstiger oder geeigneter erscheint.
Abhängigkeiten von Frameworks sind schlecht, also wenn man nicht mehr ohne sie etwas zustande bringt. Dann kommt es schnell zu Verschlimmbesserungen durch übertriebenen Einsatz von Frameworks (finde ich vor allem im CSS so). Darum finde ich auch den Artikel gut, denn es muss nicht immer jQuery sein, wenn man es auch ohne kann.

* Leichter geht es mit Frameworks wie Jquery auch nicht immer, wenn eine vorgefertige Funktion oder APP absolut nicht das machen will oder kann, was man braucht, und man dann das System austricksen muss, damit es doch irgendwie geht. Am Ende stellt sich dann die Frage, wäre es ohne Framework nicht vielleicht doch leichter gewesen.

Antworten

Melde dich mit deinem t3n-Account an oder fülle die unteren Felder aus.

Abbrechen