Jenseits von JavaScript

7. Mai 2015Daniel Assonov

Seit der Einführung 1995 wurde die Programmiersprache JavaScript (JS) kontinuierlich weiterentwickelt. Trotzdem wurde und wird sie unaufhörlich kritisiert und meistens leider zu Recht. Gleichzeitig ist JS in der Entwicklung moderner Webanwendungen unverzichtbar. Diese Umstände machen neugierig auf Sprachen, die alternativ zu JS eingesetzt werden können. Zumal solide Lösungen bereits verfügbar sind.

Warum nach Alternativen suchen?

Zeitgemäße Webanwendungen erfordern deutlich mehr clientseitigen Code: Während früher die Grenze zwischen Client und Server durch die View-Schicht gezogen wurde, ist es heute ratsam diese Aufteilung in der Controller-Schicht vorzunehmen (Stichwort Single Page Applications). Der Hauptgrund dafür ist, meiner Meinung nach, die Reduktion von Client-Server-Kommunikation, was eine schnellere Reaktion auf den Benutzerinput ermöglicht. Dies wiederum hat einen großen Einfluss auf die User Experience, deren Bedeutung für ein Software-Produkt Volker Gruhn neulich in einem Artikel hervorhebte.

Clientseitige Anwendungsteile müssen in JavaScript vorliegen, damit sie nativ in Browsern ausgeführt werden können. Andere Lösungen, wie Flash, Silverlight oder Java-Applets scheiden aus, weil sie Browser-Plugins erfordern, die auf mobilen Plattformen meist nicht verfügbar sind. Also muss bzw. sollte ein beachtlicher Teil einer Webanwendung in JS implementiert werden. Die Frage nach der Notwendigkeit von Alternativen lässt sich am besten mit einem Überblick an JavaScripts Unzulänglichkeiten beantworten:

  • Klassen und Interfaces sind nicht vorgesehen
  • Vererbung nach dem wenig verbreiteten Prototyp-Paradigma
  • Datenkapselung nur umständlich umsetzbar
  • Keine nativen Mittel zur Modularisierung
  • Geringer Funktionsumfang der API
  • Unerwartetes bzw. fragwürdiges Verhalten von manchen API-Methoden und Sprachkonstrukten (siehe wtfjs.com)

Es gibt unzählige Frameworks und Bibliotheken, die versuchen diese Nachteile zu kompensieren. Gleichzeitig stellt ihr Einsatz Entwickler vor neue Probleme, wie sinkende IDE-Unterstützung oder Update-Aufwände.

Die sechste Version von ECMAScript (JavaScript-Standardisierung) soll bereits im Juni verabschiedet werden. Neben vielen neuen Sprachfeatures werden einige der oben aufgezählten Mängel behoben. Leider nicht alle: So wird es weiterhin keine Interfaces geben, Datenkapselung bleibt schwierig und aus der Kategorie „unerwartetes Verhalten“ bleiben die Operatoren == und !=, die eine implizite Typumwandlung der Argumente beinhalten. Nachdem ECMAScript 6 offiziell ein allgemeingültiger JS-Standard geworden ist, muss immer noch abgewartet werden, bis alle marktrelevanten Browser den Standard unterstützen. Eine Feature-Support-Matrix lässt vermuten, dass es bis dahin noch ein weiter Weg ist.

Alternativen zu JavaScript – wie geht das?

Wie bereits erwähnt, können Browser nur JS-Code ausführen. Somit muss der clientseitige Teil einer Webanwendung zur Deploy-Zeit in JavaScript vorliegen. Während der Entwicklung kann jedoch mithilfe eines Compilers oder „Transpilers“ eine andere Sprache zum Einsatz kommen (konkrete Beispiele weiter unten). Der Code wird anschließend zu JS kompiliert. Der somit nötige Kompilierungsschritt fällt bei einem, meist automatisierten, Build- bzw. Delivery-Prozess nach State of the Art nicht allzu sehr ins Gewicht: Bevor Code auf einem Server landet, werden üblicherweise Unit Tests ausgeführt, der JS-Code wird mit einem Code-Checker (z. B. JSLint) geprüft und anschließend minifiziert. Die zwei letzteren Schritte werden durch den Kompilierungsprozess ersetzt – Compiler weisen auf Fehler hin und optimieren (inkl. Minifizierung) ihren Output bzw. den JS-Code.

adesso_JavaScript_

Delivery-Prozess: klassisch (links) und bei Verwendung einer anderen Sprache zur Entwicklungszeit (rechts)

 
Ein zentraler Aspekt beim Verwenden einer zusätzlichen Sprache ist das Debuggen einer Anwendung. Damit die Fehleranalyse in der Ausgangssprache statt in JS stattfinden kann, können Compiler sog. Source Maps erzeugen. Diese Textdateien beschreiben die Zuordnung von generierten JS-Anweisungen zum ursprünglichen Quellcode. Stehen Source Maps zur Verfügung, können aktuelle Browser beim Debuggen den originalen Code anzeigen. Der Programmzustand (bzw. Variablenbelegung), wird allerdings von Browsern ausschließlich in JavaScript dargestellt – hier sorgen IDEs für Abhilfe (siehe unten).

Dart, TypeScript & Co

Die drei prominentesten JavaScript-Alternativen sind Googles Dart, Microsofts TypeScript und CoffeeScript. Auch das GWT-Projekt (mit Java als Ausgangssprache) funktioniert nach dem oben beschriebenen Prinzip. Obwohl CoffeeScript die älteste der drei Sprachen ist, bietet sie hauptsächlich syntaktischen Zucker und nur wenige attraktive Sprachfeatures. Dagegen unterstützen TypeScript und Dart die klassische bzw. klassenbasierte OO-Entwicklung und ein statisches Typsystem, welches optional genutzt werden kann. Unterschiede zwischen den beiden liegen im Detail: So sind z. B. Variablen in Dart standardmäßig ohne Wertetyp, während man in TypeScript stets eine Typangabe machen muss, wobei auch any (d. h. „beliebiger Typ“) zulässig ist. TypeScript ist hervorragend in aktuelle Versionen von Visual Studio integriert, während für Dart eine eigene IDE (basierend auf einem abgespecktem Eclipse) angeboten wird. Zusätzlich werden beide Sprachen von Eclipse und IntelliJ unterstützt. Die bedeutendsten Unterschiede sind die Integrationsfähigkeit mit JavaScript und der API-Umfang. Ersteres gelingt bei TypeScript wesentlich leichter als bei Dart. Bzgl. API hat Dart wiederum deutlich mehr zu bieten, während TypeScript sich in diesem Punkt kaum von JavaScript unterscheidet. Diese Konstellation legt nahe, TypeScript insbesondere für Entwicklung von Komponenten für bestehende JavaScript-Landschaften einzusetzen. Darts Stärken kommen am besten bei einer Neuentwicklung zur Geltung. Ebenfalls bemerkenswert ist die Entscheidung von Google und Microsoft, dass AngularJS 2.0 auf TypeScript basieren soll, wobei JS weiterhin unterstützt werden soll [heise].

Zum Schluss sollte noch die Möglichkeit erwähnt werden, bereits heute mit dem künftigen JS-Standard (ECMAScript 6) entwickeln zu können. Dafür stehen Compiler wie Traceur oder Babel zur Verfügung. Jedoch wird man zwecks Kompatibilität mit älteren Browsern vermutlich auch ein bis zwei Jahre nach der Verabschiedung des Standards auf diese Compiler angewiesen sein (siehe oben).

Fazit

JavaScript ist den Anforderungen großer Web-Projekte nicht gewachsen – das wird sich ändern, aber nicht sofort. Zum Glück stehen schon jetzt Sprachen (inkl. Tools) bereit, die speziell für das Web von heute entwickelt wurden. Damit lassen sich Webanwendungen mit optimaler User Experience unter Anwendung von Best Practices des Software Engineerings realisieren.

Wie ist Ihre Meinung zu JavaScript und seinen Alternativen? Was setzen Sie ein? Ich freue mich auf Ihre Kommentare!

 

Daniel Assonov Daniel Assonov ist Software Engineer in der Line of Business Health der adesso AG. Seine Schwerpunkte sind Front-End- und Web-Entwicklung mit einem auf Java und JavaScript basierendem Technologie-Stack.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentar hinzufügen:

Ihr Kommentar: