Um eine Cross-Platform-App mit HTML5 und JavaScript zu entwickeln, müssen wir zunächst ein paar Grundlagen legen. Für viele wird dieser Post ein alter Hut sein, dann müsst ihr leider auf den nächsten Post warten und mit dem weiter machen. Allen anderen möchte ich an dieser Stelle einige Tools und Vorgehensweisen bei der JavaScript-Entwicklung ans Herz legen. Damit der Artikel nicht zu umfangreich ist, werde ich an vielen Stellen nur an der Oberfläche kratzen, jedoch im weiteren Verlauf der Serie auf die hier beschriebenen Grundlagen aufbauen und auch von der hier aufgebauten Umgebung ausgehen.
Editor
Beim Thema des passenden Editors scheiden sich die Geister. Ich halte diesen Abschnitt sehr kurz – ich komme aus der C#-Welt und arbeite bereits sehr lange mit dem Visual Studio, daher wird in meinen Posts auch diese Entwicklungsumgebung eingesetzt. Alternativen gibt es jede Menge, ob dies nun Visual Studio Code, WebStorm oder auch Notepad++ oder VI sind. Mit allen kann man programmieren und sein Ziel erreichen.
Hier wird Visual Studio 2015 Enterprise eingesetzt und im Installationsprozess zusätzlich zum Standard noch die Cordova Erweiterung mit installiert (siehe https://www.visualstudio.com/en-us/features/cordova-vs.aspx). Damit werden mehrere SDKs und Node.js mit auf den Rechner geholt. Außerdem habe ich noch die Git und GitHub-Erweiterungen aktiviert.
Node.js
Jeder, der sich in den letzten Jahren mit JavaScript näher befasst hat, ist an Node.js (https://nodejs.org) nicht vorbei gekommen. Ganz grob gesagt, ist Node.js eine auf Chrome’s V8 Engine basierende JavaScript Runtime, die nicht auf den Browser angewiesen ist, sondern direkt im Betriebssystem läuft – mit dem Vorteil, dass es die Runtime für viele verschiedene Betriebssysteme gibt. Möchte man Node.js nutzen ohne die Visual Studio Cordova Erweiterung installiert zu haben, so lädt man sich die Runtime von der Webseite, installiert sie und schon kann man mit dem Befehl „node script.js“ direkt JavaScript ausführen.
Rund um Node hat sich eine enorme Community und ein riesiges Ökosystem gebildet. Eine der Grundlagen dieses Gesamtsystems ist der Paketmanager npm, der im nächsten Abschnitt noch näher betrachtet wird.
Paketmanager
Im “Node-Universum” gibt es mehrere Paketmanager, von denen ich drei kurz vorstellen möchte. Hierbei handelt es sich um den bereits angesprochenen Node Package Manager (npm – npmjs.com) sowie bower (bower.io) und jspm (jspm.io).
Während npm für quasi alles im Bereich der JavaScript Pakete eingesetzt wird, konzentrieren sich bower und jspm auf Pakete, die im Browser laufen.
Paketmanager: NPM
Nur um eine ungefähre Vorstellung der Dimensionen von npm zu bekommen, möchte ich hier ein paar Zahlen (die natürlich bereits beim Lesen dieses Eintrages nicht mehr aktuell sind) aufführen. Aktuell umfasst das Package-Repository von npm 196.689 Pakete und innerhalb des letzten Monats wurden 2.294.816.222 Downloads über npm durchgeführt. Alleine diese Statistik zeigt schon die enorme Beliebtheit, derer sich JavaScript aktuell erfreut.
Mit npm lassen sich Pakete sehr einfach installieren und verwalten. Einmal installiert, genügt im gewünschten Basis-Verzeichnis der Befehl “npm init” und die Beantwortung einiger Fragen wie Projekt-Name, aktuelle Version, Beschreibung, etc. wonach npm dann eine Datei package.json anlegt. Damit haben wir ein npm-Projekt angelegt und können unsere Pakete verwalten. In der package.json werden die angegebenen Basisdaten zum Projekt hinterlegt und installierte Pakete können darin mit der gewünschten Version gespeichert werden.
Zur Installation eines Pakets nutzt man den Befehl “npm install”, wobei mit dem zusätzlichen Parameter “–save” dieses Paket auch direkt in die package.json eingetragen wird – z.B. “npm install jquery –save”. Hier lässt sich zusätzlich noch einmal unterscheiden, ob es sich bei dem Paket nur um eine Entwicklungsabhängigkeit oder um ein Paket für die Anwendung handelt indem der Befehl “–save” noch um ein “-dev” erweitert wird, zum Beispiel “npm install gulp –save-dev”. Aus den hier aufgeführten Befehlen würde dann die folgende package.json resultieren:
{
„name“: „npm-demo“,
„version“: „1.0.0“,
„description“: „Ein einfaches NPM-Demo Projekt“,
„main“: „index.js“,
„scripts“: {
„test“: „echo \“Error: no test specified\“ && exit 1″
},
„keywords“: [
„npm“,
„demo“
],
„author“: „Jochen Kluger“,
„license“: „Apache v2“,
„dependencies“: {
„jquery“: „^2.1.4“
},
„devDependencies“: {
„gulp“: „^3.9.0“
}
}
Neben der package.json finden wir außerdem in unserem Verzeichnis nun den Ordner “node_modules”. Hier speichert npm die Pakete in jeweils eigenen Ordnern und gegebenenfalls darin wieder in einem “node_modules” Verzeichnis deren Abhängigkeiten. Nutzt man bei der Entwicklung ein Quellcodeverwaltungssystem (was in jedem Fall zu empfehlen ist) so sollte der “node_modules” Ordner nicht mit eingechecked werden. Die Pakete können jederzeit neu heruntergeladen werden – Visual Studio übernimmt dies in der neuesten Version sogar selbst.
Paketmanager: Bower
Während npm den Fokus eher auf JavaScript legt, möchte Bower alles, was der Entwickler im Browser benutzt als Pakete anbieten. Hier möchte ich kurz eine Aussage von der Bower-Webseite zitieren – das umschreibt das Ziel am Besten:
“Web sites are made of lots of things — frameworks, libraries, assets, utilities, and rainbows. Bower manages all these things for you.”
Ansonsten hat Bower sehr ähnliche Ansätze wie npm. Zur Installation von Bower kann man einfach npm mit dem Befehl “npm install bower –save-dev” benutzen und schon kann man seine Frontend-Abhängigkeiten mit bower verwalten. Auch hier beginnt man am Besten mit dem Befehl “bower init”, worauf man einige Fragen beantworten muss. Danach findet man eine bower.json Datei im Verzeichnis, in der die gemachten Angaben und die verwalteten Pakete gespeichert werden. Auch hier stehen wieder die zusätzlichen Parameter “—save” und “—save-dev” zur Verfügung.
Bower Pakete können aus unterschiedlichen Quellen eingebunden werden. Hier sind neben der Bower-Registry auch GitHub oder einfache URLs möglich. Hier ein kurzes bower.json-Beispiel:
{
„name“: „bower-demo“,
„version“: „0.0.0“,
„authors“: [
„jochenkluger <jochen/at/kluger.net>“
],
„description“: „Eine kurze Bower-Demo“,
„main“: „index.js“,
„moduleType“: [
„amd“
],
„keywords“: [
„bower“,
„demo“
],
„license“: „Apache v2“,
„homepage“: „“,
„private“: true,
„ignore“: [
„**/.*“,
„node_modules“,
„bower_components“,
„test“,
„tests“
],
„dependencies“: {
„jquery“: „~2.1.4“,
„bootstrap“: „~3.3.5“
}
}
Paketmanager: JSPM
JSPM ist der neueste Vertreter unter den aufgeführten Paketmanagern. Während die Pakete bei npm und bower während der Entwicklung geladen und zum Beispiel als feste URL in eine Webseite eingebunden werden, setzt jspm auf system.js auf. Das bedeutet, dass hier eine Technik zugrunde liegt, die eigentlich erst in ECMAScript 6 wirklich Einzug hält und bisher nur als Draft vorliegt. Damit ist es hier recht wahrscheinlich, dass es noch zu Änderungen kommen wird. Über Polyfills lässt sich diese Technik jedoch heute schon einsetzen und auch in aktuellen JavaScript-Engines nutzen. Der Einsatz von Polyfills und system.js funktioniert meiner Erfahrung nach bereits sehr gut – ob man jetzt schon darauf setzen möchte, muss jedoch jeder selbst entscheiden.
jspm ist prinzipiell so designed, dass verschiedene Registries benutzt werden können. Aktuell werden die npm-Registry und gitHub unterstützt.
Auch hier beginnt man am Einfachsten, indem man über npm zunächst jspm installiert (“npm install jspm –save-dev”) und dann den Befehl “jspm init” ausführt. Auch hier müssen zunächst einige Fragen beantwortet werden – unter anderem, ob jspm seine Pakete in der package.json (ja, der von npm) eintragen soll und ob man einen Transpiler benutzen möchte, der aus dem ECMAScript6 aktuellen JavaScript Code erzeugt. Anschließend sieht die oben bereits dargestellte package.json Datei folgendermaßen aus – hier sieht man deutlich, dass jspm lediglich einen eigenen Abschnitt eingefügt hat:
{
„name“: „npm-demo“,
„version“: „1.0.0“,
„description“: „Ein einfaches NPM-Demo Projekt“,
„main“: „index.js“,
„scripts“: {
„test“: „echo \“Error: no test specified\“ && exit 1″
},
„keywords“: [
„npm“,
„demo“
],
„author“: „Jochen Kluger“,
„license“: „Apache v2“,
„dependencies“: {
„bower“: „^1.6.3“,
„jquery“: „^2.1.4“
},
„devDependencies“: {
„gulp“: „^3.9.0“,
„jspm“: „^0.16.13“
},
„jspm“: {
„directories“: {
„baseURL“: „www“
},
„dependencies“: {
„jquery“: „github:components/jquery@^2.1.4“
},
„devDependencies“: {
„traceur“: „github:jmcriffey/bower-traceur@0.0.92“,
„traceur-runtime“: „github:jmcriffey/bower-traceur-runtime@0.0.92“
}
}
}
jspm bietet hier mit der system.js-Basis eine sehr gute Integrationsmöglichkeit, um direkt im JavaScript-Code auf Module zuzugreifen zu können, ohne sich großartig Gedanken um die Referenzierung machen zu müssen. Gerade wenn man umfangreiche JavaScript-Anwendungen entwickelt, vielleicht selbst bereits eine Modul-Struktur wie AMD, common.js oder ähnliches benutzt oder einsetzen möchte, ist jspm auf jeden Fall einen genaueren Blick wert.
So viel erst einmal zu den Grundlagen für die HTML5 / JavaScript-Entwicklung. Wie in vielen anderen Bereichen der Informatik auch, gibt es hier viele Wege, die man gehen kann und die auch (fast) alle ans Ziel führen. Im nächsten Artikel werde ich näher auf den Aufbau der Entwicklungsumgebung und den Build eingehen. Für die weiteren Schritte in dieser Serie werde ich einen weniger dynamischen Weg gehen und nur npm als Paketmanager einsetzen. Eventuell ist das dann eine gute Basis, um eine mögliche Umstellung auf jspm zu zeigen 😉
Neueste Kommentare