Spaces. Smartes Cloud Hosting für anspruchsvolle Webprojekte. Loslegen und Spaces testen. Von Mittwald.
Denis Potschien 26. Mai 2017

Framework jQuery: die Vorteile und Nachteile

Frameworks wie jQuery gehö­ren zu den bekann­tes­ten und weit ver­brei­tets­ten Helfer, die auf Websites ein­ge­setzt wer­den. Das Framework ermög­licht es, schnell und unkom­pli­ziert auf HTML-Elemente zuzu­grei­fen und die­se zu mani­pu­lie­ren oder per CSS zu gestal­ten. Ich selbst bin kein gro­ßer Freund von sol­chen Frameworks und ver­su­che, sie – wo immer es geht – zu ver­mei­den. Das funk­tio­niert nicht immer, ist aber häu­fig pro­blem­los mach­bar.

jQuery und Co. und der große Ballast

Gerade jQuery hat sich in den letz­ten Jahren zu einer Art Schweizer Taschenmesser für JavaScript ent­wi­ckelt. Das Frameworks bie­tet unzäh­li­ge Methoden, Eigenschaften und Ereignisse, von denen die Meisten wohl nur ein Bruchteil benö­ti­gen.

Auch wenn jQuery in der aktu­el­len kom­pri­mier­ten Fassung auf gera­de ein­mal 85 Kilobyte kommt, blie­be ein Großteil des Frameworks in mei­nen Projekten unge­nutzt. Man kann es klein­lich nen­nen, dass mir 85 Kilobyte solch Kopfzerbrechen berei­ten. Aber als Webentwickler ist mir ein schlan­ker Code, der nur das beinhal­tet, was auch tat­säch­lich gebraucht wird, wich­tig.

Jetzt ist jQuery mitt­ler­wei­le zu einer Art Standard in der Webentwicklung gewor­den. Daher sind vie­le ande­re Frameworks mitt­ler­wei­le als Plugins für jQuery ent­wi­ckelt. Will ich die­se nut­zen, muss ich auch jQuery nut­zen. Hier zeigt sich im beson­de­ren Maße, was sol­che Frameworks für Nachteile mit sich brin­gen.

Denn letzt­lich benö­ti­ge ich jQuery dann nur, um das Plugin nut­zen zu kön­nen. 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 bis­lang nur per jQuery mög­lich waren, sind nun auch eben­so ein­fach als nati­ve JavaScript-Methoden vor­han­den.

Das gilt zum Beispiel für das Hinzufügen und Entfernen von JavaScript-Klassen. Mit der “classList”-API kannst du dies ähn­lich wie in jQuery rea­li­sie­ren.

Eine der wich­tigs­ten Funktionen in jQuery ist die Möglichkeit, per “$()” auf belie­bi­ge Elemente zuzu­grei­fen – und zwar in Anlehnung an CSS-Selektoren. Selbst die­ses Alleinstellungsmerkmal von jQuery ist mitt­ler­wei­le mit der Methode “querySelector()” in JavaScript auf­ge­grif­fen wor­den.

document.querySelector("ol li").classList.add("new");

Im Beispiel wird allen “<li>”-Elementen, die Kinder eines “<ol>”-Elementes sind, die Klasse “new” zuge­wie­sen. In jQuery ist ein ent­spre­chen­der Aufruf kaum kür­zer – vor allem aber nicht weni­ger kom­pli­ziert.

$("ol li").addClass("new");

In vie­len Fällen benö­ti­ge ich jQuery also gar nicht, son­dern kann mit JavaScript auf ähn­lich ein­fa­chem Wege arbei­ten.

Performance vs. Einfachheit

jQuery und sei­ne weni­ger bekann­ten Freunde machen es einem in vie­len Fällen sehr viel ein­fa­cher, mit JavaScript zu arbei­ten. Aber nicht immer ist der ein­fach Weg auch der Beste – gera­de wenn es um die Performance geht.

Denn sowohl die jQuery-Methode “$()” als auch die JavaScript-Methode “querySelector()” schnei­den in Sachen Performance schlech­ter ab als die Methoden “getElementsByTagName()” oder “getElementsByID()”. Denn bei “$()” und “querySelector()” wird zunächst der kom­plet­te DOM-Baum eines Dokumentes nach ent­spre­chen­den zutref­fen­den Elementen durch­sucht.

Die bei­den Methoden “getElementsByTagName()” oder “getElementsByID()” kom­men deut­lich schnel­ler ans Ziel. Natürlich sind die letzt­ge­nann­ten Methoden für Entwickler zuwei­len mit mehr Aufwand ver­bun­den. Auch hier mag der gerin­ge Unterschied bei der Performance ver­nach­läs­sig­bar sein. Man soll­te sich des­sen jedoch bewusst sein.

Vorteil: einheitliche Browser-Kompatibilität

Jetzt will ich natür­lich auch nicht so tun, als sei jQuery durch und durch über­flüs­sig. Denn es hat ja sei­nen Grund, war­um es immer noch sehr erfolg­reich und beliebt ist. Ein Vorteil ist natür­lich die ein­fa­che Anwendung.

Darüber hin­aus haben sol­che Frameworks natür­lich den Vorteil, dass sie eine brei­te Browser-Kompatibilität mit sich brin­gen. Während ich bei nati­ven Methoden immer schau­en muss, wel­cher Browser ab wel­cher Version sie unter­stützt, macht jQuery mir das ein­fa­cher.

Denn für jede jQuery-Version weiß ich, wel­che Browser und Versionen unter­stützt wer­den. Gerade wer für älte­re Versionen des Internet Explorers ent­wi­ckelt, hat mit jQuery in der aktu­el­len Version die Sicherheit, dass die­ser ab Version 9 unter­stützt wird.

Und wer älte­re Browser noch unter­stüt­zen möch­te, kann auf älte­re Versionen von jQuery zurück­grei­fen. Das erleich­tert die Entwicklung von Websites, da man schon im Vorfeld weiß, wel­che Browser denn mit an Bord sind.

Frameworks fürs Spezielle

Jetzt bin ich also jemand, der – wenn immer es mög­lich und sinn­voll ist – auf Frameworks ver­zich­tet. Möglich ist es eigent­lich immer. Denn grund­sätz­lich kann man ja alles selbst in JavaScript pro­gram­mie­ren. Nur sinn­voll ist es natür­lich nicht immer.

Es gibt natür­lich Situationen, in denen der Aufwand, eine kom­ple­xe JavaScript-Programmierung selbst zu ent­wi­ckeln, in kei­ner Relation zum Ergebnis steht. Wer mit JavaScript zum Beispiel 3D-Animationen erstel­len möch­te, kann sich natür­lich selbst sein eige­nes 3D-Framework bau­en.

Hier ist es hin­ge­gen mehr als sinn­voll, auf ein sta­bi­les und mög­lichst leich­tes Framework zurück­zu­grei­fen. In sol­chen Fällen ist es mir aber immer wich­tig, dass die­ses Framework nicht auf ande­re Frameworks wie jQuery auf­baut, son­dern unab­hän­gig ver­wen­det wer­den kann.

Fazit

Natürlich ist die Frage, ob man auf Frameworks setzt oder nicht, durch­aus eine ideo­lo­gi­sche. Denn der Gewinn an Schnelligkeit ist in vie­len Fällen mar­gi­nal. Aber man soll­te als Entwickler nicht aus blo­ßer Bequemlichkeit auf jQuery und Co. zurück­grei­fen.

Denn nati­ves JavaScript kann häu­fig all das, was jQuery kann, selbst auch abde­cken. Gerade wer für zeit­ge­mä­ße Browser ent­wi­ckelt und die Abwärtskompatibilität eh in Grenzen hält, kommt gut ohne die­ses Framework aus.

Denis Potschien

Denis Potschien

Denis Potschien ist seit 2005 freiberuflich als Kommunikationsdesigner tätig, seit Anfang 2010 im Kreativkonsulat in Iserlohn, einem Büro für Gestaltung und Kommunikation. Dort betreut er kleine und mittelständische Unternehmen ebenso wie kommunale Körperschaften und Organisationen aus Südwestfalen und dem Ruhrgebiet. Als Webdesigner und -entwickler gehören HTML5 und CSS3 zu seinen Kernthemen, weshalb er dazu 2013 ein Buch geschrieben hat. „Pure HTML5 und CSS3“ richtet sich an alle, die Vorkenntnisse haben, sich aber bisher mit HTML5 und CSS3 nicht oder nur am Rande beschäftigt haben.

6 Kommentare

  1. Hallo,

    ich habe nur ein paar klei­ne Kritikpunkte zu dei­ner Schreibweise: Viel zu vie­le Sätze fan­gen mit “Denn” an und “natür­lich” ver­wen­dest du auch oft in 2 oder 3 Sätzen nach­ein­an­der. Weiß nicht wie­so, aber mich per­sön­lich hat das ganz leicht gestört.

    Ansonsten ist der Artikel top.

  2. Klar, eine schlan­ke Programmierung soll­te natür­lich ohne Frameworks aus­kom­men. Dennoch den­ke ich, dass die Vorteile von jQuery über­wie­gen (auch wenn es von Version zu Version stets ein wenig grös­ser wird).

    Habe gera­de mal bei GTMetrix nach­ge­schaut: “The average num­ber of Requests is 87”. Auch kom­ple­xe Websites las­sen sich ohne wei­te­res mit unter 10 Requests rea­li­sie­ren – einer mehr lässt sich da schon ver­schmer­zen.

    Hinzu kommt, dass JS im Browser aus­ge­führt wird. Selbst jedes Smartphone ver­fügt heu­te über genü­gend Power eine Seite voll­stän­dig ren­dern zu kön­nen bevor der Besucher Maus/Finger ein­setzt.

    Mich ner­ven Seiten die lang­sam laden oder deren Inhalte stän­dig ver­sprin­gen genau­so wie alle Anderen auch. Die Schuld dar­an liegt jedoch nicht bei jQuery.

  3. Dem hier Gesagten ist mei­ner Meinung nach nicht mehr viel hin­zu­zu­fü­gen. Ausser viel­leicht, daß das Thema Browser-Kompatibilität in Bezug auf die Verwendung von jQuery zum Glück immer unwich­ti­ger wird. Auch und beson­ders bei DOM-Manipulationen gibts fast kei­ne Browser mehr, die “nor­ma­les” Javascript nicht rich­tig ver­ste­hen wol­len.
    Und auch die wei­ter unten monier­te “Lösung”, jQuery über ajax.googleapis.com ein­zu­bin­den, ändert nichts dar­an, daß der gan­ze jQuery-Müll vom Browser erst ver­ar­bei­tet wer­den muß, egal ob er im Cache ist oder nicht.
    Und, – auch wenn’s im Artikel bereits erwähnt wur­de – bei zeit­kri­ti­schen Anwendungen ver­bie­tet sich die Verwendung von jQuery ohne­hin von selbst…

  4. Bindet man jQuery über die ajax.googleapis.com ein, liegt die JS-Datei doch bei jedem User bereits im Browsercache. Die Datei muss also nicht gela­den wer­den. Das gan­ze ist also als Performance Vorteil zu wer­ten und nicht als Nachteil.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.