JavaScript für Enterprise-Entwickler

Professionell programmieren im Browser und auf dem Server

Oliver Ochs

• Verlag: dpunkt
• Jahr: 2012
• ISBN:
  9783864911279
• Auflage: 1
• Thema: Computer Science
• Thema: Programming in JavaScript

Immer mehr Programmierer von Enterprise-Anwendungen interessieren sich für JavaScript. Sie wollen sich schnell darin einarbeiten, sind aber oft nicht mit den gängigen JavaScript-Büchern für Webentwickler zufrieden. Nach einem schnellen Überblick über die JavaScript-Kernkonzepte geht es in diesem Buch daher ohne Umschweife an die spannenden Themen, u.a.: funktionales, prototypisches und objektorientiertes Programmieren, Testen, Packaging, Entwurfsmuster, jQuery und node.js. Kenntnisse in der Webentwicklung sind erforderlich, Jave-EE-oder.NET-Erfahrung ist hilfreich.

1 Die Geschichte von JavaScript

Um JavaScript und seine verschiedenen Ausprägungen einordnen zu können, ist ein kurzer Blick in die Geschichte von JavaScript sinnvoll. Es wird zunächst berichtet, wie JavaScript entstanden ist und was die Vorbilder von JavaScript waren. Dies ist wichtig, um JavaScript von bekannten objektorientierten Programmiersprachen wie Java unterscheiden zu können. Dann werden die unterschiedlichen Ausprängungen und Implementierungen der Sprache angesprochen, um schließlich moderne Strömungen kurz anreißen zu können.

1.1 JavaScript – die Lingua franca des WWW

Nahezu jede Website – egal in welcher Sprache das Backend programmiert wurde – verwendet im Browser JavaScript als Programmiersprache. Selbst Adobe Flash wird in ActionScript, einem Dialekt von JavaScript, programmiert. Daher kommt fast jeder Webentwickler zwangsläufig mit JavaScript in Berührung. Dies macht JavaScript zu einer der am häufigsten verwendeten Programmiersprachen der Welt. Mit anderen Worten: JavaScript ist die Lingua franca des World Wide Web!

1.2 Netscape und JavaScript

1994 gründete Marc Andreessen, einer der Mitentwickler des NCSA¹ Mosaic Web Browser, die Firma Netscape, die den ersten kommerziell erfolgreichen Webbrowser, den Netscape Navigator, veröffentlichte. Mit dem Netscape Navigator wurde das World Wide Web, wie wir es heute kennen, geboren. Allerdings konnte die erste Version des Netscape Navigator nur statische HTML-Seiten darstellen.

Brendan Eich, der zuvor u. a. bei Silicon Graphics gearbeitet hatte und heute der CTO der Mozilla Foundation ist, stieß 1995 zu Netscape. Dort entwickelte er die Skriptsprache Mocha, die dann in LiveScript umbenannt und schon im September 1995 mit dem Netscape Navigator 2.0 ausgeliefert wurde. Bereits im Dezember 1995 wurde LiveScript nochmals umbenannt, dieses Mal in JavaScript. Der Name JavaScript hat technisch nichts mit Java zu tun, einer Programmiersprache, die gerade von Sun Microsystems entwickelt wurde, sondern wurde aus Marketinggründen gewählt, um vom Hype um das gerade populär werdende Java zu profitieren.

Als Gegenleistung für die Namensrechte an Java lieferte Netscape die Java Virtual Machine von Sun Microsystems zusammen mit ihrem Netscape Navigator aus. Die Zusammenarbeit von Netscape und Sun Microsystems fand 1999 ihren Höhepunkt in der Sun | Netscape Alliance und der iPlanet-Produktfamilie.

Durch die Namensverwandtschaft mit Java und durch die C-ähnliche Syntax wird JavaScript meist als ein abgespecktes Java oder C verstanden, ohne die mächtigen Features, die es bietet, zu erahnen.

Böse Zungen behaupten, Eich hätte jeden Fehler, der je beim Design einer Programmiersprache begonnen wurde, aufgegriffen, ein paar mehr Fehler erfunden und daraus JavaScript entwickelt. Unbestritten hat JavaScript viele Schwächen. Trotzdem ist JavaScript auch die am meisten missverstandene Programmiersprache. Als JavaScript entwickelt wurde, waren die Vorbilder nämlich nicht nur C oder Java, sondern auch Self² von Sun Microsystems und Scheme³.

1.3 Das Vorbild Self

Self wurde bereits in den 1980ern als Projekt bei Xerox PARC gestartet und später bei Sun Microsystems fortgeführt. Self sollte dem Programmierer noch mehr Freiheiten im objektorientierten Programmieren bieten als das damals sehr verbreitete Smalltalk. Um dies zu erreichen, wurde Self gegenüber Smalltalk vereinfacht. Das erste Paper zu Self trug darum auch den passenden Titel: »Self: The Power of Simplicity«⁴.

Self basiert auf wenigen, einfachen Konstrukten: Prototypen, Slots und Traits. In Self gibt es, im Gegensatz zu Smalltalk, weder Klassen noch Variablen. Es wird also nicht zwischen dem Verhalten eines Objekts (den Methoden einer Klasse) und dem Zustand des Objekts (den Variablen bzw. den Eigenschaften) unterschieden. Objekte bestehen aus Slots. Slots haben einen Namen und können entweder ein Attribut oder eine Methode aufnehmen. Neue Objekte werden nicht durch das Erzeugen (fälschlicherweise inzwischen auch Instanziieren genannt) von Klassen, sondern durch Kopieren eines anderen Objekts erzeugt. Das Quellobjekt wird als Prototyp, d. h. als Kopiervorlage für das neue Objekt, benutzt. Es wird dabei sowohl das Verhalten als auch der Zustand des Objekts kopiert. Die prototypische Vererbung in Self ist also eine Weiterentwicklung der klassenbasierten Vererbung aus Smalltalk.

1.4 Das Vorbild Scheme

Scheme ist ein Lisp-Dialekt. Scheme unterstützt neben der reinen funktionalen Programmierung auch Paradigmen, die dazu im Widerspruch stehen, wie die der imperativen Programmierung. Das Grundprinzip von Scheme ist es, eine Sprache nicht dadurch mächtig werden zu lassen, indem man immer mehr Features hinzufügt, sondern indem man Einschränkungen entfernt. So gibt es in Scheme keine Objekte oder andere Paradigmen der objektorientierten Programmierung. Allerdings kann man sich solche Hilfsmittel leicht selbst programmieren. Scheme ist also eine »programmierbare Programmiersprache«.⁵ In den Sourcecode-Reposi-tories der Mozilla Foundation lässt sich noch heute eine in Lisp implementierte JavaScript-Engine finden.⁶

1.5 JavaScript und ECMAScript

Nachdem der Netscape Navigator 2 in 1995 mit JavaScript ausgeliefert wurde, entwickelte Microsoft eine zu JavaScript weitestgehend kompatible Sprache, die JScript getauft und im August 1996 mit dem Internet Explorer 3.0 ausgeliefert wurde.

Um eine Fragmentierung der Sprache zu vermeiden, reichte Netscape im November 1996 JavaScript bei der ECMA – der European Computer Manufacturers Association – ein, damit diese eine standardisierte Version unter dem Namen ECMAScript entwickeln konnte.

ECMAScript 1st Edition wurde 1997 veröffentlicht. Implementiert wurde es von JavaScript 1.2 (Netscape 4.07) und JScript 3.0 (Internet Explorer 4.0).

ECMAScript 2nd Edition wurde ein Jahr später, 1998, veröffentlicht.

ECMAScript 3rd Edition (ES3), die dritte Ausgabe von ECMAScript, erschien bereits im Folgejahr 1999. Sowohl JavaScript 1.5 (Netscape 6, Mozilla) als auch JScript 5.5 (Internet Explorer 5.5) implementieren ECMAScript 3rd Edition. Im Browserbereich ist ECMAScript 3rd Edition also die Version, die von gängigen Browsern unterstützt wird. Sie ist im Moment der kleinste gemeinsame Nenner für JavaScript-Entwickler.

Nach ECMAScript 3rd Edition war es lange ruhig um die Standardisierung von JavaScript. Erst 2005 wurde die Erweiterung ECMAScript for XML (E4X) verabschiedet. Dieser Standard fügt XML als nativen Datentyp und Funktionen, um XML zu bearbeiten, zu JavaScript hinzu.⁷ Allerdings wird E4X nicht von allen aktuellen Laufzeitumgebungen komplett implementiert.

Die ECMA plante, mit ECMAScript 4th Edition JavaScript komplett zu überarbeiten. JavaScript sollte Interfaces, Klassen, klassenbasierte Vererbung und ein statisches Typsystem bekommen. Dies rief Widerstände hervor, da diese Veränderungen dem Ursprung und der Natur von JavaScript zuwiderliefen. Diese Widerstände zwangen die ECMA dazu, die Arbeit an ECMAScript 4th Edition im Oktober 2008 einzustellen.

ActionScript, die Programmiersprache von Adobe Flash, beruht ab der Version 3.0 auf Entwürfen zu ECMAScript 4th Edition. ActionScript 3 enthält z. B. statische Typisierung und klassenbasierte Objektorientierung. Da die Arbeit an ECMAScript 4th Edition eingestellt wurde, verfolgt Adobe also einen isolierten Weg in Sachen JavaScript. ActionScript ist also nicht das »bessere« oder »weiterentwickelte« JavaScript, sondern lediglich eine Abspaltung.

1.6 ECMAScript 5th Edition

Die aktuelle Ausgabe von ECMAScript ist die 5th Edition (ES5). Einige Teile von ECMAScript 5th Edition können heute bereits verwendet werden. Diese werden neben ECMAScript 3rd Edition auch in diesem Buch behandelt. Mit ECMA-Script 5.1 wurde ECMAScript 5th Edition aktualisiert.

Strict Mode

Der Strict Mode ist ein neues Feature von ECMAScript 5th Edition. Wenn der Strict Mode aktiviert ist, dann verhält sich JavaScript nicht mehr rückwärtskompatibel zu ECMAScript 3rd Edition, sondern folgt allein den Regeln von ECMAScript 5th Edition. Alle Features, die in ECMAScript 5th Edition als »deprecated« gekennzeichnet wurden, funktionieren dann nicht mehr. Man schaltet den Strict Mode ein, indem man im Kopf eines Programms und/oder einer Funktion einen leeren String “use strict“ definiert:

"use strict";

Den Strict Mode sollte man verwenden, wenn man eigene Bibliotheken erstellen möchte, die in einer kontrollierten Umgebung verwendet werden. Der Strict Mode macht die Entwicklung einfacher, denn der JavaScript-Interpreter muss sich nicht um Rückwärtskompatibilitäten kümmern, sondern muss nur noch der ECMAScript 5th Edition folgen. Zudem sind im Strict Mode für den Interpreter mehr Laufzeitoptimierungen als im Kompatibilitätsmodus möglich. Mehr zum Strict Mode findet man im Mozilla Developer Network.⁸

1.7 Harmony

ECMAScript wird im Moment unter dem Codenamen »Harmony« weiterentwickelt hin zu ECMAScript 6th Edition (ES6). In ES6 fließen viele Ideen ein, die ursprünglich in ECMAScript 4th Edition enthalten sein sollten.

1.8 JavaScript und HTML5

In HTML5 wird JavaScript scheinbar unabhängig von der ECMA weiterentwickelt. In HTML5 werden aber lediglich neue APIs im Browser definiert. Diese neuen APIs ermöglichen es nicht nur, reichhaltigere Websites mit generierten Grafiken, Multitasking sowie Multimedia ohne Plug-ins zu erstellen, sondern sie widmen sich vor allem auch mobilem Computing (z. B. auf dem Smartphone), indem sie Offline-Fähigkeit oder ein Geo-Locations-API definieren. Die Sprache JavaScript selbst betreffen diese Erweiterungen nicht.

1.9 New Wave JavaScript

Während des »Browserkriegs«⁹ (1995–1998) zwischen Netscape und Microsoft wurden zueinander inkompatible Versionen von JavaScript entwickelt, die der professionellen Nutzung der Sprache zuwiderliefen. Im Kern waren beide JavaScript-Implementierungen identisch. Um Dokumente im Webbrowser zu verändern, wurden allerdings unterschiedliche und verschieden mächtige APIs angeboten. Diese APIs, um Dokumente im Browser zu verändern, wurden zwar auch unter dem Namen DOM – Document Object Model – standardisiert, doch waren auch die DOM-Implementierungen nicht identisch. Diese Inkompatibilität schreckte professionelle Entwickler ab. Eine weitere Inkompatibilität ist die Ajax-API (Ajax steht für Asynchronous JavaScript and XML), die es ermöglicht, Requests aus einer Website abzusetzen, ohne die Website neu zu laden.

Erst mit dem Ende des Browserkriegs und dem Aufkommen von Web 2.0-Applikationen um 2004, die Inkompatibilitäten durch Bibliotheken kapselten, richtete sich das Augenmerk der Entwickler wieder auf JavaScript.

Die erste prominente Bibliothek war Prototype, das zusammen mit Ruby on Rails ausgeliefert wurde. John Resig schrieb die Bibliothek jQuery, da Prototype einige Schwächen aufwies. Daher sind sich Prototype und jQuery sehr ähnlich.

Prototype und jQuery bilden eine Abstraktionsschicht um das DOM und um Ajax-Funktionalitäten. Man verwendet nicht mehr die native API des Browsers, sondern nur noch die API, die Prototype oder jQuery bieten. Diese rufen dann je nach Browser die passenden Implementierungen auf, ohne dass sich der Entwickler um Browser-Inkompatibilitäten kümmern muss. Zusätzlich bieten sie grafische Effekte wie animiertes Ein- und Ausblenden von Elementen.

Weitere Bibliotheken wie YUI, jQuery-UI, Moo-Tools, SproutCore und ExtJS erlauben es, anspruchsvolle Anwendungen im Browser zu erstellen, die einer Desktop-Anwendung ähneln.

GWT und Cappuccino helfen dabei, Rich-Client-Anwendungen zu schreiben, die nicht nur so aussehen und sich bedienen lassen wie eine klassische Desktop-Anwendung, sondern auch genauso programmiert werden. Googles Web Toolkit GWT kompiliert in Java geschriebene Applikationslogik zu JavaScript, sodass Java-Entwickler Applikationslogik in Java formulieren bzw. bereits existierende Logik in JavaScript wiederverwenden können. Cappuccino versucht das Gleiche mit Objective-J und Cocoa. Objective-J ist eine an Apples Objective-C angelehnte Übermenge von JavaScript. Es erweitert JavaScript um klassenbasierte Vererbung und pseudostatische Typisierung. Cocoa ist eine objektorientierte API zur Programmierung unter dem Apple-Betriebssystem Mac OS X.

1.10 Die JavaScript-Revolution

In den letzten Jahren hat sich der Webbrowser zu der wichtigsten Anwendung auf dem Desktop-Rechner und im Smartphone entwickelt. Er ist in die Domäne von ausgewachsenen Applikationen wie Mail-Clients und Office-Suiten vorgestoßen und hat scheinbar allgegenwärtige Programme wie Microsoft Outlook und Word teilweise bereits verdrängt. Anwendungslogik wandert zunehmend vom Server zum Client, vom Backend in den Webbrowser, vom Thin Client in den Smart Client.

Wenn immer mehr Anwendungslogik vom Server in den Client verlagert wird, stellt sich für einen Entwickler die Frage, ob der Rest der Anwendungslogik im Thin Server nicht in der gleichen Sprache entwickelt werden kann, die auch im Webbrowser verwendet wird. Es gibt zudem keinen logischen Grund, warum JavaScript ausschließlich im Webbrowser laufen sollte. Und es erscheint wirtschaftlich, wenn man auf eine große Zahl an Entwicklern zurückgreifen kann, die in einer einzigen Sprache programmieren. JavaScript auf dem Server könnte sicherlich nicht gewachsene SAP- oder SOA-Umgebungen, dafür aber Webframeworks wie ASP.NET, Spring MVC/Webflow oder JSF ersetzen.

Inzwischen wird JavaScript also auf dem Server interessant. Sogar Datenbanken wie Couch-DB verwenden JavaScript als native Abfragesprache. Mit ECMA-Script 5th Edition gibt es zudem in der Sprache selbst interessante neue Features.

Auch auf dem Smartphone ist JavaScript eine Sprache, in der sich Apps entwickeln lassen – kleine Applikationen, die als native Anwendungen auf dem Telefon laufen.

JavaScript im Browser ist inzwischen wohldefiniert und stabil. Inkompatibilitäten der Browser werden durch Toolkits hinreichend gekapselt. Leider gibt es außerhalb des Browsers noch keine Standardbibliotheken, um Anwendungen zu schreiben. So ist in JavaScript der Zugriff auf lokale Dateien und Netzwerk-Sockets nicht definiert. Daher lassen sich diese Features auch nicht durch ein gewöhnliches Toolkit kapseln.

In Anlehnung an Common Lisp, die Standardbibliothek von Lisp, versucht CommonJS diese Lücke zu schließen. Ein Anwendungsentwickler soll eine JavaScript-Applikation, egal ob es eine Server-, Desktop- oder Kommandozeilenanwendung ist, in verschiedenen Laufzeitumgebungen laufen lassen können. Eine Implementierung von CommonJS ist node.js, in diesem Buch kurz »Node« genannt.

1.11 Zusammenfassung

Nach diesem Kapitel sollte Ihnen bewusst sein, dass JavaScript nicht eine vereinfachte Version von Java ist, sondern ganz andere Wurzeln hat. Unterschiedliche Ausprägungen der Sprache und verschiedene Standards können Sie nun einordnen. Im nächsten Kapitel werden wir verschiedene Laufzeitumgebungen installieren, um dann praktisch mit JavaScript experimen...

Inhaltsverzeichnis

• Cover
• Titel
• Impressum
• Hingabe
• Vorwort
• Inhaltsverzeichnis
• 1 Die Geschichte von JavaScript
• 2 JavaScript-Laufzeitumgebungen
• 3 Core JavaScript
• 4 JavaScript als funktionale Programmiersprache
• 5 JavaScript als prototypische Programmiersprache
• 6 JavaScript als objektorientierte Programmiersprache
• 7 Eingebaute Objekte
• 8 Entwurfsmuster
• 9 JavaScript im Webbrowser – Teil 1
• 10 JavaScript auf dem Server mit Node
• 11 JavaScript im Webbrowser – Teil 2
• 12 Build-Automatisierung
• 13 Testen
• 14 Nachwort
• Anhang
• Fußnoten