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

Feature

Für jede Kleinigkeit ein Framework: Warum immer mehr Entwickler von Javascript genervt sind

    Für jede Kleinigkeit ein Framework: Warum immer mehr Entwickler von Javascript genervt sind
Computer könnten bald unvorstellbar schnell sein. (Bild: Shutterstock)

Javascript erfreut sich einer hohen Popularität im Einsatz – das liegt aber nicht an der Liebe zur Sprache – im Gegenteil –, sondern eher am Verbreitungsgrad.

Javascript historisch

Javascript entstand 1995 innerhalb einer Coding-Session von zehn Tagen. Es floss nur so aus der Tastatur des Erschaffers Brendan Eich und hat sich seitdem eher mäßig weiterentwickelt. Erst im letzten Jahr entschloss sich das für die Sprache zuständige TC39 dazu, zumindest ab 2016 jedes Jahr wirklich eine neue Version herauszubringen.

Javascript: So schnell, wie es entstand, ist es heutzutage nicht mehr erlernt. (Foto: Shutterstock / ESB Professional)

Das erste Ergebnis dieses neuen Vorsatzes kann unter der Bezeichnung ES6 (ECMAScript 6) begutachtet werden. Die Vielzahl der neu eingeführten Features lässt ES6 tatsächlich fast wie eine neue Programmiersprache und nicht wie eine bloße Weiterentwicklung wirken. Dennoch fehlt der Sprache im Vergleich zu anderen Programmiersprachen einiges an Funktionalität.

Historisch betrachtet ist das auch logisch, denn Javascript sollte in Maßen interaktive Seiten ermöglichen, nach den Standards des Jahres 1995. Was heutzutage mit Javscript geschaffen wird, war nicht Grundlage der Überlegungen bei der Entwicklungung der Programmiersprache.

Javascript ist (noch) alternativlos

Dennoch sind wir als Entwickler auf Javascript angewiesen, eben aus denselben historischen Gründen. Javascript ist ganz grundsätzlich rückwärtskompatibel und muss es auch sein. Hunderte von Millionen an Websites nutzen die Sprache für das ein oder andere Feature. Es wäre eine regelrechte Katastrophe, wenn eine neue Version von Javascript mit alte Konventionen brechen und damit unzählige Websites unbrauchbar machen würde.

Andererseits ist Javascript per Design nicht so weit ausbaubar wie modernere Konkurrenten. Möglicherweise kommt irgendwann tatsächlich der Zeitpunkt, an dem sich alle Browserhersteller auf die Implementation einer Alternative einigen. Sollte das passieren, wird die Situation für eine mehr oder weniger lange Übergangszeit noch komplizierter.

Entwickler werden dann – wie heute schon bei HTML und CSS erforderlich – Alternativen zur neuen Programmiersprache in Javascript anbieten müssen, um diejenigen Nutzer nicht zu verlieren, die noch mit älteren Browsern unterwegs sind. Da ist das heutzutage bereits verwünschte Prefixing ein Kinderspiel dagegen.

So ist es nicht zuletzt der Bedarf an mehr Funktionalität und flexiblerer Programmierung, der in den letzten Jahren zu einer wahren Flut neuer Javascript-Frameworks, Libraries und anderer, komplexerer Tools wie Babel oder Webpack geführt hat.

Jsfatigue: Wenn du die Nase voll hast von Javascript

Es ist vor allem dieser rasante Anstieg in der Zahl neuer Tools und Erweiterungen, der dem durchschnittlichen Webentwickler zu schaffen macht. Wahrscheinlich sind in der Zeit, die ich brauchte, um diesen Beitrag zu schreiben, schon wieder drei Javascript-Frameworks erschienen. Unter dem Hastag #jsfatigue wird in der Community dementsprechend fleißig darüber diskutiert, wer in welcher Form und warum die Nase voll hat von Javascript.

Rede und Gegenrede konzentrieren sich auf ein paar wenige Aspekte:

Überflüssige Me-Too-Frameworks

Diesen Aspekt verdeutlicht ein Cartoon ganz gut, den ich für das Dr. Web Magazin erstellt habe:

(Quelle: Dr. Web / Dieter Petereit)

Es hat durchaus bisweilen den Anschein, dass Hans und Franz sich bemüßigt fühlen, auf jeden Fall als erstes ein Framework zu programmieren, wenn sie ein neues Projekt umsetzen wollen. Schauen wir uns die Bandbreite verfügbarer Lösungen in Ruhe an, so kommen wir tatsächlich nicht umhin, eine recht beachtliche Redundanz festzustellen.

Unnötige Komplexitätssteigerung

Vielfach wird beklagt, dass durch die verfügbaren Frameworks und Erweiterungen die Programmierung unnötig verkompliziert würde. Gerade der Umgang mit Tools wie Babel, SystemJS oder Webpack ist nicht ohne Lernkurve zu bewältigen.

Wenn 24 Stunden nicht reichen, dann nehmen wir noch die Nacht dazu. (Foto: Shutterstock / Stokkete)

Je nachdem, welche Aufgabe letztlich durch den Javascript-Einsatz erledigt werden soll, kann bisweilen durchaus der Eindruck entstehen, es würde mit Kanonen auf Spatzen geschossen.

Ebenfalls an dieser Stelle zu nennen ist der Umstand, dass die Entscheidung für ein bestimmtes Tool häufig gleich die Entscheidung für etliche andere Tools nach sich zieht. Das gilt besonders beim Einsatz von React oder Angular. Hier kann allein das Einrichten eines Javascript-Projekts in die Stunden gehen.

Wunderbare Vielfalt

Entwickler hingegen, die sich bereits seit Jahren im Javascript-Umfeld bewegen, loben die neu entstandene Vielfalt und plädieren dafür, sich darüber zu freuen, dass es für jeden Anwendungszweck mehrere Alternativen gibt. Am All-you-can-eat-Buffet beschwere man sich schließlich auch nicht über zuviel Auswahl.

Gelassene Selbstbeschränkung

Erfahrenere Entwickler empfehlen, sich nicht den Stress anzutun, jede Neuerung und jedes neue Tool direkt verstehen und einsetzen zu wollen. Stattdessen solle man sich zunächst auf Vanilla JS (also das ursprüngliche Javascript) beschränken und schauen, wie weit man damit alleine bereits kommt. Dann könne man immer noch entscheiden, ob es an bestimmten Stellen eventuell sinnvoller sein könnte, mit einer Erweiterung zu arbeiten.

Andere raten insoweit zur Gelassenheit, als die Geschwindigkeit, mit der neue Frameworks, Libraries und Methoden produktiv eingesetzt werden, im Regelfall nicht in Wochen und Monaten bemessen wird, sondern eher in Jahren. Insofern bestehe jede Eile nur gefühlt.

Fazit: Much ado about nothing?

Wir haben es im Deutschen leichter, das Wort Fatigue flexibel zu deuten. Wir können es entweder recht krass als Erschöpfung oder etwas milder als Ermüdung definieren. Und ziemlich exakt zwischen diesen beiden Polen verläuft auch die aktuelle Diskussion. Die Wahrheit liegt – wie so oft – in der Mitte.

Die Innvationsgeschwindigkeit, mit der neue Javascript-Frameworks, Methoden und Libraries aus dem Boden gestampft werden, kann einen dann ermüden, wenn man an sich selbst den Anspruch setzt, stets ganz aktuell auf dem Stand der Technik sein zu müssen. Bringt man sich dann noch voll ein und versucht, alle Neuerungen produktiv umzusetzen, mag es tatsächlich sogar zur Erschöpfung kommen.

Der Workaround ist so simpel wie er klingt: Weder Anspruch, noch Umsetzung sollten stets „Bleeding Edge“ sein. Das ist zum einen gesünder und zum anderen auch völlig ausreichend.

Wie steht ihr zu diesem Thema?

Quellen zum Weiterlesen

Finde einen Job, den du liebst zum Thema JavaScript, Webdesign

7 Reaktionen
bonjovi
bonjovi

Kann den Artikel ebenfalls nicht richtig nachvollziehen. Denkt man nur an die großen Frameworks wie React oder Nodejs ist es doch toll, dass die Vielfalt der Frameworks auch solche Lösungen hervorgebracht hat. Gerade von der Einfachheit bei Nodejs einen Webservice aufzusetzen bin ich immer noch beeindruckt. Außerdem halte ich Vielfalt grundsätzlich nicht für falsch. Natürlich macht es mehr Arbeit sich durch die Menge der Möglichkeiten zu arbeiten, aber ich verstehe nicht, warum immer noch so viele Entwickler der Meinung sind, alles immer wieder von Grund auf neu entwickeln zu müssen. Unabhängig von der Programmiersprache helfen uns Frameworks neue Techniken zu entwicklen, anstatt immer das selbe wieder und wieder zu wiederholen.

Antworten
Martin
Martin

Wenn man sich im Agenturumfeld bewegt, ist es leider nicht so wie "ist doch nicht so schlimm, es kann ja jeder selbst entscheiden was er nutzt". Regelmäßig übernimmt man andere Projekte oder arbeitet an größeren Projekten mit anderen Agenturen, wodurch es dann verschiedene Teile mit verschiedenen Techniken gibt (wenn es nicht gut koordiniert wird). Um bestehende größere Projekte auf einen aktuellen technischen Stand zu bringen fehlt da leider meistens das Budget. Auch innerhalb der eigenen Organisation gibt es schnell eine große Diversität an Tools, denn die Technik entwickelt sich weiter, aber damit wird nicht automatisch jedes vorige Projekt auch auf den Stand gebracht, auch aus Budgetgründen.

Um beim Bild des All-you-can-eat zu bleiben: man kann sich da nicht herrlich frei entscheiden, was man davon isst; nein, man wird festgebunden und andere stopfen dich scheinbar wahllos mit den verschiedenen Sachen voll :-)

Antworten
BSimpson
BSimpson

Meiner Meinung nach liegt das Problem von JavaScript darin, dass viele Funktionalitäten die man von einer modernen Programmiersprache erwartet ( weil man ja auch andere kennt, wie Python , PHP usw. ) einfach in der Standart-Library fehlen. Man muss für die einfachsten Dinge wie ein Datum zu Formatieren oder ähnliches selbst Funktionen schreiben oder aber auf schon existierende Libraries zurück greifen. Mein liebstes Beispiel ist immer JQuery und die Tatsache dass kaum eine Library ohne auskommt. Dass und die Tatsache dass es keine integrierte Abhängigkeitsverwaltung in der Sprache existiert, zeigt mir dass Javascript einfach nicht zu Ende gedacht und implementiert wurde. Ebenfalls ist die Sprache nicht strikt genug und erlaubt zuviel in Sachen schlechten Code ( Gültigkeit von Variablen uvm. ) Aber wie der Artikel schon beschrieb ist JS im Moment noch alternativlos. Ich hoffe Die Browserhersteller entschliessen sich in nicht all zu ferner Zukunft Javascript durch was anderes komplett zu ersetzen, anstatt die Karr mit mässigen Erfolg zu reparieren.

Antworten
Robert Willemelis
Robert Willemelis

Das Einrichten eines Angular-Projektes dauert stunden? noch nie von der CLI gehört? :-D

https://github.com/angular/angular-cli

Antworten
Tom
Tom

Es kommt mir oft so vor, dass die meisten deutschen JavaScript-Entwickler, hinter dem Mond wohnen.

btw.
In dem Artikel hätte man auch auf nodejs eingehen können und die Server-seitigen Möglichkeiten, mit dieser simplen Sprache. (npm... etc.)

Antworten
Erich Gerulat
Erich Gerulat

Es bleibt doch jedem selber überlassen, ein Framework zu nutzen oder nicht. Die meisten werden doch vom Programmierer geschrieben, um die Arbeit für sich selber zu erleichtern. Man muss nichts davon benutzen !

Antworten
Markus
Markus

Wie kommt man auf die Idee JavaScript selbst zu zerreden, nur weil es viele nutzen und damit zwangsweise viel drum herum entsteht. Wir haben hier im produktiven EInsatz eine klare Trennung. So wenig wie möglich fremde Frameworks und häufig verwendetes in ein eigenes. ABER es scheint dann viele zu geben, die das eigene publizieren und der Meinung sind, dass die eigene Lösung für andere auch eine ist. Völliger Käse und es kostet einen guten Entwickler (ich bin keiner) viel Zeit sich in die Idee eines anderes reinzudenken, als auf Null ein eigenes zu bauen.

Vielfalt ist also ein Makel für die Grundsprache, dann wird es in Zeiten von Plattformdenken aber hart.

Antworten
Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden