Modern Web Dev Build: Entwicklung moderner Webapplikationen mit TypeScript

Mit eines der größten Diskussionsthemen im Bereich der Webentwicklung ist der Einsatz unterschiedlicher Frameworks und Tools. Die enorme Auswahl erschwert die Entscheidung für eine Technologie deutlich. Um Neueinsteigern diese Wahl abzunehmen, hat Sébastien Dubois ein Tool entwickelt, mit dem eine komplexe Technologiearchitektur innerhalb weniger Minuten aufgesetzt werden kann. Die erzeugte Infrastruktur deckt Themen wie Dependency Management, Buildautomatisierung, Testen, Codequalität, Minifizierung und Packen von Haus aus ab und ist dabei problemlos erweiter- und konfigurierbar.

Folgender Post basiert auf dem Modern Web Dev Build von Sébastien Dubois, welches unter GitHub dokumentiert ist.

TypeScript

Eine grundlegende Entscheidung ist der Einsatz von TypeScript, um sämtliche Features von ES2015 nutzen zu können. TypeScript ist ein typisiertes Superset von JavaScript (wobei die Typisierung optional ist), das von entsprechenden Compilern in natives JavaScript übersetzt wird. Es herrscht eine hitzige Debatte um den Einsatz von TypeScript gegenüber JavaScript, auf die ich in diesem Post nicht weiter eingehen will. Hier noch ein paar Links zu Artikeln, die genau diese Thematik hinterfragen:

Sass

Bei der Wahl für einen CSS Präprozessor hat Sébastien Dubois sich für Sass – um genauer zu sein SCSS – entschieden. Sass erweitert den Funktionsumfang von CSS an vielen Stellen. Ganz besonders die Einführung von Variablen und Funktionen erleichtert Webentwicklern den Umgang und die Wartung von CSS Code. Sass unterstützt zusätzlich die Syntax SCSS, die zwar etwas gesprächiger ist, aber direkt an die CSS3 Syntax angepasst ist. Somit ist jeder valide CSS3 Code auch gleichzeitig valides SCSS, was die Einarbeitung in die Sprache deutlich vereinfacht. In diesem Artikel wird ebenfalls der Vergleich zu einem anderen CSS Präprozessor (LESS) gezogen und erklärt, wieso man auf Sass setzen sollte.

Dependency Management: SystemJS/JSPM

Zum Laden der Abhängigkeiten wird SystemJS beziehungsweise das darauf aufbauende JSPM verwendet. Viele stellen sich jetzt möglicherweise die Frage, wieso man nicht einfach NPM – das Dependency Management Tool von NodeJS – verwendet. Die Antwort ist einfach: NPM ist für Node, also Backend, spezialisiert. JSPM enthält zusätzlich zu den Abhängigkeiten von NPM auch viele weitere, frontend-spezifische, Abhängigkeiten. Durch die Verwendung von SystemJS und der Integration des ES6 Module Loader Polyfills können Abhängigkeiten im Quellcode mit der ES6 Syntax geladen werden.

Codequalität: JSCS, JSHint & TSLint

Besonders in Projekten mit großen Teams ist es wichtig, eine einheitliche Formatierung für Quellcode vorzugeben. Dass diese tatsächlich auch von allen Teammitgliedern eingehalten werden, sind im Modern Web Dev Build gleich drei Frameworks integriert, die die Entwickler auf mangelhaften Code hinweisen: JSCS, JSHint und TSLint.

Testen: Karma & Jasmine

Testen ist auch im Bereich der Webanwendungen ein wichtiges Thema. Auch hier existieren viele Frameworks, die das Testen vereinfachen sollen. Beim Modern Web Dev Build wurde auf Karma gesetzt. Karma wird zur Ausführung der Tests verwendet. Die eigentlichen Testfälle werden mit Jasmine geschrieben. Da Karma auch andere Testframeworks unterstützt, können alternativ auch Mocha und QUnit eingesetzt werden.

Buildautomatisierung: Gulp

Die Buildautomatisierung ist wohl eines der komplexesten Themen, wird allerdings vom Modern Web Dev Build komplett vorgegeben und eingerichtet.
Zur Vereinfachung des Buildvorgangs wird der weit verbreitete Taskrunner Gulp verwendet. Der Buildvorgang, der beim Ausführen von npm start (ruft intern gulp serve auf) durchgeführt wird, setzt sich aus neun Schritten zusammen.

  1. Ausgabeordner leeren
  2. TypeScript mit TSLint analysieren
  3. JavaScript Codestyle prüfen
  4. JavaScript Codequalität mit JSHint prüfen
  5. TypeScript in ECMAScript 6 übersetzen und Sourcemaps erzeugen
  6. ECMAScript 6 Code in ECMAScript 5 Code übersetzen und Sourcemaps erzeugen
  7. SCSS kompilieren und Sourcemaps erzeugen
  8. package.json validieren
  9. Server starten

Die Definition des eigentlich Gulp Tasks befindet sich in der Datei node_modules/modern-web-dev-build/dist/gulp/serve.js.
Ein weiterer wichtiger Teil des Builds ist das Packen und die Minifizierung. Beim Packen werden alle Ressourcen eines Typs (CSS, HTML, TypeScript) in eine Datei gepackt, was die Anzahl der http Requests – und somit die Ladezeit – der späteren Applikation reduziert. Nach dem Packen werden die gepackten Dateien minifiziert. Das bedeutet, dass alles, was im produktiven Einsatz überflüssig ist wie beispielsweise Quellcodekommentare oder Whitespace, entfernt wird. Außerdem werden Variablennamen durch vereinfachte Namen (meist einzelne Buchstaben) ersetzt. Durch diesen Vorgang reduziert sich die Dateigröße, was wiederum die Ladezeit verringert. Außerdem wird durch die Minifizierung der Code schwerer lesbar und somit auch schwerer für andere, den Code wiederzuverwenden. Allerdings hat die Minifizierung auch zur Folge, dass das Debugging drastisch erschwert wird. Daher werden bei der Ausführung von gulp serve die Dateien nicht gepackt und auch nicht minifiziert. Hierzu existiert ein weiterer Befehlt namens gulp serve-dist.

Hands On

Das Aufsetzen eines neuen Projekts ist dank des generator-modern-web-dev NPM Pakets extrem einfach. Folgende Befehle reichen aus, um die komplette Infrastruktur zu bilden: (es muss NPM installiert und in der PATH Variable eingetragen sein)

npm install --global yo
npm install --global generator-modern-web-dev
npm install --global gulp

Dann in den Ordner navigieren, in dem die Projektdateien gespeichert werden sollen. Es wird kein Unterordner für das Projekt erstellt! Anschließend einfach folgenden Befehl ausführen:

yo modern-web-dev

Das Tool fragt anschließend einige grundlegende Dinge wie Projektname, Beschreibung und noch einiges mehr. Anschließend werden über Yeoman (yo) alle Dateien erstellt und befüllt, sodass eine AngularJs Hello-World Webapplikation verfügbar ist.

Die erzeugte Dateistruktur gibt eine recht klare Definition vor, in welchem Ordner welche Dateien abgelegt werden soll. Wenn diese Regeln eingehalten werden, entsteht eine gut strukturierte Anwendung, die einfach gewartet werden kann und auch für Einsteiger einfach zu verstehen ist:

  • Projektverzeichnis
    • app: Enthält allen selbstgeschriebenen Quellcode
      • components: Enthält die modularisierten Komponenten der Applikation
      • core: Enthält den Einstiegspunkt der Applikation
        • commons: Enthält häufig wiederverwendeten Code
        • services: Enthält Services
        • boot.ts: Der Einstiegspunkt der Applikation
        • app.ts: Das Grundmodul der Applikation
      • fonts: Enthält Schriftarten
      • images: Enthält Bilder
      • pages: Enthält templates für Seiten
      • styles: Enthält grundlegende Stylesheets, modulspezifische Stylesheets sollen direkt beim Modul abgelegt werden
        • main.scss: Bündelt alle eigenen CSS-Dateien
        • vendor.scss: Bündelt alle CSS-Dateien von verwendeten Bibliotheken
      • index.html: Das Template zum Einstiegspunkt der Applikation
    • .babelrc: Babel Konfigurationsdatei
    • .jscsrc: Enthält Styleregeln für JavaScript-Code
    • .jshintrc: Enthält JSHint Regeln
    • .jshintignore: Enthält von JSHint ignorierte Dateien/Ordner
    • gulpfile.babel.js: gulp Konfigurationsdatei
    • jspm.conf.js: SystemJS/JSPM Konfigurationsdatei
    • karma.conf.js: Karma Konfigurationsdatei
    • package.json: NPM/JSPN Konfigurationsdatei, enthält eine Auflistung aller Abhängigkeiten
    • tsconfig.json: TypeScript Comiler Konfiguration
    • tslint.json: Regeln zur TypeScript Codequalität

Zum Ausführen der Applikation reicht der Befehl

npm start

oder wahlweise

gulp serve

Der Buildvorgang wird nun angestoßen und der Server gestartet. Anschließend steht die Applikation unter folgender URL zur Verfügung: http://localhost:3000

Short URL for this post: http://wp.me/p4nxik-2HW
This entry was posted in Web as a Platform and tagged , , , , . Bookmark the permalink.

One Response to Modern Web Dev Build: Entwicklung moderner Webapplikationen mit TypeScript

  1. mugwump64 says:

    everyting including the kitchen sink :) do you have some long(er)-term experiences with this?!

    Although I really appreciate the decision-making in a field that has become awfully crowded and tools appearing and disappearing in a matter of weeks, these are many moving parts – all fine, when it works, but with the often brittle state of js-frameworks, this is likely to break at some point. If at this point you don’t know **all** the moving parts really good, fixing issues can be a real pain…

    What are your experiences with this approach in the long term – especially if you compare this with an approach where you bring in one tool at a time and let things settle and stabilize before moving on?

    PS: And Eventually, you will have to have intimate knowledge of most of these tools, as they outdate and are abandoned pretty fast these days (e.g. moving on from browserify to webpack to jspm to …)) – so replacing one or the other part will also become an issue over time.

Leave a Reply