Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Stets zu Diensten: Yeoman

Frontendentwicklung

Stets zu Diensten: Yeoman

Moderne Frontendentwicklung benötigt viele Bibliotheken und Werkzeuge. Yeoman verspricht, diese als installierbare Pakete zugänglich zu machen und in einen einheitlichen Workflow zu packen.

In der zeitgenössischen Web-Entwicklung benutzt der Entwickler immer mehr und ausgefeiltere Werkzeuge, Bibliotheken und Frameworks. Die Integration in das eigene Projekt kann eine mühsame Arbeit sein: Quelle im Web finden, Download, Einbinden, vor der Auslieferung auf den Server alles zusammenpacken, um HTTP-Requests zu sparen, usw., usw…

Hier kommt Yeoman ins Spiel, »eine robuste und meinungsfreudige Sammlung von Werkzeugen, Bibliotheken und einem Workflow, der Entwicklern helfen kann, schnell schöne und überwältigende Web-Anwendungen zu erstellen«. Der Name »Yeoman« leitet sich von den Yeoman Warders ab, den zeremoniellen Torwächtern des Towers von London, deren Hut und Uniform das Vorbild für das putzige Logo von Yeoman stellen.

Yeoman ist ein merkwürdiges Ding. Es ist sowohl ein Meta-Paketmanager, aber auch ein Entwicklungs-Server, und auch ein Code-Generator, der ein Grundgerüst einer Web-Anwendung mit den ausgewählten Bibliotheken und Frameworks erstellt. Es ist »opiniated« in der Hinsicht, dass die Entwickler, Paul Irish und Addy Osmani, die Ansicht vertreten, dass Web-Entwicklung vom Einsatz vorhandener Tools profitiert, wie das in einem Vortrag auf der Google I/O 2012 eingeführt und einem Blogeintrag von Addy Osmani weiter erläutert wird. Wie bei vielen Developer-Frameworks kann man sich dieser Meinung anschließen oder eben nicht. Sinnvoll ist der Einsatz von Yeoman nur, wenn man Gefallen an dem »Tooling«-Ansatz gefunden hat.

Installation

Vor der Nutzung muss Yeoman installiert werden. Yeoman hat keine grafische Oberfläche, sondern arbeitet komplett in der Shell im Terminal. Es läuft unter OSX, Linux und Windows. Für letzteres (die »Shell« in Windows ist bei der Arbeit mit solchen Werkzeugen bekanntlich stets problematisch) sollte der Entwickler die Hinweise in der Installationsanleitung und einen Blogartikel bei Decodize beachten.

Yeoman ist im Grunde nichts weiter als ein node.js-Modul und braucht deshalb bestimmte Voraussetzungen, um seinen Dienst antreten zu können. Die Installation prüft die Umgebung und gibt Hinweise, was noch installiert werden muss. Wie das neuerdings (schlechte) Praxis ist (man sollte solche Skripte aus dem Web nicht direkt ausführen, ohne sie sich vorher einmal angeschaut zu haben), läuft das über ein aus dem Web geladenes Shell-Script, das direkt an die Bash übergeben wird:

  1. curl -L get.yeoman.io | bash

Führt der Entwickler das im Terminal aus, wird er mit einem hübschen »Yeoman« als Ansi-Shell-Grafik sowie einer Liste vorhandener oder zu installierender Werkzeuge belohnt:

Yeoman Installation

Neben einigen betriebssystemspezifischen Voraussetzungen (so müssen unter OSX die XCode-Command-Line-Tools und Homebrew vorhanden sein) benötigt der Yeoman diverse Pakete, deren (Nicht-)Präsenz in der Ausgabe des Installationsskripts angegeben wird. Hat der Entwickler sich die notwendigen Pakete besorgt (wie man das auf dem jeweiligen OS macht steht wieder in der Installationsanleitung auf github), muss noch Yeoman selbst installiert werden. Das wird mit dem node-Paketmanager npm erledigt. Dieser installiert eine Menge benötigter node.js-Module und zum Schluss den yeoman selbst. Damit steht dem ersten Einsatz nichts mehr im Wege.

Yeoman benutzt Compass und Sass, um Stylesheets zu kompilieren (sofern man das nicht explizit beim Einsatz von Yeoman abschaltet). Es sollten die neuesten Versionen von Compass und Sass verwendet werden. Mit älteren Versionen funktioniert Yeoman nicht korrekt.

Einsatz

Wie bereits erwähnt: Yeoman arbeitet ausschließlich auf der Kommandozeile in der Shell. Der Entwickler benutzt das Kommandozeilen-Programm yeoman, um die unterschiedlichen Aufgaben des Yeoman auszuführen. Ohne jede Option abgeschickt listet yeoman die verfügbaren Optionen auf:

Yeoman Optionen

Das Kommando yeoman init erzeugt das Gerüst (engl. »scaffold«) eines neuen Projekts. Dazu erstellt der Entwickler ein neues Verzeichnis, führt yeoman init aus und beantwortet die dabei aufkommenden Fragen (wie z.B. ob man sein CSS mit Compass bauen möchte). Danach fängt Yeoman an zu arbeiten, besorgt die benötigten Pakete und erstellt das Gerüst einer neuen Webapp, die fix und fertig die benötigten Tools wie Bootstrap, jQuery, Modernizr sowie – sofern bei init entsprechend angefordert – Source-Dateien für Compass/Sass und Coffeescript enthält:

Yeoman bei der Arbeit

Im Verzeichnis app legt Yeoman den Source der neuen Webapp ab:

Yeoman-Struktur

Mit yeoman build kann der Entwickler daraus eine fertige Webapp erzeugen. In »Meta-Sprachen« wie Compass, Coffeescript oder Sass angelegte Ressourcen werden dabei kompiliert und in den Verzeichnisbaum unter dist (wie »Distribution«) abgelegt; ebenso werden vorhandene Bilder in ihrer Größe optimiert. dist enthält danach die fertige auslieferungsbereite Webapp.

Wie macht Yeoman das? Es nutzt das Build-Tool grunt für den eigentlichen Task des »Kompilierens« der fertigen App (siehe auch unseren Artikel »(Bessere) Projekt-Pakete schnüren mit Grunt«). Das ist typisch für Yeoman: Statt alles selbst zu entwickeln, setzt es einen Rahmen, in den vorhandene Tools dann eingebunden werden, um die eigentliche Arbeit zu erledigen. »Tooling« ist der zu gehende Weg in der Yeoman-»Philosophie«.

Mit yeoman server oder yeoman server:dist (bei letzterem wird der Build in dist als Basis genommen, ansonsten wird es aus den Sourcen in app frisch erzeugt) startet der Entwickler einen Entwicklungsserver auf http://localhost:3501, so dass das Werk im Browser angeschaut werden kann:

Yeoman im Browser

Pakete installieren

Weitere Pakete kann der Entwickler mit yeoman install nachinstallieren. Yeoman hat dazu Bower integriert und nutzt dessen Repository. Mit yeoman search kann der Entwickler nach einem Paket suchen. Benötigt er z.B. jquery-ui, so findet er mit yeoman search jquery-ui das entsprechende Paket, das dann mit yeoman install jquery-ui in das aktuelle Projekt integriert werden kann. yeoman search ohne einen weiteren Parameter listet alle verfügbaren Pakete und Bibliotheken auf.

Fortgeschrittene Anwendungen

Eine Webapp mit Boilerplate, Bootstrap, jQuery und ein wenig Sass/Compass mit dem Yeoman zu erzeugen, ist ganz nett und fühlt sich recht integriert an. Das würde der Entwickler aber auch ohne größere Mühe »von Hand« hinbekommen. Interessant wird Yeoman mit seinen Generatoren bei der Erstellung komplexerer Client-seitigen Webapps. Möchte der Entwickler bspw. das Web-Anwendungs-Framework backbone.js benutzen, so greift der Yeoman dabei hilfreich unter die Arme. Backbone.js arbeitet ähnlich einem serverseitigen MVC-Framework wie Rails oder Django und kennt zur Strukturierung des Codes Models, Collections und Views. Diese benötigten Komponenten können alle mit yeoman-Kommandos erzeugt werden.

Yeoman installiert mit yeoman init backbone eine Basis-Backbone-js-Anwendung. Alle verfügbaren Optionen für init listet das Kommando yeoman init --help auf. Neben Backbone finden sich auch andere Frameworks wie Ember oder Angular im Angebot, sogar ein Rahmen für eine Chromeapp kann erzeugt werden.

Komponenten der Backbone-App kann der Entwickler ebenfalls mit init hinzufügen. Ein Backbone-Model namens »Article« wird zum Beispiel mit yeoman init backbone:model article angelegt. Auch für Collections, Views usw. kann der Yeoman-Code-Generator die entsprechenden Dateien erzeugen.

Da komplexere Anwendungen auch automatisch getestet werden sollten, legt Yeoman ein Verzeichnis test an und besitzt einen Generator für das JS-Test-Framework Mocha.

Fazit und Ausblick

Yeoman ist ein vielversprechender Ansatz, die heterogene Landschaft der Client-seitigen Frameworks, Bibliotheken und Werkzeuge unter einer einheitlichen Oberfläche verfügbar zu machen. Teilt man den »Tooling«-Ansatz der beiden Yeoman-Entwickler ist Yeoman ein nützlicher Helfer bei der Arbeit mit den verfügbaren »Tools«. Yeoman ist »opiniated«. Ein Workflow zur Erstellung einer Web-Anwendung sieht nach Meinung von Yeoman so aus:

  • Anlegen der Anwendung mit yeoman init.
  • Installation der benötigten Bibliotheken und Pakete mit yeoman search und yeoman install.
  • Erzeugen von Code mit dem Generator in yeoman init ..._.
  • Entwicklung mit dem Server mittels yeoman server.
  • Distribution der fertige Anwendung mit yeoman build.

Möchte der Entwickler sich nicht auf die Arbeit in diesem Workflow einlassen, macht der Einsatz des Yeoman wenig Sinn.

In serverseitigen Frameworks wie Rails oder Django schätzen Entwickler die Generatoren und Paketmanager zur vereinfachten Arbeit mit dem Framework. Yeoman hat das Zeug, ein solches Werkzeug für die Entwicklung client-basierter Web-Anwendungen auf Basis populärer Javascript-Frameworks wie backbone.js oder Ember zu werden.

Yeoman ist ein junges Projekt und in Bewegung. In Zukunft sollen z.B. die Yeoman-eigenen Wrapper um Werkzeuge wie grunt und Bower reduziert werden und die erzeugten Projekte auch ohne Yeoman mit grunt gepflegt werden können. Diese und weitere Pläne haben die Entwickler in einem Beitrag zur Diskussion gestellt.

Kommentare

Christian
am 14.12.2012 - 14:04

In unserer Agentur arbeiten 2 Mediengestalter am Frontend (HTML/CSS), sowie 3 Programmierer für PHP Anwendungen im Backend bzw. CMS, Tools, etc.

Mich würde mal interessieren, wie Eure Meinung ist? Wird sich in den nächsten 10 Jahren die Frontendentwicklung immer mehr in den Programmierbereich verschieben, oder wird es weiterhin auch die Dreamweaver Nutzer in Agenturen geben? Mit Sass/Compass oder auch hier mit yeoman merkt man schon, dass die Tools mehr und mehr in die Programmier/Entwickler Ecke gehen.

Permanenter Link
Ralf Graf

Ralf Graf (Autor)
am 15.12.2012 - 10:53

Schwierig zu sagen. Ich finde es ja eher erstaunlich dass es überhaupt noch Dreamweaver-Nutzer gibt. ;-)

So ein typischer "der Designer malt mit Photoshop ein Layout - der Frontend-Entwickler klöppelt das dann in HTML - und der Programmierer schneidet es in Stücke und setzt es in die CMS/Anwendung rein"-Workflow erscheint mir sowieso nicht der effektivste Weg zu sein, im Frontend wird der Übergang zwischen HMTL-Seiten-Bauen und "Programmieren" noch fließender werden als es es ohnehin schon ist und in der oben skizzierten Kette scheint der Dreamweaver-HTML-Layout-Bauer der verzichtbare Teil zu sein.

Aber das sind nur meine 2 Eurocent, gerade Agenturen hängen scheinbar an ihrer "jeder Job hat sein Spezialgebiet und nur das"-Struktur, sowas kann zäh sein in seinem Behauptungswillen.

Permanenter Link

Die Kommentare sind geschlossen.