Hallo,
Bibliotheken müssen, wie du geschrieben hast, alle Eventualitäten abdecken. Das erfordert einen recht großen Aufwand für der Browser, Informationen zu ermitteln, die der Seitenersteller eigentlich weiß. Wenn ich z.B. mittels $-Funktion ein Element anspreche, ist es toll, dass die Selection-Engine selbst ermittelt, ob der Parameter eine ID, ein Name, ein Tagname, ein Classname etc. ist. Toll. Der Seitenersteller sollte dieses auch wissen. So muss der Browser jedes mal ermitteln, was bei der Seitenerstellung eigentlich schon bekannt ist.
Das nennt sich Flexibilität und ist eine gute Sache. Das Gegenteil hieße, sämtliche *aktuellen* Parameter hart zu kodieren und die Umsetzung auf die *gegenwärtigen* Anforderungen zuzuschneiden. Dann schreibt man natürlich nur so viel Code wie gerade nötig und dieser kann auf die *gegenwärtigen* Anwendungsfälle optimiert sein, aber Änderungen und Erweiterungen sind umso aufwändiger.
Es ist ferner sinnvoll, allgemeine APIs zu verwenden. Nachdem wir uns mit document.links, document.forms, document.layers, document.all, getElementById, getElementsByTagName, getElementsByClassName usw. herumgeplagt haben, sind wir heute bei querySelector(All) und jQuery-artigen APIs angekommen. Diese APIs geben einem die nötige Abstraktheit und Kürze, um Logik lesbar und wartbar auszudrücken, z.B. $('.foo').on('mouseenter', '.bar', function(event) { … })
.
Aber das scheint in der SW-Entwicklung inzwischen normal zu sein: Zeiteinsparung beim Programmierer zu lasten der CPU-Zeit beim User.
JavaScript ist mittlerweile so schnell, dass selbst dicke Bibliotheken wie jQuery keinen merklichen Overhead erzeugen. jQuery besteht aus einem Haufen Funktionen, Objekten und Listenoperationen. So etwas frisst ein moderner JIT-Compiler zum Frühstück.
DOM-Queries und DOM-Operationen wirken sich generell negativ auf die Performance aus. Es ist zudem schwierig, bei Animationen 60fps hinzubekommen. I/O-Operationen sind ebenfalls »teuer«.
Eine Abstraktion wie jQuery ist jedoch kein Performance-Problem mehr, jQuery ist selbst auf Teufel komm raus optimiert worden. jQuery hilft einem eher weiter, z.B. indem intern DocumentFragments verwendet werden und Event-Delegation einfach möglich ist. Es ist in der Summe einfacher, mit jQuery performanten Code zu schreiben als ohne.
Wer sich professionell oder als ambitionierter Amateur im WWW-Geschäft bewegt, sollte meiner Meinung nach neben den Bibliotheken unbedingt auch die Grundlagen kennen. Sonst bewegt man sich auf verdammt dünnen Eis.
Fragt sich was Grundlagen sind. Als Grundlagen sehe ich das, was ich z.B. in meiner JavaScript-Dokumentation beschreibe. Vieles davon läuft darauf hinaus, dass man sich zur sicheren Anwendung dieser Grundlagen am besten eine vernünftige Bibliothek sucht, die ausgereift, gut dokumentiert und automatisiert getestet ist.
Dann gibt es noch die Grundlagen, die jQuery und Co. selbst einsetzen. Das sind fiese Details, Fallstricke und Browserbugs, die man kennen und behandeln muss, um eine robuste Software zu schreiben. Fast niemand kennt diese Grundlagen. Man kann sie als Einzelperson gar nicht vollständig kennen. Zum Glück *muss* sie heutzutage nicht mehr jeder kennen, weil es große Bibliotheken gibt, in denen tausende Leute ihr Wissen bündeln.
Mathias