senäh

17senäh und so…

HTML5 Logo Thumbnail 2

HTML/CSS/JS
14. Feb 2014
Kommentare: 3

Mein Trend 2014: Pre- und Postprocessing mit der selben Programmiersprache

Kategorien: HTML/CSS/JS | 14. Feb 2014 | Kommentare: 3

Mit der Übersetzung von einer Programmiersprache in eine andere hat sich fast jeder von uns bereits einmal auseinander gesetzt. Sei es Java mit GWT nach JavaScript zu kompilieren oder Less nach CSS. Das ganze wird häufig als Preprocessing beschrieben und war in der letzten zwei, drei Jahren ein hippes Thema im Front-End-Bereich. Als Stichwörter seien CoffeeScript, TypeScript, Sass, Less, Jade oder HAML genannt. Im Wesentlichen geht es – vor allem im Frontend – darum, dass die zur Verfügung gestellte Laufzeitumgebung (= der Browser) einige Restriktionen besitzt (= Technologie festgelegt auf HTML, CSS und JS) und man diese Restriktionen während der Entwicklung durch den Einsatz anderer Programmiersprachen umgehen möchte.

Das klappt in gewissen Grenzen sehr gut. Die Programmiersprachen können sich von der Entwicklungs- zur Laufzeitumgebung teilweise sehr unterscheiden (Java → JavaScript), können aber auch sehr ähnlich sein (Less → CSS). Das hat sowohl Vorteile (bestehende Java-Entwickler müssen kein JavaScript lernen), aber auch Nachteile (bestehende JavaScript-Entwickler müssen Java lernen^^). Teilweise ergeben sich auf diese Weise aber auch Tooling-Probleme: So bietet Brackets eine tolle Möglichkeit HTML live zu bearbeiten, aber diese Funktion kann nur ohne Preprocessors verwendet werden.

Eine im Front-End-Bereich (noch) etwas unbekanntere Form den Quellcode eines Programms zu verändern ist das Postprocessing. Hierbei wird der “eigentlich” fertig Quellcode eines Programms – welcher so auch identisch im Git-Repo eingecheckt ist – genommen und nachträglich noch verändert. Ein guter Anwendungsfall dafür ist das Prefixen von CSS-Eigenschaften. So kann ich in meinem CSS einmalig sagen, dass meine Buttons einen border-radius verwenden sollen und gebe keine zusätzliche Browser-Prefixes an. Stattdessen könnte Jenkins einmal im Monat überprüfen, wie meine reale aktuelle Browsermatrix ist und ggf. einen -webkit- vor allen border-radius schreiben, wenn ich besonders viele alte Android-Nutzer habe :) (Für diese Aufgabe gibt es das Projekt autoprefixr.)

Postprocessors geben die Richtung schon vor: Eine Sprache wird verändert und die selbe Sprache wieder ausgegeben. Der gleiche Weg kann mit Preprocessors gegangen werden. Dabei wird mit einer Sprache entwickelt, die nach einem Build-Schritt auch wieder ausgegeben wird. Aber warum sollte man das machen? Ein gutes Beispiel ist der Weg den Ember (und zuvor im Prinzip auch TypeScript) jetzt geht: Dort werden alle Module nach dem ES6-Standard geschrieben, der zukünftigen neuen Version von JavaScript. Nach einem Build-Schritt entsteht jedoch vor-ES6-standardkonformer JavaScript-Code, welcher auch heute in alten Browser funktioniert. Der neue Modulstandard ist einfacher als alte Modulstandards (einen echten Modulstandard gab zuvor eigentlich noch gar nicht), man arbeitet zukunftssicher und standardkonform. Das Traceur-Projekt versucht so viele neue ES6-Features wie möglich auf diese Weise zu forward polyfill‘en und ermöglicht so bspw. die Verwendung von Defaultparametern. TypeScript ist dem sehr ähnlich und erweitert das ganze noch um Nicht-ES6-Features wie Typen.
Ein weiteres Beispiel ist der CSS-Preprocessor rework, welcher im Wesentlich aus einem CSS Parser und Stringifier besteht, der das Modifzieren von CSS erlaubt. (Das ganze geht in die Richtung static metaprogramming. Eine Einführung zu diesem Thema mit Bezug auf JS gibt es hier.) Auf diese Weise lassen sich bspw. komplett neue CSS-Eigenschaften erstellen. So könnte ich border-top-radius: 5px; als neue Eigenschaft definieren, welche dann nach border-top-left-radius: 5px; border-top-right-radius: 5px; kompiliert wird. Ein weiteres Beispiel wäre es die @import Syntax von CSS so zu modifizieren, dass sie Bower Packages und die in der bower.json hinterlegten "main" Dateien importieren kann. (In der Tat gibt es ein rework Plugin, welches genau das mit npm Packages macht!)

Auf diese Weise können auch ganze neue Tools entstehen. So modifiziert der Theseus-Debugger euer JavaScript zur Laufzeit, um mehr Debuginformationen zu erhalten. (Genau genommen ist es damit eigentlich kein Pro- oder Postprocessor, sondern eine Art While-Running-Processor. :) Eher bekannt als dynamic code analysis.)

JavaScript Processing

Ein Nachteil der dabei noch entsteht, ist der fehlende IDE-Support für eigene Regeln. Wenn ich über @import im CSS bspw. ein Bower Package laden möchte, kennt meine IDE nur Pfade und URLs und keine Bower Packages. Ich hoffe, dass Projekte wie Tern dem in Zukunft etwas entgegenkommen. Tern ist ein selbstständiges JavaScript-Analyse-Framework, welches einem bspw. in jedem beliebigen Textfeld auf einer Webseite JavaScript-Autocompletion und -Refactoring geben könnte. Durch solche Projekte lassen sich in Zukunft wichtige IDE-Funktionen fasst per Plug&Play in jedem Textfeld nachrüsten. (Ja, ich habe hier die rosarote Brille auf. :) )

Natürlich kann es wie immer auch ganz anders kommen, aber diese Entwicklungen sind auf jeden Fall sehr inspirierend! :)

Autor: Pipo

...kommt ursprünglich aus der Designerecke, ist aber im Laufe seines Studiums in die Webentwicklung gestolpert. Kann sich seit dem nicht so richtig entscheiden wo er hingehört und wagt deswegen vielleicht die Flucht nach vorne in ein komplett neues Gebiet. Vielleicht Management? Niemand weiß es. Auch er nicht.

Kommentare (3)

  1. Pingback: ugoArangino – Pre- und Postprocessing mit der selben Programmiersprach

  2. Bislang kaum Kommentare? Wohl weil sich dem aufgrund der Informationsdichte nicht viel hinzufügen vermag? Vielen Dank für den Rundumschlag zum gefühlt aktuellen Stand von morgen. Einige Ideen sind nun schon intern zur Begutachtung eingetütet.

  3. Hehe, danke :)

    Mein Prognosen scheinen sich übrigens stark zu bewahrheiten. Projekte wie “sweet.js” (Macros in JavaScript) sind zurzeit sehr beliebt :)