Kolumne

JavaScript – die nächste Runtime-Plattform?

Niko Köbler

Niko Köbler

Niko Köbler geht in dieser Kolumne einem interessanten Gedanken nach: Ist JavaScript nicht auf dem Weg, ganz ähnlich wie die JVM eine universelle Runtime-Plattform zu werden? Vielleicht steht die JS-Community ja gerade dort, wo wir in der Java-Welt vor ca. 10-15 Jahren waren!

JavaScript als Runtime Platform

Auf der JAX 2016 in Mainz konnte ich mit vielen Menschen über das Thema JavaScript in der IT-Landschaft reden. Hat mich gefreut, dass das Interesse an diesem Thema so groß ist. Dabei sind nicht alle Personen, mit denen ich gesprochen habe, so begeistert von JavaScript, wie ich es bin. Aber das ist auch gut so.

Ich kann die Bedenken gegenüber JavaScript als Sprache in den meisten Fällen nachvollziehen. Dabei spielt aber meistens die Komplexität der Programmiersprache selbst eine untergeordnete Rolle. Denn wenn man JavaScript einmal verstanden hat, ist die Komplexität beherrschbar. Was aber bleibt, und auch mir das ein oder andere Mal Sorgen und Kopfzerbrechen bereitet, ist die Komplexität vieler JavaScript Frameworks und Bibliotheken sowie die Entwicklung, die diese an den Tag legen. Sei es inhaltlich, zeitlich und qualitativ (was ein eigener Artikel Wert wäre).

Die JS-Community ist momentan dort, wo wir in der Java-Welt vor ca. 10-15 Jahren waren.

In der Java-Welt sind wir mittlerweile von gut gereiften Standards und Beständigkeit verwöhnt. Wir können uns auf viele Dinge verlassen. Das ist in der JS-Welt noch nicht der Fall. Die JS-Community ist momentan dort, wo wir in der Java-Welt vor ca. 10-15 Jahren waren. Mit allen Höhen und Tiefen. So bezeichne ich z.B. den JSX-Dialekt, mit dem React.JS arbeitet, gerne als „JSP on Steroids“ – ich fühle mich dabei oft an „damals“ erinnert, als wir uns mit JSPs rumärgern mussten. Aber das nur am Rande, ich mag React.JS recht gerne.

Die Entwicklung von JavaScript-Bibliotheken schreitet schnell voran. Vielen ist die Entwicklung „zu schnell“, weil sie nicht hinterher kommen und die Beständigkeit vermissen. Eine Halbwertszeit bei JS-Bibliotheken von einem Jahr ist meist schon sehr lange. Es zeigt aber auch das Potential, das in der Platform und im Sprach-Standard liegt. Die Entwicklung schreitet voran und stagniert nicht. Das mag dem ein oder anderen negativ aufstoßen. Der Mensch fürchtet die Veränderung. Nein, eigentlich fürchtet sich der Mensch nicht vor Veränderung, sondern er fürchtet sich davor, sich selbst ändern zu müssen. Denn das mag er nicht, denn der Mensch ist ein Gewohnheitstier und mag am liebsten seine eigenen Gewohnheiten.

Laufzeitumgebung

Aber lassen wir die Programmiersprache JavaScript mal außen vor und denken über die Laufzeitumgebung nach. JavaScript läuft mitterweile auf vielen unterschiedlichen Devices und ist in viele Systeme und Plattformen integriert. Nicht nur im Browser und mit Node.js auf dem Server, auch in „Dingen“ wie SmartTVs, Smartphones, diversen Microcontrollern, ja sogar in unseren Autos kann mittlerweile JavaScript ausgeführt werden. Mit Nashorn steht eine JavaScript-Engine auch direkt auf der JVM zur Verfügung. Und es gibt noch viele weitere Szenarien, die ich nicht alle aufzählen kann. Ja, es existiert bereits eine ganze Menge an Möglichkeiten und die Verbreitung ist sehr hoch. Das macht es einfach, JavaScript-basierte Programme an eine breite Nutzerschaft zu verteilen.

Dabei müssen die Programme gar nicht mal in JavaScript geschrieben sein, wenn sie in JavaScript ausgeführt werden sollen. Mit GWT, Vaadin, DukeScript etc. existieren bereits seit ein paar Jahren Frameworks, die ausführbaren JS-Code erzeugen, aber in einer anderen Sprache geschrieben werden. Mit TypeScript ist es möglich, statisch getypten Code zu schreiben und zu Standard-JS zu transpilieren. Dabei können bestehende JS-Bibliotheken als Abhängigkeiten eingebunden und gegen deren APIs programmiert werden. Das ist ein großer Benefit, da existierende Ökosysteme genutzt werden können, ohne sich mit der Sprache selbst, in der sie implementiert sind, auseinandersetzen zu müssen. Scala.js verfolgt einen ähnlichen Ansatz, um mit Scala-Code typsichere Frontend-/UI-Komponenten zu entwickeln, mit entsprechenden Bindings auch gegen bestehenede JS-Frameworks wie z.B. jQuery, Angular, React.JS, etc., und diesen Scala-Code dann zu ausführbarem JavaScript-Code zu transpilieren.

Ist JavaScript wirklich so unsicher? Meines Erachtens nein.

Vielleicht müssen wir anfangen, JavaScript-Engines als eine Art von Binary-Runtime anzusehen, so wie die JVM auch eine Binary-Runtime ist. Klar, jetzt werden viele sagen, warum denn das? Mit der JVM haben wir doch schon eine entsprechende Runtime, und dieses (unsichere?) JavaScript wollen wir nicht als Runtime haben. Ist JavaScript wirklich so unsicher? Meines Erachtens nein. Erst recht nicht, wenn man den auszuführenden Code in einer statisch getypten Sprache schreibt und dann zu JS übersetzt. Schließlich schreibt ja auch niemand direkt Java-Bytecode (oder nur die wenigsten von uns). Und wie gesagt, die Verbreitung und damit die Erreichbarkeit einer großen Nutzerschaft ist sehr einfach und in weiten Teilen schon gegeben.

JavaScript kann mehr

Nur weil es etwas schon gibt (z.B. die JVM), heißt es nicht, dass etwas ähnliches (JS-Runtimes) nicht auch existieren kann, darf und vielleicht sogar auch muss. Wenn kein Interesse bzw. Bedarf in der Community und den Unternehmen vorhanden wäre, gäbe es auch keine Entwicklung im JavaScript-Umfeld. So weit reichen meine BWL-Kenntnisse in Sachen „Angebot und Nachfrage“ noch aus!

Wir stehen mit der gesamten Entwicklung des JavaScript-Ökosystems noch sehr weit am Anfang (und dennoch existiert bereits eine ganze Menge). Frontend-Komponenten und -Bibliotheken sind für mich nur ein Teil des großen Ganzen. JavaScript kann mehr. Es wird nur noch ein wenig dauern. Ich weiß, dass mir viele Personen jetzt widersprechen möchten und werden und mir meine Aussagen in ein paar Jahren um die Ohren gehauen werden. Aber schließlich gibt es „weltweit ja auch nur einen Bedarf für fünf Computer…

Web Tales

Niko Köbler

In der Kolumne Web Tales gibt Niko Köbler (freiberuflicher Software-Architekt) Anstöße zur Web-Entwicklung mit JavaScript, Java & Co. Aus der Praxis, für die Praxis!

Bisher erschienen:

Geschrieben von
Niko Köbler
Niko Köbler
Niko Köbler ist freiberuflicher Software-Architekt, Developer & Trainer für Java & JavaScript-(Enterprise-)Lösungen, Integrationen und Webdevelopment. Er ist Co-Lead der JUG Darmstadt, schreibt Artikel für Fachmagazine und ist regelmäßig als Sprecher auf internationalen Fachkonferenzen anzutreffen. Niko twittert @dasniko.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.