Frameworks wie jQuery gehören zu den bekanntesten und weit verbreitetsten Helfer, die auf Websites eingesetzt werden. Das Framework ermöglicht es, schnell und unkompliziert auf HTML-Elemente zuzugreifen und diese zu manipulieren oder per CSS zu gestalten. Ich selbst bin kein großer Freund von solchen Frameworks und versuche, sie – wo immer es geht – zu vermeiden. Das funktioniert nicht immer, ist aber häufig problemlos machbar.
jQuery und Co. und der große Ballast
Gerade jQuery hat sich in den letzten Jahren zu einer Art Schweizer Taschenmesser für JavaScript entwickelt. Das Frameworks bietet unzählige Methoden, Eigenschaften und Ereignisse, von denen die Meisten wohl nur ein Bruchteil benötigen.
Auch wenn jQuery in der aktuellen komprimierten Fassung auf gerade einmal 85 Kilobyte kommt, bliebe ein Großteil des Frameworks in meinen Projekten ungenutzt. Man kann es kleinlich nennen, dass mir 85 Kilobyte solch Kopfzerbrechen bereiten. Aber als Webentwickler ist mir ein schlanker Code, der nur das beinhaltet, was auch tatsächlich gebraucht wird, wichtig.
Jetzt ist jQuery mittlerweile zu einer Art Standard in der Webentwicklung geworden. Daher sind viele andere Frameworks mittlerweile als Plugins für jQuery entwickelt. Will ich diese nutzen, muss ich auch jQuery nutzen. Hier zeigt sich im besonderen Maße, was solche Frameworks für Nachteile mit sich bringen.
Denn letztlich benötige ich jQuery dann nur, um das Plugin nutzen zu können. Da sind mir 85 Kilobyte dann in der Tat zu viel.
Doppelt gemoppelt: Was jQuery kann, kann JavaScript oft auch
Mit der Einführung von HTML5 hat auch JavaScript einen großen Sprung gemacht. Viele Funktionen, die bislang nur per jQuery möglich waren, sind nun auch ebenso einfach als native JavaScript-Methoden vorhanden.
Das gilt zum Beispiel für das Hinzufügen und Entfernen von JavaScript-Klassen. Mit der „classList“-API kannst du dies ähnlich wie in jQuery realisieren.
Eine der wichtigsten Funktionen in jQuery ist die Möglichkeit, per „$()“ auf beliebige Elemente zuzugreifen – und zwar in Anlehnung an CSS-Selektoren. Selbst dieses Alleinstellungsmerkmal von jQuery ist mittlerweile mit der Methode „querySelector()“ in JavaScript aufgegriffen worden.
document.querySelector("ol li").classList.add("new");
Im Beispiel wird allen „<li>“-Elementen, die Kinder eines „<ol>“-Elementes sind, die Klasse „new“ zugewiesen. In jQuery ist ein entsprechender Aufruf kaum kürzer – vor allem aber nicht weniger kompliziert.
$("ol li").addClass("new");
In vielen Fällen benötige ich jQuery also gar nicht, sondern kann mit JavaScript auf ähnlich einfachem Wege arbeiten.
Performance vs. Einfachheit
jQuery und seine weniger bekannten Freunde machen es einem in vielen Fällen sehr viel einfacher, mit JavaScript zu arbeiten. Aber nicht immer ist der einfach Weg auch der Beste – gerade wenn es um die Performance geht.
Denn sowohl die jQuery-Methode „$()“ als auch die JavaScript-Methode „querySelector()“ schneiden in Sachen Performance schlechter ab als die Methoden „getElementsByTagName()“ oder „getElementsByID()“. Denn bei „$()“ und „querySelector()“ wird zunächst der komplette DOM-Baum eines Dokumentes nach entsprechenden zutreffenden Elementen durchsucht.
Die beiden Methoden „getElementsByTagName()“ oder „getElementsByID()“ kommen deutlich schneller ans Ziel. Natürlich sind die letztgenannten Methoden für Entwickler zuweilen mit mehr Aufwand verbunden. Auch hier mag der geringe Unterschied bei der Performance vernachlässigbar sein. Man sollte sich dessen jedoch bewusst sein.
Vorteil: einheitliche Browser-Kompatibilität
Jetzt will ich natürlich auch nicht so tun, als sei jQuery durch und durch überflüssig. Denn es hat ja seinen Grund, warum es immer noch sehr erfolgreich und beliebt ist. Ein Vorteil ist natürlich die einfache Anwendung.
Darüber hinaus haben solche Frameworks natürlich den Vorteil, dass sie eine breite Browser-Kompatibilität mit sich bringen. Während ich bei nativen Methoden immer schauen muss, welcher Browser ab welcher Version sie unterstützt, macht jQuery mir das einfacher.
Denn für jede jQuery-Version weiß ich, welche Browser und Versionen unterstützt werden. Gerade wer für ältere Versionen des Internet Explorers entwickelt, hat mit jQuery in der aktuellen Version die Sicherheit, dass dieser ab Version 9 unterstützt wird.
Und wer ältere Browser noch unterstützen möchte, kann auf ältere Versionen von jQuery zurückgreifen. Das erleichtert die Entwicklung von Websites, da man schon im Vorfeld weiß, welche Browser denn mit an Bord sind.
Frameworks fürs Spezielle
Jetzt bin ich also jemand, der – wenn immer es möglich und sinnvoll ist – auf Frameworks verzichtet. Möglich ist es eigentlich immer. Denn grundsätzlich kann man ja alles selbst in JavaScript programmieren. Nur sinnvoll ist es natürlich nicht immer.
Es gibt natürlich Situationen, in denen der Aufwand, eine komplexe JavaScript-Programmierung selbst zu entwickeln, in keiner Relation zum Ergebnis steht. Wer mit JavaScript zum Beispiel 3D-Animationen erstellen möchte, kann sich natürlich selbst sein eigenes 3D-Framework bauen.
Hier ist es hingegen mehr als sinnvoll, auf ein stabiles und möglichst leichtes Framework zurückzugreifen. In solchen Fällen ist es mir aber immer wichtig, dass dieses Framework nicht auf andere Frameworks wie jQuery aufbaut, sondern unabhängig verwendet werden kann.
Fazit
Natürlich ist die Frage, ob man auf Frameworks setzt oder nicht, durchaus eine ideologische. Denn der Gewinn an Schnelligkeit ist in vielen Fällen marginal. Aber man sollte als Entwickler nicht aus bloßer Bequemlichkeit auf jQuery und Co. zurückgreifen.
Denn natives JavaScript kann häufig all das, was jQuery kann, selbst auch abdecken. Gerade wer für zeitgemäße Browser entwickelt und die Abwärtskompatibilität eh in Grenzen hält, kommt gut ohne dieses Framework aus.
