JavaScript

• Allgemein JavaScript ansich ist Copyright-behaftet, deswegen heißt der Standard ECMAScript. Dieser Fakt ist nicht unbedingt jedem bekannt, sollte aber immer mal im Hinterkopf gehalten werden, wenn ein neuer Standard der Sprache erscheint. Als Prototypen-Sprache macht Javascript nun schon seit einigen Jahren immer mehr die Rede von sich, sei es als neue Engine im Microsoft Edge-Browser (dort heißt sie Chakra), oder als Nicht-Browser-Implementierung z.B. NodeJS (die Bezeichnung serverseitiges Javascript wäre hier absolut falsch, da NodeJS auch in der Entwicklung auf dem Entwickler-PC eingesetzt wird).

• Meine Anfänge mit Javascript Angefangen habe ich noch mit DHTML, was hoffentlich kaum noch einer kennt, da dies nichts anderes war als normales HTML mit Javascript-Funktionalitäten. Einige Zeit später habe ich dann meine Freude an der Library jQuery gefunden, die in der damaligen Zeit des Browserkrieges die Lücken zwischen den einzelnen Engine-Implementationen gefüllt hat, sodass die Workarounds direkt durch die Bibliothek bereits mitgeliefert worden sind.

Man kann einige meiner jQuery-Plugins bei meinen Projekten finden, dies sind aber nur die Skripte, die ich privat entwickelt habe. Beruflich habe ich ebenfalls einige jQuery-Skripte und auch -Plugins entwickelt, die zum Glück so universal und leistungsstark sind, dass ich immer wieder welche davon in neue Projekte mit reinziehen kann (ohne dass etwas kaputt geht, was bei den ganzen Bibliotheken nicht immer der Fall ist).

Neben jQuery gibt es natürlich auch noch viele anderen JavaScript Frameworks und Bibliotheken, und mittlerweile gibt es sogar viele interessante Projekte, die sehr C-like arbeiten und dadurch eine JVM oder eine gesamte Spiele-Engine nach JavaScript verlagern. Gerade durch den aktuell laufenden Browserkrieg zu HTML5 und den damit eingeführten Standards wie WebGL und andere lustige Dinge entwickelt sich der Browser zur Applikationsplattform. Wer jetzt nicht aufspringt, der wird den Zug verpassen und eine ganze Menge an Potential verlieren.

• Diese Seite wird mit Gulp erzeugt Nach vielen Ansätzen mit PHP und sogar ein paar Entwicklungen zu einem eigenen Java-basierten CMS habe ich mich dazu entschlossen meine Website statisch zu generieren. Es hat keinen Sinn mehr gemacht die sowieso statischen Inhalte in der Datenbank zu speichern um dann die Auslastung meines Systems durch mehr als einen Prozess in die Höhe zu treiben. Wenn man sich die einzelnen Anwendungen betrachtet, die Ressourcen verbaucht haben (Webserver, PHP-Prozess, Datenbank), und sich dann das gleiche mit einer statisch ausgelieferten Website ansieht (also nur der Webserver), dann war meine Entscheidung sehr schnell gefunden. Ich brauche keinen Login-Bereich, ich benötige keine direkte Dynamik (obwohl das der Domainname dies anmuten lässt), was ich benötige ist ein leistungsstarkes Templating-System, eine Möglichkeit meine Artikel zu Pflegen und am besten so, wie ich es möchte.

Die gefundene Lösung war anfangs für mich noch neu, doch setze ich sie nun seit ungefähr mehr als einem Jahr ein. Meine Artikel verfasse ich in dem agnostischem Markdown, lasse durch Gulp mir meine Navigation erzeugen anhang der URLs, notiere Metainformationen zu den Artikeln mittels Frontmatter und erzeuge meine SEO-URLs mit Hilfe von Gulp und einem Template für die .htaccess-Datei.

Das ganze sieht dann im Ausschnitt so aus:

gulp.task("processContent",function() {
    prepareAndSortBlogPages();

    // render all front-matter stuff
    return gulp.src('**/*.md', {cwd:pagesFolder})
        .pipe(frontMatter({property: 'page', remove: true}))
        .pipe(filterValidEntriesAndReadFrontMatterData())
        .pipe(parseWithMarkdown())
        .pipe(rename({extname: '.html'}))
        .pipe(applyTemplate(typesToIgnoreForContentProcessing))
        .pipe(gulp.dest(targetFolder))
    ;
});

gulp.task("renderAll",
    gulp.series(
        "cleanAll",
        "copyStaticFiles",
        "generateDownloadStuff",
        "calculateRessourceIntegrity",
        "prepareContent",
        "processContent"
    )
);

• Der professionelle Einsatz Den Einsatz von Gulp habe ich bereits in meiner Firma etablieren können, gerade der auch von mir eingesetzte Templating-Mechanismus mittels SWIG hilft für die Transition in die CMS-Systeme, da man hier auch nur Fragmente generieren kann, schließlich bestimmt man selber, was in den Tasks passiert. Aber aufpassen: Wer jedoch auf XING bei den Skills "Swig" aufführt, wird oftmals wegen SWING-Kenntnissen angeschrieben ;) ist dies jedoch Grund-verschieden.

Ansonsten ist jegliches Javascript, was durch Frameworks wie Polymer oder AngularJS verstärkt im professionellen Umfeld eingesetzt wird, immer im Klartext und höchstens minifiziert auszuliefern. Es gibt einige Buzzen, die auch einen Uglyfier über den Code jagen, allerdings empfinde ich gerade den einsehbaren Charakter von Javascript (wie auch bei CSS) als eine der Stärken für den professionellen Einsatz, nicht nur kann man dadurch neue Techniken erlernen

• Die Zukunft von der Prototype-Sprache ECMAScript 6 (bzw. heißt es mittlerweile ja ECMAScript 2015) bringt in meinen Augen einen Rückschritt in die Sprache: Klassen! Es ist immer wieder interessant zu sehen, dass wirklich jemand eine Klasse braucht. Daran merkt man, dass in klassischen Sprachen die Probleme viel größer sind, wer BEIDE Verfahren kennt (also klassische Sprachen sowie Prototypen-Sprachen), und man sich der entsprechenden Stärken bewusst ist, nimmt nur das, was man auch benötigt.