„VanillaJS is the lowest-overhead, most comprehensive framework I've ever used.“Jeder
Wahrscheinlich wird kein Framework so häufig eingesetzt wie VanillaJS, und das zu Recht. Denn vanilla.js ist in der maximalen Größe nur 0.02 Kilobyte groß – gzipped.
VanillaJS: Unglaublich klein, unglaublich schnell
Und VanillaJS ist nahezu unbegrenzt erweiterbar: Ihr könnt VanillaJS mit den Plugins Backbone.js, Angular.js, Dojo, jQuery und Mootools beliebig erweitern. VanillaJS erlaubt Entwicklern sprichwörtlich unlimitierte Möglichkeiten. Möglich ist das unter anderem, da VanillaJS bereits im Browser verarbeitet werden kann, bevor überhaupt ein Request an einen Server gesendet wurde. Aber das ist nicht alles: VanillaJS ist unglaublich schnell. Die jQuery-Bibliothek ist in der Lage 350.557 IDs pro Sekunde aufzurufen – das ist verschwinden gering, zu den unglaublichen 12.137.211 IDs die VanillaJS in der selben Zeit abfragen kann.
Implementierung mit VanillaJS
Für einen direkten Vergleich haben wir euch Code-Snippets vorbereitet damit ihr sehen könnt wie VanillaJS im Vergleich zu jQuery aussieht:
| jQuery | VanillaJS |
|---|---|
| $(document).ready(function() { // code… }); | document.addEventListener("DOMContentLoaded", function() { // code… }); |
| var divs = $("div"); | var divs = document.querySelectorAll("div"); |
| var newDiv = $(""); | var newDiv = document.createElement("div"); |
| newDiv.addClass("foo"); | newDiv.classList.add("foo"); |
| newDiv.toggleClass("foo"); | newDiv.classList.toggle("foo"); |
| $("a").click(function() { // code… }) | [].forEach.call(document.querySelectorAll("a"), function(el) { el.addEventListener("click", function() { // code… }); }); |
| $("body").append($("")); | document.body.appendChild(document.createElement("p")); |
| $("img").filter(":first").attr("alt", "My image"); | document.querySelector("img").setAttribute("alt", "My image"); |
| var parent = $("#about").parent(); | var parent = document.getElementById("about").parentNode; |
| var clonedElement = $("#about").clone(); | var clonedElement = document.getElementById("about").cloneNode(true); |
| $("#wrap").empty(); | var wrap = document.getElementById("wrap"); while(wrap.firstChild) wrap.removeChild(wrap.firstChild); |
| if($("#wrap").is(":empty")) | if(!document.getElementById("wrap").hasChildNodes()) |
| var nextElement = $("#wrap").next(); | var nextElement = document.getElementById("wrap").nextSibling; |
Fazit: Unglaubliches Framework, das völlig unterschätzt wird
Ihr merkt schon. Bei VanillaJS handelt es sich um nicht anderes als um reines JavaScript. VanillaJS ist ein Gag. Das Ziel dahinter ist es, darauf aufmerksam zu machen, ob wirklich eine 90-Kilobyte-Library verwendet werden muss um einen einfachen Fade-In-Effekt zu realisieren. Aufgrund dessen ist die vanilla.js-Datei auch leer, wenn ihr sie öffnet – egal welche Features ihr ausgewählt habt. Trotzdem sollte einem klar werden, dass JavaScript durchaus auch einige Performance-relevante Vorteile hat, die meistens ungenutzt bleiben, wenn ihr euch gegen VanillaJS – also reines JavaScript – entscheidet. Schreibt ihr mit VanillaJS?
Bitte beachte unsere Community-Richtlinien
@Mario Janschitz Wir warten immer noch alle gespannt auf deinen Fade in einer Zeile. Du willst doch jetzt nicht kneifen oder ? :)
AntwortenEs fehlt der hinweis , dass domcontentloaded, classlist, addeventlistener nicht im ie8 unterstützt werden. Classlist auch nicht im ie9.
AntwortenDer Artikel erklärt, dass VanillaJS nichts anderes ist als JavaScript. Nicht mehr, nicht weniger :)
AntwortenIch verstehe ja dein eigentliches Ansinnen des Artikels, allerdings ist der Artikel einfach zu eng gefasst um das Thema entsprechend rüberzubringen. Dementsprechend kommen hier auch zahlreiche Kommentare, die die Aussage anzweifeln, bzw. zu einem differenzierterem Blick "aufrufen", da es eben kein schwarz/weiß, kein "nur 'VanillaJS'"/"nur jQuery" gibt.
Im einfachsten Fall kann man natürlich sagen, dass jQuery übertrieben ist wenn man nur einen Fade-Effekt einbauen will. Das ist eine simple Aussage und der kann man zustimmen.
Man muss hier aber weiter denken: In welchen Browsern soll der Fade-Effekt laufen? Was wünscht hier der "Kunde"? (Wenn Prinzipien wie Progressive Enhancement oder Graceful degradation nicht "gelten") Was soll langfristig mit der Website gemacht werden? Wird sie erweitert, angepasst, verändert, …?
Wie viel Code benötige ich, um in allen diesen Browsern den Effekt umsetzen zu können? Kann ich zu CSS-Transitions greifen? Muss die Animation auch in reinem JS programmiert sein? Welche Events funktionieren in welchem Browser nicht, oder anders?
So kann sich sehr schnell das minifizierte jQuery (wie gesagt, 33kb) rentieren.
Der Artikel erklärt, dass VanillaJS nichts anderes ist als JavaScript. Nicht mehr, nicht weniger :)
Du schreibst aber, dass VannilaJS "von allen Browsern" unterstützt wird. Gemessen an den Code-Beispielen ist das so nicht richtig. Wie viele vor mir schon schrieben, wurde jQuery ursprünglich mal entwickelt, um die verschiedensten Browser auf ein gemeinsames Niveau zu heben. Mit reinem JS hat man je Browser und Version unterschiedlichste Niveuas, wen auch bei aktuellen Versionen inzwischen einen sehr großen gemeinsamen Nenner.
JavaScript wird grundlegend untersützt. Genauso wie HTML oder CSS. Dass es trotzdem andere Interpretionen bei den Browser-Herstellern ist davon unabhängig. Der Browser versteht die Sprachen. Falsch wäre es gewesen wenn ich geschrieben hätte, dass jeder Browser JavaScript gleich ausgibt. Habe ich aber nicht.
Davon abgesehen geht es im Kontext darum, dass man VanillaJS im Gegensatz zu Frameworks nicht herunterladen muss -> weil JavaScript von jedem Browser verstanden wird. Ich denke ich wiederhole mich :)
Und wie sich unschwer an den Kommentaren erkennen lässt, schaffst du es dennoch nicht, deinen Punkt, welcher auch immer das sein soll, zu vermitteln. Erzeugen die Artikel von deinen Kollegen die selbe Art von Feedback? Ich finde du hast da persönlich eine ziemliche Alleinstellung mit deinen nicht selten unkompletten Artikeln. Leider frisst T3N das alles, meistens sogar ohne proofreading. Schade eigentlich.
Bibliotheken wie z.B. Jquery nehmen einem viel Arbeit in Bezug auf Browser- und Platform-kompatibiliät ab.
AntwortenJa, wenn man nur wenig Code hat, ist pures Javascript schneller und kleiner.
Allerdings sieht das bei einer Seite mit einigen der beliebten Features wie slider, Akkordion ... dann ganz anders aus. Abgesehen vom Programmieraufwand spart man mit Jquery/ExtJS und Co. dann durchaus auch einiges an Code ein.
Und wenn man sich die Ladezeiten anschaut, so spielen die Javascript-Dateien bei optimierten Versionen (in wenige Dateien zusammengefasst) gegenüber den Bildern oder gar Mediendateien keine Rolle!
Finde ich ehrlich gesagt ziemlich reißerisch die Überschrift. Klar kann man alles in purem JS machen. jQuery mappt ja auch nur eigene Funktionen auf Standard-JS. Aber hier kommt es auf die Wartbarkeit und vor allem Effizienz an. jQuery minified auf einem schnellen (eigenen) CDN steht unnötig komplexen und meist schwer lesbaren JS Code gegenüber. In der Praxis trifft man die Entscheidung, ob man eine Woche dranhängt oder mit jQuery ein paar KB Overhead in Kauf nimmt.
AntwortenErklärt man dem Kunden dann, dass der Code zigfach länger ist, es mehrere Tage länger gedauert hat und dadurch deutlich teuerer wurde, wir aber immerhin 60kb an Daten gespart haben?
Wenn Konzerne wie Apple, Facebook und Amazon 200 Entwickler hat die den ganzen Tag Däumchen drehen, dann ist klar das eigener Code auf Basis von purem JS entwickelt wird. Das macht aber rein wirtschaftlich schon gar keinen Sinn, wenn wir hier von Agenturen und Webentwicklern reden, die auf Auftragsbasis arbeiten.
Du willst ernsthaft behaupten, dass Firmen wie Apple, Facebook und Amazon nicht effizient arbeiten müssen? Wie kommst du zu diesem Schluss? Ich halte das für kompletten Blödsinn.
Du schreibst von Wartbarkeit. Wie sieht denn der typische mit jQuery zusammengeklöppelte Code aus? Was ich bisher gesehen habe war zum schrecklich, so viel schlechten Code findest du bei reinem Javascript nicht. Mag sein, dass die Einstiegshürde höher liegt, aber das kann auch von Vorteil sein. Ich glaube die großen Firmen die auf reines Javascript setzen wissen ganz genau warum sie das tun.
AntwortenNein, ich denke du hast das falsch verstanden. Ich meine damit, dass es bei großen Firmen mit entsprechender Man-Power sicher lohnt, in eigenen Code (natives JS um beim Artikel zu bleiben) zu investieren. Besonders größere Firmen sind ungerne auf externe Bibliotheken angewiesen um Abhängigkeiten abzubauen. Wenn man die Ressourcen hat, schön und gut. Das trifft aber auf die meisten Startups oder mittelständischen Unternehmen nicht oder nur in sehr geringem Maße zu.
Ich rede von Wartbarkeit im Sinne vom Verstehen und Erweitern von "fremdem" Code. Code sollte so geschrieben sein, dass man nach kurzem Lesen weiß worum es geht.
Sieh dir doch bitte einfach die Übersicht oben an. Willst du ernsthaft behaupten, der native JS Code in der linken Spalte ist lesbarer, kürzer, und vor allem nachvollziehbarer, wenn man sich mal ein JS-Skript mit mehreren hundert Zeilen anschaut?
Egal ob jQuery oder natives JS - jeder Code kann lesbar oder schrecklich sein. Aber ein ordentlich geschriebenes Stück jQuery ist mit Sicherheit leichter verständlich und damit auch wartbar als natives JS. Hierzu empfehle ich das Buch "The Art of Readable Code". Man kann jeden Code versauen, das gebe ich zu. Aber die grundlegenden Ansätze sind bei Frameworks/Bibliotheken schon übersichtlicher als alles was nativ so geht (siehe nochmals den Vergleich oben in der Tabelle!)
Ich denke hier muss man stark auf die Ausgangslage schauen. Ich habe schon zigfach Projekte auf dem Tisch gehabt, in denen bestehender JS-Code erweitert, umgebaut oder gefixt werden musste. Vielleicht hattest du bisher bei sowas Glück, aber es war bisher immer ein deutlicher Zeitgewinn wenn ein Framework oder eine (bekannte) Bilbliothek benutzt wurde.
Nochmal: Große Unternehmen haben große Abteilungen für sowas, es wird entsprechend dokumentiert und man hat die Entwickler meist greifbar, wenn Fragen oder Probleme auftauchen. Das ist aber (besonders auf die Code-Doku bezogen) absolut nicht der Regelfall im Tagesgeschäft kleinerer und mittlerer Firmen.
Kurze Korrektur:
"...der native JS Code in der linken Spalte ist lesbarer, kürzer, und vor allem nachvollziehbarer..."
sollte natürlich heißen "der native JS Code in der rechten Spalte ist lesbarer, kürzer, und vor allem nachvollziehbarer..."
Ich denke nicht, dass es da um Manpower geht, du brauchst nur fähige Entwickler die Javascript beherrschen und nicht nur 3 mal in die Doku von jQuery geschaut haben.
Ja Bibliotheken vereinfachen teilweise etwas sperrige Javascript bzw. eher DOM-APIs, aber vor allem die großen Kaliber wie jQuery sind oft zu viel des Guten. Meiner Meinung nach tragen sie auch nichts zur Codequalität bei, dafür sind allein die Entwickler verantwortlich.
Ich finde auch nicht, dass man alles von Grund auf selbst schreiben sollte, aber es ist meiner Meinung nach besser gezielt Bibliotheken zu wählen die einem bei einem bestimmten Problem helfen.
Zu deiner Frage: Ja der native JS-Code ist einfacher nachvollziehbar, denn dafür muss ich keine Doku lesen, sondern verstehe ihn ohne weiteres. Kürzer ist er offensichtlich nicht, genausowenig wie jQuery-Code leichter lesbar und wartbarer ist.
Ich wage mal zu behaupten, dass sich der Einsatz von jQuery & Co oftmals auch für "Kleinigkeiten" lohnt.
AntwortenIn der Praxis ist es nämlich nur allzu oft so, dass mit der Zeit immer mehr von diesen Kleinigkeiten dazu kommen.
Bei vielen älteren Projekten hat es sich dann irgend wann als praktikabler heraus gestellt die vielen Eigenentwicklungen durch jQuery Lösungen zu ersetzen, da es für gewöhnlich schlicht und einfach leichter zu pflegen und zu erweitern ist.
Was man aber doch an den Beispielen direkt sieht: Sie sind viel länger und viel komplizierter zu schreiben. Da sind die 90kb (33kb gzipped), die jQuery groß ist schnell wettgemacht.
Generell ist es wichtig, darauf hinzuweisen, dass es noch eine Welt nach jQuery gibt, allerdings vereinfacht jQuery in vielfacher Hinsicht das Arbeiten mit dem DOM, auch hinsichtlich Cross-Browser-Kompatibilität. Ja, das ist auch heute noch wichtig. Wie im jQuery-Blog mal geschrieben wurde sind die meistens Workarounds für Webkit/Blink (Safari/Chrome) geschrieben und NICHT für den IE.
Daneben sollte man auch Bedenken, dass viele Effekte heutzutage einfach über CSS umgesetzt werden können. So hat man auch Aussehen und Funktion sauber voneinander getrennt
AntwortenEs geht eigentlich nicht unbedingt nur um die Dateigröße, sondern wie schnell deine Applikation funktioniert. Und natives JavaScript ist da nunmal um einiges schneller als irgendeine Bibliothek.
AntwortenMal davon abgesehen, dass diverse Lo-Dash Funktionen die nativen Äquivalente schlagen. Zum Beispiel das im Artikel erwähnte Array.forEach.
Was die generelle Performance angeht, klar ist natives JS schneller als eine weitere Abstraktionsebene drübergepackt.
Unter der Voraussetzung man macht alles richtig.
Die Libs sind optimiert und werden von beruflichen Entwicklern maintained. Da kann der Designer Fritz der JS schonmal gehört hat, und selbst jQuery Selektoren überspezifiziert einfach nicht mithalten.
Der Nutzen den solche Bibliotheken haben ist relativ und in vielen Fällen bedingt durch den Code der alternativ an der Stelle stehen würde falsch.
Zumal der Unterschied von JS zu jQuery echt marginal ist wenn man nicht gerade bei jedem click, scroll oder mousemove 50 Änderungen am DOM macht, nur weil jQuery dazu verleitet.
Hast du Beispiele wo der Unterschied spürbar ist? Das wäre interessant und würde den Artikel vielleicht noch ein Stück aufwerten.
Es ist davon auszugehen, dass jeder weiß was er tut.
Ein Extrem-Beispiel wäre zum Beispiel: Wenn du dir relativ große Datenmengen per JSON von irgendwoher holst, und aus Gründen der gefühlten Ladezeit, es vorziehst, das UI (samt Logik) live im Browser des Besuchers zu bauen. Vorausgesetzt die Seite muss nach dem Betrachten nicht mehr weiter existieren oder verfügbar sein.
In so einem Fall ist vanilla JS um einiges besser geeignet als vorher noch eine Lib laden zu müssen.
Aber es stellt sich die Frage: Warum sollte ich für einen Fade, der in einer Zeile geschrieben werden kann, eine ganze Lib einsetzen die zu 99,9999% nicht benutzt wird.
Bitte schreib uns mal deinen fade in einer Zeile.
alt ist der gag durchaus, aber jquery hatte vor jahren auch mehr daseinsberechtigung als heute. heutzutage wird es übertrieben eingesetzt, da vieles schon per vanilla js funktioniert - natürlich hat jquery viele vorteile, aber wenn es um simple selektionen geht dann ist man mit vanilla js genauso schnell und der code ist performanter. allerdings wird zb classlist vom IE9 nicht unterstützt, für simple dinge reicht aber className auch.
Antworteneinen guten developer erkennt man daran dass er jquery eben NICHT für jede kleinigkeit einsetzt, sondern gezielt da wo es auch sinn macht.
Dieser "Gag" ist leider schon 10 Jahre alt und auch völlig falsch. Warum wohl hat sich jQuery so etabliert wenn reines JS ach so easy ist ? Ist es nämlich nicht. jQuery ist "JS + usability". Wer in reinem JS mal eben einen fader schreiben kann: Bitte, macht. Für die restlichen 99% ist aber dann $(x).fadeOut() die bessere Wahl. Entwickler kosten Zeit und Geld, und jQuery hat sich - okönomisch gesehen - in bisher jeder mir bekannter Firma der Welt gründlich rentiert.
AntwortenHallo Chris, dann kennst du aber leider nicht sehr viele Firmen :(
Antwortent3n gehört dann wohl auch zu den "wenigen" Firmen, für die sich jQuery ökonomisch lohnt.
P.s. wie wäre es mal mit einer Bildergalerie in IRGEND EINER Form von Javascript? Pro Bild ein PHP Request ist schon ein schöner Weg die Page Impressions zu steigern.
Bei nem FadeOut mit jQuery kann man nicht wirklich von Wirtschaftlichkeit reden...
Es tut mir Leid, aber ganz ehrlich wenn 99% der Webdesigner/-developer nicht in der Lage sind einen FadeOut in nativen JS zu schreiben sollten sie vielleicht mal darüber nachdenken ob sie den falschen Job haben.
AntwortenAußerdem ist hier wohl von einigen Leuten nicht der Sinn des Artikels verstanden worden. So wie ich das sehe hat hier niemand versucht jQuery oder der Gleichen schlecht zu machen, sondern es wird nur darauf hingewiesen das es extrem oft unnötigt eigesetzt wird und das es Fakt. Ich habe schon Seiten gesehen wo nur für ein einzelnen ID Select jQuery eingebunden wurde. Ich nutze jQuery auch in vielen (wenn nicht sogar den meisten) Projekten und ich glaube auch, dass hier Niemand leugnen will, dass es extrem oft extrem praktisch ist. Sonst würde es auch nicht von so vielen großen Firmen eingesetzt. Aber wenn ich hier in den Kommentaren sehe wie wenig Leute scheinbar überhaupt das Interesse haben, möglichst performanten Code zu schreiben, macht mich das wirklich Traurig. Schaut euch mal Statistiken an wie viele UNNÖTIGEN Bytes pro Minute im Netz übertragen werden und rechnet das mal auf UNNÖTIG verschwendete Ressourcen um
+1
Völlig falsch? Ganz sicher nicht. jQuery ist in einer Zeit groß geworden, wo die Javascriptunterstützung der Browser gelinde gesagt katastrophal weit auseinander lag. Heutzutage ist das nicht mehr der Fall und die wenigen verbliebenen Lücken lassen sich problemlos mit Polyfills stopfen.
Es ist ja auch nicht grundsätzlich falsch ein Framework wie jQuery zu verwenden, aber man sollte sich schon Gedanken machen, ob es wirklich notwenig ist. Bei sehr vielen Seiten ist das nämlich nicht der Fall. Erschwerend kommt zum Beispiel hinzu, dass die Animationen von jQuery fast unbrauchbar langsam sind und man somit eh noch Velocity oder ähnliches einbinden muss. Dann lieber gleich gezielt die benötigten Bibliotheken auswählen und wenn von den Rundumsorglosframeworks (das funktioniert nämlich nicht).
AntwortenUnsinn es gibt noch genug bugs die jquery fixt. Siehe https://mobile.twitter.com/paul_irish/status/431584056883429376
@gdhsnsbsvs
Ach und die sind für jedes deiner Projekte relevant?
Natürlich. So lange die jeweiligen Browserversionen eingesetzt und unterstützt werden, müssen wir diese als Relevant ansehen.
Was für eine schwachsinnige Aussage, die Bugs sind doch gar nicht bei jeder Anwendungs relevant, man nutzt ja nicht immer alles was eine Sprache oder ein Browser bietet.
jQuery stammt aus einer Zeit wo das Javascript bei jedem Browser anders aussah. Da gab es für die gleichen Funktionen im Netscape andere Namen als im Firefox. Teilweise ist das immer noch so.. aber zum Glück ist es inzwischen die Ausnahme.
AntwortenQuatsch, jQuery kam raus als Netscape schon lange irrelevant war. Du verwechselt das mit DHTML und den Browserwars.
@netzaktiv.de-Redaktion - Das ist mir bekannt. Dachte nur es wäre sinnvoll den Link direkt in den Artikel einzubinden.
AntwortenDer Aprilscherz ist leider einige Monate zu früh drann.
Antworten@grabnla - VanillaJS ist der Name dafür, wenn man kein Framework benutzt. Vanilla == Ganz einfach
http://vanilla-js.com
AntwortenIhr könntet ja zumindest mal den Link zur Webseite einfügen, wenn ihr schon davon sprecht. ;)
Antworten