Emmet - The essential toolkit for web-developers

Eine der Dinge, die ich in meiner täglichen Arbeitswelt nicht habe, ist zu viel Zeit. Daher bin ich immer daran interessiert, wenn möglich genau diese, mir sonst an anderer Stelle fehlende Zeit einzusparen.

Eine der häufig unnötig Zeit kostenden Tätigkeiten ist dabei das Aufbauen der benötigten DOM Struktur. Dabei ist es oft der Fall, dass viele wiederkehrende Elemente, wie beispielsweise Listen und deren Elemente, angelegt werden müssen. Diese Arbeit ist oft mühselig und kostet unnötig Zeit.

Abhilfe kann hierbei Emmet schaffen. Mit dem selbst ernannten "essential toolkit for web-developers" lassen sich mit einfachen Anweisungen schnell und einfach komplexe Strukturen aufbauen.

Einen Überblick über die Funktionen findet ihr in der Emmet Dokumentation.

Emmet ist als Plugin für viele Editoren verfügbar. Viele Online IDEs  wie CodePen und JSFiddle haben Emmet sogar schon integriert.

Glücklicherweise wird Emmet nativ von meiner Lieblings-Entwicklungsumgebung PHPStorm von JetBrains unterstützt.

Für alle, die gerade erst beginnen, oder ausgelößt durch diesen Artikel, mit Emmet zu arbeiten, kann ich dieses Cheat Sheet Empfehlen.

Ich hoffe, dass ihr genauso viel Interesse an Emmet findet und dies euch ebenfalls eure Arbeit erleichtert.

Callbacks in JSDoc

lange Zeit habe ich mich gefragt, ob es in JSDoc  eine Möglichkeit gibt, Callbacks beziehungsweise die Parameter die an die Callbacks übergeben werden sauber zu dokumentieren.

Bis dato habe ich zwar die Callbacks die an die aufrufenden Funktion übergeben werden mit @param Dokumentiert, die Parameter die an diesen Callback übergeben werden musste man jedoch schlichtweg wissen.

Bei kleineren Skripten ist dies ja noch möglich, bei größeren Skripten führt die häufig schnell ansteigende Zahl der Callbacks jedoch auch zu einem recht proportionalen Verlust der Übersicht über eben diese.

Des weiteren konnte ich mir nicht vorstellen, dass es hierfür keine Lösung gibt, denn dinge die man schlichtweg wissen muss stehen ja schon prinzipiell kontrovers gegen den Grundgedanken einer Software Dokumentation und damit auch gegen das Prinzip von JSDoc.

Nach einiger Recherche habe ich heute dann doch die korrekte Lösung dann doch ganz am Ende der Dokumentation zu @param finden können:

/**
 * This callback type is called `requestCallback` and is displayed as a global symbol.
 *
 * @callback requestCallback
 * @param {number} responseCode
 * @param {string} responseMessage
 */
/**
 * Does something asynchronously and executes the callback on completion.
 * @param {requestCallback} cb - The callback that handles the response.
 */
function doSomethingAsynchronously(cb) {
    // code
};

Zunächst definiert man über den @callback Parameter die Callback Funktion mit den zugehörigen Parametern. An der aufrufenden Funktion kann man nun mit {callbackName} auf die zuvor dokumentierte Callback-Funktion verweisen.

Ich bin froh, nun einen Ansatz gefunden zu haben, der mir einen besseren Überblick in großen Projekten verschafft und hoffe, dass ich dem ein oder anderen dadurch ebenfalls helfen konnte.

Performant HTML5 Canvas detection

Für ein aktuelles Projekt muss ich in der Applikation prüfen, ob HTML5 Canvas zur Verfügung steht und genutzt werden kann. Ist dies nicht der Fall, soll dem Anwender eine entsprechende Rückmeldung gegeben werden, mit der Bitte doch bald einmal seinen Browser zu aktualisieren.

Der übliche Weg, der auch in den meisten Frameworks verwendet wird, ist ein entsprechendes Canvas Element zu erzeugen und das Ergebnis zu überprüfen.

Beispiel:

var canvasSupport = !!document.createElement("canvas").getContext;

Leider ist dieser Ansatz, gerade im Internet Explorer, aber auch in anderen Browsern recht performance hungrig. Ein anderer Weg ist es das im HTML Standard und im W3C Working Draft definierte Interface anzusprechen. Eine Dokumentation dazu ist auch im Mozilla Developer Network zu finden.

Beispiel:

var canvasSupport = !!window.HTMLCanvasElement;

Wie vermutet und durch einen jsPerf Test belegt, ist diese Methode in vielen Browsern deutlich schneller. Der Grund hierfür ist recht schnell klar: Bei der zweiten Methode muss nicht erst ein entsprechendes Element erzeugt werden.

Dass dieser Weg deutlich schneller sein muss, ist daher nur logisch. Überrascht hat mich jedoch das Ergebnis. Bei eigens durchgeführten Tests im sogar recht aktuellen Internet Explorer 11 lag der unterschied bei ca 200%!

Den Entsprechenden Test könnt ihr auch selbst durchführen. die URL lautet:
http://jsperf.com/htmlcanvaselement-vs-getcontext-checks

The Power of SASS

See the Pen Particle Orb CSS by Nate Wiley (@natewiley) on CodePen.

Heute bin ich über CodePen über diese SCSS Demo gestolpert die mich doch sehr überrascht hat: Das Ergebnis an sich ist technisch nicht so anspruchsvoll und ließe sich selbstverständlich mit HTML5 Canvas oder ähnlichem problemlos lösen. Die hier vorgestellte Lösung basiert jedoch ausschließlich auf SCSS und kommt ohne JavaScript oder ähnlichem aus. Dies hat mich tatsächlich doch überrascht und mir ein weiteres mal gezeigt, wie mächtig CSS bzw. SASS & LESS doch sind.