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

VanillaJS: So nutzen Apple, Facebook und Amazon das schnellste JavaScript-Framework

VanillaJS eigentlich „nur“ JavaScript. (Foto: © Lisovskaya - iStock.com)

Die ganz Großen nutzen es: Facebook, Amazon, Yahoo, Wikipedia, Apple, oder eBay, wohin man auch sieht: VanillaJS ist allgegenwärtig. In diesem Artikel zeigen wir euch das unglaublich schnelle und extrem mächtige Framework.

„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.

icecream
VanillaJS eigentlich „nur“ JavaScript. (Foto: © Lisovskaya - iStock.com)

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:

jQueryVanillaJS
$(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;
Eine umfangreiche Dokumentation zu VanillaJS findet ihr übrigens hier! Ihr könnt euch VanillaJS auf der offiziellen Website herunterladen, müsst ihr aber nicht, denn: VanillaJS wird von allen Browsern bereits unterstützt.

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

38 Reaktionen
Geograman

@Mario Janschitz Wir warten immer noch alle gespannt auf deinen Fade in einer Zeile. Du willst doch jetzt nicht kneifen oder ? :)

Antworten
dgdhdbd

Es fehlt der hinweis , dass domcontentloaded, classlist, addeventlistener nicht im ie8 unterstützt werden. Classlist auch nicht im ie9.

Antworten
Mario Janschitz

Der Artikel erklärt, dass VanillaJS nichts anderes ist als JavaScript. Nicht mehr, nicht weniger :)

Antworten
web

Ich 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.

Mario Janschitz

Der Artikel erklärt, dass VanillaJS nichts anderes ist als JavaScript. Nicht mehr, nicht weniger :)

Martin

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.

Mario Janschitz

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 :)

sca

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.

thod

Bibliotheken wie z.B. Jquery nehmen einem viel Arbeit in Bezug auf Browser- und Platform-kompatibiliät ab.
Ja, 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!

Antworten
ErikB

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.
Erklä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.

Antworten
irgendeinem Spinner

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.

Antworten
ErikB

Nein, 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.

ErikB

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..."

irgendeinem Spinner

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.

Fanmade

Ich wage mal zu behaupten, dass sich der Einsatz von jQuery & Co oftmals auch für "Kleinigkeiten" lohnt.
In 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.

Antworten
web

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

Antworten
Mario Janschitz

Es 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.

Antworten
jet

Mal 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.

Mario Janschitz

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.

Geograman

Bitte schreib uns mal deinen fade in einer Zeile.

Andi

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.
einen guten developer erkennt man daran dass er jquery eben NICHT für jede kleinigkeit einsetzt, sondern gezielt da wo es auch sinn macht.

Antworten
Chris

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.

Antworten
Mario Janschitz

Hallo Chris, dann kennst du aber leider nicht sehr viele Firmen :(

Antworten
Martin

t3n 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.

Mario Janschitz

Bei nem FadeOut mit jQuery kann man nicht wirklich von Wirtschaftlichkeit reden...

Simon

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.
Auß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

Antworten
Mario Janschitz

+1

irgendeinem Spinner

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).

Antworten
gdhsnsbsvs

Unsinn es gibt noch genug bugs die jquery fixt. Siehe https://mobile.twitter.com/paul_irish/status/431584056883429376

irgendeinem Spinner

@gdhsnsbsvs

Ach und die sind für jedes deiner Projekte relevant?

dhshdhdv

Natürlich. So lange die jeweiligen Browserversionen eingesetzt und unterstützt werden, müssen wir diese als Relevant ansehen.

irgendeinem Spinner

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.

W4rl0ck

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.

Antworten
ubexburbxu

Quatsch, jQuery kam raus als Netscape schon lange irrelevant war. Du verwechselt das mit DHTML und den Browserwars.

graubnla

@netzaktiv.de-Redaktion - Das ist mir bekannt. Dachte nur es wäre sinnvoll den Link direkt in den Artikel einzubinden.

Antworten
Saenic

Der Aprilscherz ist leider einige Monate zu früh drann.

Antworten
netzaktiv.de-Redaktion

@grabnla - VanillaJS ist der Name dafür, wenn man kein Framework benutzt. Vanilla == Ganz einfach

http://vanilla-js.com

Antworten
graubnla

Ihr könntet ja zumindest mal den Link zur Webseite einfügen, wenn ihr schon davon sprecht. ;)

Antworten

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

Abbrechen

Finde einen Job, den du liebst