Javascript ist und bleibt ein Krampf
Tags: html5, softwareentwicklung
Kategorie Software Engineering | 1 Kommentar »
Wenn ich mir eine Programmiersprache genauer anschaue, interessiert mich nicht, wie man in dieser eine Schleife schreibt oder Eigenschaften zwischen Objekten vererbt. Mich interessieren eher die architektonischen Aspekte, etwa:
- wie kann ich Code in Module oder Pakete strukturieren?
- wie leicht lässt sich eine Testautomatisierung erreichen?
- wie kann ich Code effizient debuggen?
- welche Bibliotheken gibt es, damit ich nicht alles neu erfinden muss?
- wie sieht die Werkzeugkette für das Einbinden externer Bibliotheken aus?
- wie sieht die Werkzeugkette aus, um vom Quellcode zur auslieferbaren Applikation zu gelangen?
- wie ausgereift sind Werkzeuge für statische Code Analyse?
- wie gut sind Entwicklungsumgebungen und gibt es beim „Refactoring“ Unterstützung?
- wie hoch ist die Lernkurve und gibt es etablierte Standards?
Leider bleibt Javascript auch im Jahr 2015 aus architektonischer Sicht ein Krampf. Dummerweise ist es aber ein Krampf, um den man kaum umhin kommt, wenn man Webanwendungen entwickeln muss.
Meine heimliche Referenz für all die Punkte ist Java. Zugegeben, der Vergleich hinkt, da Javascript primär für die Entwicklung von Weboberflächen verwendet wird, während sich Java abgesehen von GWT, Vaadin und JSP auf dem Server tummelt. Nichtsdestotrotz will ich für meine Javascript Weboberfläche genauso wie für meine Java Geschäftslogik eine stabile Build Pipeline und gut strukturierten Code haben. Deshalb sei mir der Vergleich gestattet.
In Javascript wird der Quellcode vor Auslieferung nicht kompiliert, da der Browser ihn interpretiert. Deshalb werden zur Auslieferung meist nur die Quelltexte der verschiedenen Dateien aneinander gehängt und eventuell minifiziert. Soweit so gut. Für einen Unittest hingegen möchte man eigentlich nur die Quelltextdateien verwenden, zu denen Abhängigkeiten bestehen. Da es aber in der momentan in der Praxis verwendeten Javascript Version keine Import Anweisung gibt, ist man auf Krücken wie RequireJS oder Browserify angewiesen. Ein Krampf.
Für den Bauprozess gibt es momentan 2 konkurrierende Werkzeuge: Grunt und Gulp. Auch in der Java Welt gibt es unterschiedliche Werkzeuge, die aber aus unterschiedlichen Epochen stammen:
- Ant – der Urvater, heute bei Neuprojekten tunlichst zu vermeiden
- Maven – der jahrelange Platzhirsch, eine sichere Wahl, um die Lernkurve gering zu halten (viele Java Entwickler kennen sich damit aus)
- Gradle – der Herausforderer, sollte man in Neuprojekten testen
Bei Javascript ist alles in Bewegung und nichts funktioniert richtig. Grunt ist simpel, aber wichtige Plugins sind häufig nicht aktuell und funktionieren nicht. Gulp ist die diesjährige Reinkarnation, Ausgang ungewiss. Und während man bei Java einfach Maven oder Gradle installiert bzw. entsprechende Wrapper gleich mit ausliefert, benötigt man in der Javascript Welt zunächst eine lokale Node.js Installation. Das vereinfacht die Sache nicht.
Abhängigkeiten zu anderen Bibliotheken ist der nächste große Krampf. In Java definiert man solche Abhängigkeiten in seiner Maven oder Gradle Baudatei und man kann sofort mit der Entwicklung beginnen. Bei Javascript steht man wieder vor einem Wust an halbfertigen Tools zur Verwaltung von Abhängigkeiten, etwa Bower, Atomify oder doch nur npm package.json?! Bower lädt definierte Bibliotheken brav herunter, aber man muss sich dann immer noch selbst um die Einbindung dieser Bibliotheken in das Projekt kümmern und mit Grunt/Gulp rumfrikkeln (siehe browserify-shim). Neben einer reinen Javascript Bibliothek gibt es aber auch Komponenten (etwa Bootstrap), die zum Beispiel eigene Bilder, Schriften oder Stylesheets (zusätzlicher Krampf: CSS vs. Less, vs. Sass) mitbringen. Bei der Entwicklung von Bower hat daran anscheinend niemand gedacht und man muss sich dann wieder was einfallen lassen, damit auch diese Dateien korrekt eingebunden werden.
Einen etablierten Standard für die Formatierung von Javascript Quelltext gibt es natürlich auch nicht. Neben der reinen Formatierung gibt es auch noch unterschiedlichste Ansätze, wie man Funktionen und Klassen definiert. Werkzeuge für statische Code Analyse sind ebenfalls nicht ausgereift.
Gut sieht es einzig beim Debugging aus. Hier haben die Browserhersteller in den letzten Jahren massiv investiert und in ihre Browser so genannte Entwicklerwerkzeuge eingebaut. Ohne diese Werkzeuge wären viele Javascript Entwicklungsprojekte sicher schon längst gescheitert. Auch bei den Entwicklungsumgebungen gibt es für jeden Geschmack etwas, vom programmierbaren Editor wie Sublime Text oder Atom bis hin zu den üblichen Verdächtigen wie IntelliJ Idea, Eclipse und Visual Studio. Die Refactoring Unterstützung ist in allen Werkzeugen schwach, was aber in der Natur einer dynamischen Programmiersprache liegt.
Zum Thema Unittest schreibe ich lieber nichts außer: Karma vs. Jasmine vs. QUnit vs. Mocha vs. … :-)
Fazit: Die Lernkurve für einen erfahrenen Entwickler beim Einstieg in die Javascript Welt ist ungewöhnlich hoch. Etablierte Standards fehlen, alles ist im Fluss, jeden Monat kommen neue halbfertige Werkzeuge um die Ecke. Mehr als ein paar zehntausend Zeilen Code möchten man diesen Werkzeugen nicht anvertrauen. Eine einheitliche Linie fehlt, vieles stammt aus der Node.js Ecke, passt aber nur bedingt auf die clientseitige Javascript Entwicklung. Resultat sind schlecht aufgesetzte Projekte mit vielen Speziallösungen, die sich kaum von Projekt zu Projekt wiederverwenden lassen.
[…] 5 Jahren echauffierte ich mich an dieser Stelle über die vielen Unzulänglichkeiten in der Web-Entwicklung m…. Aus Selbstschutz habe ich die Web-Entwicklung deshalb in den letzten Jahren gemieden. In den […]