JavaScript gibt’s doch schon seit den 90ern…

9. April 2015Dr. Thomas Franz

Die Aussage im Titel ist richtig. Und könnte zugleich nicht fehlleitender sein. Selbst ein Blick nur wenige Jahre zurück gibt ein völlig falsches Bild. In diesem, bewusst etwas provokant und mit Augenzwinkern formulierten Artikel, möchte ich die Diskussion befeuern, warum genau jetzt die Zeit reif ist – nicht für JavaScript, HTML 5 oder ein losgelöstes technisches Feature oder einen Standard. Sondern für Single Page Applications. Einen grundverschiedenen Ansatz für webbasierte und mobile Software.

Mit JSF, Play, Wicket, ASP.NET, PHP und Co kann man auch schicke Webanwendungen entwickeln…

Auch richtig. Aber was müssen wir tun, damit die Webanwendungen schick werden, die mit solchen serverseitigen Frameworks entwickelt werden? Richtig: JavaScript entwickeln. Oder, noch schlimmer, das von den Komponenten eingesetzte JavaScript anpassen und die Komponenten selber ebenfalls. Spätestens dann erscheint es mir grundsätzlich falsch, heute noch den Browser bzw. echte JavaScript-Anwendungen zu meiden.

Ach ja, was ist eigentlich mit HTTP, dem Protokoll, mit dem jede Webanwendung die Kommunikation zwischen Browser und Server umsetzt? Das Protokoll ist zustandslos, es ist also unmöglich auf dem Server zu wissen, was im Browser passiert. Jeder Ansatz, serverseitig eine Webanwendung zu entwickeln, bedeutet also:

 Wir entwickeln Präsentations- und Anwendungskomponenten in einer Umgebung, die völlig losgelöst ist von der Umgebung, in der diese Komponenten bedient werden.

Dieser Ansatz war lange Zeit „alternativlos“, heute jedoch klingt er fast schon verrückt. Session-Kontexte, Session-Replikation und mehr sind notwendig, damit wenigstens die Zustandsinformationen der Browser-Server-Interaktion verfügbar sind. Das bedeutet jedoch zusätzliche Komplexität und erschwert oder verhindert teilweise sogar Skalierbarkeit.

1

 

jQuery gibt’s doch schon lange…

Wieder richtig. Und doch ist jQuery kein Framework für die Anwendungsentwicklung – und immer noch (zu) nahe am HTML-DOM. Wollen wir Tests schreiben, die bei jeder Änderung eines Templates angepasst werden müssen? Sicher nicht. Daher glaube ich aktuell an diese Daumenregel:

Die direkte Nutzung von jQuery ist
ein Hinweis auf schwer zu wartende und schwer zu verstehende Software.

Dass es heute viel besser geht, zeige ich in den nächsten Abschnitten.

Single Page Applications now!

Entwickeln, Testen, Bauen, Deployen, Debuggen und mehr sind Aufgaben rund um den Softwareentwicklungsprozess. Diese Aufgaben können heute effizient und professionell mit den Werkzeugen, Konzepten, Frameworks und Bibliotheken um JavaScript erledigt werden. Single Page Applications bedeutet für mich daher wesentlich mehr als HTML 5, CSS 3 und JavaScript zu nutzen. Es bedeutet nicht nur, das gesamte neue Ökosystem professionell zu nutzen, sondern auch neue Möglichkeiten für Unternehmen zu schaffen. Webbasierte Software wird nicht nur interaktiver, sie kann auch draußen wie drinnen, offline bzw. im Keller oder im ICE, web-basiert statt nativ für mobile Anwendungsfälle entwickelt werden. Das birgt enormes Potenzial für mehr Wirtschaftlichkeit, Veränderung von Unternehmensprozessen und neue Integrationsfähigkeit zwischen Unternehmensanwendungen.

2
Die Welt der Browser und von JavaScript früher und heute – kein Vergleich

Model-View-Controller im Browser

Der Weg zu Single Page Application Development ist ein langer. Es ist 1996, meine Freundin ist weg und bräunt sich … und es gibt den ersten Web-Browser, der JavaScript interpretieren kann: Netscape Navigator 2.0 nennt er sich. JavaScript schreibe ich im Texteditor, testen muss ich manuell, die Sprache ist gewöhnungsbedürftig und mein Code ist fehleranfällig. Das ist er heute auch noch, aber das Schlimme daran ist: Ich kann nicht einmal einfache Unit-Tests umsetzen. Ich habe auch keine Möglichkeit BestPractices anzuwenden. Es ist 2009, Netscape gibt es nicht mehr … dafür aber ModelView Controller Frameworks für Browser. Wir wählen hier zwischen Angular, Backbone, Ember, Knockout und neuerdings auch React. Das sind allesamt Frameworks, mit denen echte Anwendungen entwickelt werden – das sind keine Webseiten mehr! Vergessen sind Page-Loads, die Interaktionen unterbrechen. Noch wesentlicher: Die Serverseite hat sich extrem gewandelt. Wir nutzen unser gesammeltes Java-, .Net-, PHP-Wissen und entwickeln damit hochskalierbare, leichtgewichtige REST-Services. Die können übrigens nicht nur von der Anwendung im Browser einfach genutzt werden, sondern sind gleichzeitig auch für weitere Anwendungen nutzbar, weil sie um Anwendungslogik bereinigt sind und eher als Datendienste fungieren.

3

Testen, Debuggen und Performance-Messung

Wir nutzen Jasmine, Protractor oder Karma, um nur einige Werkzeuge zu nennen, und können Unit-Tests und End-to-End-Tests schreiben. Und das ohne DOM-Elemente zu referenzieren oder überhaupt zu behandeln.
Der Browser ist nicht mehr nur Interpreter. Er ist eine umfangreiche Laufzeitumgebung, bietet Debugging mit Haltepunkten und Bedingungen, Performance-Messungen und genaueste Einblicke in Caching, Latenzzeiten und Netzwerkkommunikation.

Build Management

Es gibt zahlreiche Bibliotheken für die verschiedensten typischen Anforderungen in Softwareentwicklungsprojekten. Über den Paketmanager npm stehen 135.332 (Stand 26.03.2015) Pakete zur Verfügung, um Werkzeuge für das Build Management und, wo gewollt, serverseitiges JavaScript einzusetzen. Aus der Entwicklung von Twitter nutzen wir bower, den Paketmanager für das Web, den wir über npm erhalten und der uns die JavaScript Bibliotheken liefert, mit denen wir Single Page Apps entwickeln. npm liefert uns auch Build-Werkzeuge wie grunt oder gulp, mit denen wir automatisiert die verschiedenen Werkzeuge für das Schnüren der Anwendung bis zur automatischen Ausführung von Test, der Code-Analyse, dem automatischen Deployment oder dem Start der Anwendung im Browser steuern können.

4
Die Evolution der Webentwicklung

Don’t be tricked: Es geht um viel mehr als JavaScript, HTML 5 und CSS 3

Die Gesamtheit der Entwicklungen macht den Neuerungseffekt aus, nicht die Verfügbarkeit einzelner Entwicklungen. Und eine sehr große Neuerung steht kurz bevor: ECMAScript 6. JavaScript erhält Vererbung, Modularisierung, statische Typisierung und mehr als Sprachkonstrukte. Schon heute können wir diese Neuerungen übrigens in Projekten einsetzen. Mit Rückwärts-Compilern wie traceur schreiben wir Klassen und Pakete, importieren, vererben und erhalten JavaScript, das heutige Browser interpretieren kann.

Zu guter Letzt: Nein, nicht immer sind Single Page Applications der richtige Weg. Zwar interpretiert Jeff Atwood Tim Berners Lee’s “The Principle of Least Power” folgendermaßen: “Any application that can be written in JavaScript, will eventually be written in JavaScript”. Aber ich denke nicht, dass alles in JavaScript entwickelt werden wird ;).

Was meint ihr? Arbeitet ihr mit Single Page Applications? Oder nutzt ihr lieber JavaScript?

Dr. Thomas Franz Dr. Thomas Franz ist Technologieexperte bei adesso. Er interessiert sich für die Themen Big Data, Lean Startup und DevOps sowie deren Zusammenwirken mit technologischen Trends wie NoSQL-Datenbanken, Cloud-Infrastrukturen und modernen Web-Architekturen.
Artikel bewerten:
1 Star2 Stars3 Stars4 Stars5 Stars
Loading...

Kommentare

Stavros Kamarianakis 9. April 2015

Sehr guter Bericht!

Kommentar hinzufügen:

Ihr Kommentar: