Die Umgebung

Bevor ich loslegen kann, muss die Location stimmen. Man mag jetzt glauben, das da nur zwei Varianten zur Auswahl stehen, nämlich Home Office und der heiß geliebte Arbeitsplatz. Wenn ihr euch selbst einen gefallen tun wollt, bremst euch und die bestehenden Möglichkeiten nicht aus. Beschränkt euch nicht auf diese zwei Optionen. Wie wär’s mit einem netten Cafe in der Stadt? Ich war selbst sehr verwundert, als ich feststellte, wie sehr man sich in einer anderen Umgebung konzentrieren kann. Wenn dann noch das Käffchen stimmt, kann’s losgehen. Also nach Feierabend, anstatt zuhause, gern mal in einer neutralen Umgebung hacken!

Das Setup

Nachdem die Location also festgelegt ist, kann die Maschine gestartet werden. Im Laufe der Zeit stellt man schnell fest, welche Apps man irgendwie IMMER braucht. Folgende Apps starte ich also als Anmeldeobjekte, um mir ein paar Klicks zu sparen (Zeit sich ‘nen Kaffee zu holen):

Da wäre zum Beispiel der schönste Mail-Client auf Erden namens Sparrow und das mit mehr Funktionalität bepackte iTerm, zum Rumrocken auf der Konsole. Als Webentwickler braucht man natürlich auch sämtliche Browser und Profilemanager. Hier beschränke ich mich aber auf Chrome. Außerdem habe ich im Hintergrund immer meinen Twitter-Client laufen, um regelmäßig von Growl benachrichtigt zu werden, dass neue Tweets eintrudeln. Ich verwende keine IDE. Letztes Jahr habe ich Vim geheiratet. Und wer will schon, dass seine Frau permanent neben einen steht. Vim wird also erst dann gestartet, wenn’s nötig ist. Um schlussendlich wirklich gar nichts zu verpassen, wartet mein Reeder ebenfalls auf entsprechendes Futter sämtlicher Feeds.

So sieht’s aus. Aber nicht nur der Twitter-Client, auch Sparrow ist mit Growl verknüpft, was dafür sorgt, dass ich nicht ständig aus der Zone™ rausgerissen werde. Growl’s Notifications sind dezent genug, um nicht abzulenken.

Musik

Der nächste Schritt zur vollständigen Isolierung. Paul hat in seinem Artikel nicht unrecht.”An endless supply of new beats works wonders.” – Yepp. Songs von Justice, Daft Punk aber auch Skrillex und sämtliche Tracks von UKF Dupstep ziehen mich in die tiefsten Tiefen der Zone™. Komischerweise lässt es sich bei Drum’n'Bass auch schneller Tippen. Um Musik zu hören nutze ich keine Cloud-Dienste. Meine iTunes-Library ist gefüllt mit vielen verschieden Songs unterschiedlicher Genres. Da kommen gern mal so Wiedergabelisten mit Namen wie “Hacking” oder “Send the Geek the Zone™” zustande.

Wenn nicht zuhause, sondern in irgendeinem Cafe meiner Wahl, macht’s natürlich mehr Sinn, anstatt einer entsprechenden Anlage, zu den guten alten Over-Ear-Headphones zurück zugreifen.

The Zone™

Ab jetzt befinde ich mich in meiner persönlichen Zone™. Natürlich kommt es immer wieder vor, dass irgendwelche Kräfte von außen auf einen einwirken, die dann schließlich doch dafür sorgen, die Zone™ zu verlassen. Trotzdem bin ich unter diesen Voraussetzungen weitaus produktiver. In den Abendstunden, ab 23 Uhr, bekomme noch das Sahnehäubchen der Konzentration.

Wie gelangt ihr in eure Zone™?

Wie Sparrow und Twitter – Smartbar rocks!

Nach dem ersten Start von Raven fällt eines besonders schnell auf: die Smartbar. Was bei Raven als Smartbar bezeichnet wird, hat sich bereits in Apps wie Twitter for Mac und dem absolut schlanken Mail-Client Sparrow als sehr sinnvoll erwiesen. Übersichtlich und auf’s wichtigste reduziert hat man Zugriff auf Timelines der verschiedenen Twitter-Accounts bei Twitter for Mac und auf beliebig viele Postfächer bei Sparrow. Bei Raven hat man die Möglichkeit, sämtliche Web Apps aus dem Web App Shop zu installieren. Diese werden dann automatisch der Smartbar hinzugefügt und schon hat man schnellen Zugriff auf die jeweilige App.

Letztendlich ist der Aufruf einer solchen Web App bei Raven nichts anderes, als das Aufrufen einer bestimmten URL. Das schöne dabei: Bestimmte Web Apps bieten entsprechende “Unterbereiche”, die ebenfalls über die Smartbar aufzurufen sind. Auch bei diesen handelt es sich um nichts anderes als das Aufrufen einer bestimmten URL, man spart sich aber das Tippen und hat noch eher das Look & Feel einer nativen App. Da sich Raven zur Zeit noch in der Betaphase befindet, ist das Angebot an Apps eher mager. Das macht aber nichts, wenn man sich in erster Linie mit weitverbreiteten Apps wie Facebook und Instapaper oder iCloud und Amazon, zufrieden geben kann.

Ich persönlich bin ein großer Freund dieser Smartbar. Erstmals bei Tweetie und dann bei Twitter for Mac kam ich das erste Mal in den Genuss einer solchen Art von GUI. Klar. Irgendwo ist es auch Geschmackssache. Ich mag’s. Das ist auch einer der Gründe gewesen, warum ich mich auf Sparrow eingelassen habe und ich bereue es auf gar keinen Fall!

Weitere “smarte” Einzelheiten

Alles was mich bei Raven überzeugt, steht offenbar in Verbindung mit der Smartbar. Was mir nämlich ebenfalls sehr gefällt, ist z.B. der Zugriff auf die eigene History. Diese ist, wie nicht schwer zu erwarten, über die Smartbar erreichbar und bietet eine Sparrow-ähnliche Ansicht der zuletzt besuchten Seiten. Selbstverständlich ist es auch hier möglich, nach bestimmten Dingen zusuchen, indem man die sich über der History befindenden Suchleiste verwendet.

Zum Schluss möchte ich noch gern auf den besonders coolen Download-Bereich von Raven hinweisen. Auch hier ist es möglich, sämtliche Downloads die mit Raven getätigt wurden nach bestimmten Suchkriterien zu filtern und zu finden. Aus einer direkt getätigten Suche, erhält man hier nach dem selektieren eines Files, dessen Informationen über Dateigröße, Dateityp, sowie die Herkunft. An dieser Stelle ist es sogar möglich ausgewählte Files aus dem Interface heraus in den Papierkorb zu schmeißen, oder im Finder zu öffnen.

Fazit

Wer ein Freund von der Smartbar-GUI ist und bereits Erfahrungen in der Handhabung mit Twitter for Mac oder Sparrow gesammelt hat, wird sich in Raven sehr schnell zurecht finden und es höchstwahrscheinlich mögen. Da sich das Projekt noch in der Betaphase befindet, gibt es noch einige kleine Bugs, die aber sicherlich gefixed werden. Ich denke man kann noch eine Menge cooler Features erwarten. Da Raven zum kostenlosen Download bereit steht, würde ich jedem Mac-User empfehlen, es einfach mal zu probieren. Wer’s nicht mag, wirft’s einfach wieder weg.

Das Meetup bestand wieder aus drei Talks. Neben “Usability Aspects” von Normen Ludwig, “Rocking the fugly form elements” von Marcel Böttcher und Christian Haller gab es noch einen Talk von meiner Wenigkeit über JavaScript Performance mit “Making your JavaScript faster”.

Normen Ludwig klärte darüber auf, was Usability eigentlich ist und bedeutet.Er ging auf die sogenannte Gebrauchstauglichkeit ein und wies besonders darauf hin, das weniger mehr ist. “Minimalism in design” ist also das Stichwort, während er auf die “Effizienz der Handhabung” einging und es nicht nur die Benutzer sind, die damit leben müssen. Entwickler sind auch Benutzer und sollten ihre selbst entwickelten APIs unter Usability aspekten entwerfen.

Marcel Böttcher von Neoskop und Christian Haller stellten ihr eigenes jQuery-Plugin rock.js vor. Rock.js hilft dabei sämtliche standard HTML Form Elemente auf einfachste Weise zu stylen. “Wir planen die Stable” war eine Aussage, die darauf hoffen lässt, dass dieses Plugin bald für den Produktiveinsatz verfügbar ist.

Zu guter Letzt durfte meine Wenigkeit auf die Stage und den Leuten erzählen, wo in JavaScript Performance Probleme auftauchen und wie man sie vermeiden kann. Dazu zählten Themen wie Scope Management, Datenzugriff, Schleifen das DOM und in Verbindung damit, Reflow. Der interessanteste Teil war offenbar der Reflow-Part, weils für so ziemlich jeden was Neues war.

Im Großen und Ganzen wieder ein cooles Meetup gewesen! Man trifft alte Gesichter wieder und lernt neue kennen. Also für jeden, der noch nicht auf den Geschmack gekommen ist: jeder vierte Donnerstag im Monat findet ein Hannover.js Meetup statt! Fotos gibt es übrigens hier!

Hier noch ein paar interessante Links:

- Hannoverjs.de – Offizielle Website
- Neoskop – Offizielle Website
- Medienküche – Offizielle Website
- Tapeup
- EDELSTALL Coworkingspace
- Doctape – Offizielle Website

Talk bezogen:

- rock.js
- Slides – Making your JavaScript faster

TodoMVC als Inspiration

Addy Osmani hat bereits eine coole Anwendung gebaut, die als eine Art “Probier-mal-ein-bisschen-rum-und-finde-heraus-was-dir-am-besten-passt”-Plattform dient und auf den Namen TodoMVC getauft. Ich persönlich finde diesen Ansatz total klasse und dachte mir, sowas in der Richtung muss es auch für JavaScript Libraries geben, die für Slides gedacht sind! Aus diesem Grund habe ich also TodoMVC als Vorlage verwendet und eine, für sich eigene, Plattform erstellt, die genau diesen Zweck erfüllt!

Was so cool daran ist

Jeder da draußen kann diese Plattform verwenden und rumprobieren. Ebenfalls kann jeder da draußen seinen Teil dazu beitragen und ein eigenes Beispiel mit irgendeiner anderen JavaScript (Slide) Library hinzufügen. Somit haben alle was davon! Zur Zeit gibt es nur eine kleine Live-Demo zu Fathom.js, aber es stehen bereits Demos mit anderen Libraries in Aussicht! Wer also Lust oder Interesse hat irgendwas beizutragen, oder vielleicht einfach nur ein bisschen stöbern möchte: Der Sourcecode befindet sich auf Github und wartet nur darauf zu wachsen! Wer sich die Plattform direkt ansehen will, hier geht’s lang!

Im Anschluss ein kleiner Einblick:

Links

- Modern HTML5 Presentations
- TodoMVC
- Fathom.js

In JavaScript sind Objekte niemals gleich

Es klingt ein bisschen verwirrend, aber es ist nunmal so. Wenn wir ein neues Objekt in JavaScript erstellen, gibt es kein anderes Objekt, das gleich ist, und das neue Objekt ist schon ein Singleton. Schauen wir uns folgendes Codebeispiel an, lässt sich schnell erkennen, das die Erzeugung eines Objektes mit Objekt-Literalen ein Singleton ins Leben ruft.

var myObj = {
    myAttribute: 'JS is awesome!'
};

var myObj2 = {
    myAttribute: 'JS is awesome!'
};

myObj === myObj2    // false
myObj == myObj2    // false

Also grundsätzlich gilt: Immer dann, wenn ein Objekt mit Objekt-Literalen erzeugt wird, erstellt man eigentlich ein Singleton.

Singleton mit new-Konstruktor

Eine weitere Möglichkeit ein Singleton zu erzeugen ist die mit der Verwendung von new. Es gibt Fälle, in denen ist es gewollt ein Objekt immer mit dem new-Operator zu instanziieren. Auch hier gilt: Bei jeder Erzeugung einer solchen Instanz wird immer auf das gleiche Objekt gezeigt. So könnte also die Schnittstelle aussehen, wenn man das Singleton-Pattern mit der Verwendung von new implementiert:

var numberOne = new Singleton();
var numberTwo = new Singleton();

numberOne === numberTwo;  // true

Letztendlich wird also nur bei numberOne die eigentliche Instanz erzeugt. Jeder weitere Aufruf von “new Singleton();” erzeugt nichts weiter als eine Referenz auf die bereits bestehende Instanz. Wie lässt sich das Ganze aber nun umsetzen?

Grundsätzlich gibt es mehrere Möglichkeiten das obige Ziel zu erreichen. Die stumpfste, die mir als erstes in den Sinn kommt, wäre die Verwendung einer globalen Variable, in der eine entsprechende Instanz gespeichert wird. Das das nicht sonderlich vom Vorteil ist, wissen wir. Der globale Namensraum sollte freigehalten werden. Zudem könnte unter diesen Umständen der Wert unserer globalen Variable jeder Zeit von außen geändert werden.

Weg Nummer zwei wäre der Konstruktor-Funktion für Singleton eine statische Eigenschaft hinzuzufügen, welche die Instanz hält. Da Funktionen in JavaScript auch nur Objekte sind, ist das kein Problem. Ein Ansatz wie Singleton.__instance wäre also denkbar. Nur gibt’s auch hier wie immer einen Haken. Statische Eigenschaften eines Objektes in dieser Form sind ebenfalls global öffentlich. Das wiederum bedeutet, das auch in diesem Fall der Wert der Eigenschaft einfach von außen geändert werden kann.

Zu guter Letzt wäre es möglich, ein Closure zu erzeugen, wodurch wir eine mögliche Eigenschaft __instance in eine Art gefaketen privaten Scope holen.

Gehn wir’s an!

function Singleton () {

    if (typeof Singleton.__instance === "object") {
        return Singleton.__instance;
    }

    Singleton.__instance = this;
}

var numberOne = new Singleton();
var numberTwo = new Singleton();

numberOne === numberTwo; // true

Hier sehen wir die Lösung mit der Instanz als statische Eigenschaft. Unwahrscheinlich, aber nicht unmöglich ist hier, __instance von außen einfach zu ändern.
Schauen wir uns nun einen möglichen Lösungsweg mit der Instanz in einem Closure an.

function Singleton() {

    var __instance = this;

    Singleton = function () {
        return __instance;
    }
}

var numberOne = new Singleton();
var numberTwo = new Singleton();

numberOne === numberTwo; // true

Hier wird also beim ersten Aufruf ganz normal this zurück gegeben. Bei jedem weiteren Aufruf wird die mit bereits this versehende Variable __instance zurück gegeben, da sich der Konstruktor “Singleton” selbst definiert. Der Konstruktor wird also beim ersten Aufruf überschrieben, hierbei handelt es sich übrigens um eine “Lazy Function definition”.
Allerdings gibt es hier den Nachteil, dass die neugeschriebene Funktion alle Eigenschaften verliert, die zwischen der initialen Definition und der Redefinition hinzugefügt wurden.
Hier mal ein konkreter Fall:

Singleton.prototype.something = false;

var singleton = new Singleton();

Singleton.prototype.somethingelse = true;

var singleton2 = new Singleton();

// Und nun der Test
singleton.something; //false
singleton2.something; // false

singleton.somethingelse; // undefined
singleton2.somethingelse; // undefined

singleton.constructor.name; // "Singleton"

singleton.constructor === Singleton; // false

Durch die Redefinition zeigt singleton.constructor nicht mehr auf den Konstruktor Singleton(). Um das zu fixen kann man ein paar Kniffe verwenden.

function Singleton() {

    var __instance;

    Singleton = function Singleton() {
        return __instance;
    }

    Singleton.prototype = this;

    __instance = new Singleton();
    __instance.constructor = Singleton;

    return __instance;
}

// Und nochmal testen
Singleton.prototype.something = false;
var singleton = new Singleton();

Singleton.prototype.somethingelse = false;
var singleton2 = new Singleton();

singleton === singleton2; // true
singleton.constructor === Singleton; // true

Perfekt! Fertig ist unser Singleton! Zur Verschönerung packen wir alles nochmal in eine Immediate Function. So wird beim ersten Aufruf des Konstruktors ein Objekt erzeugt und der “privaten” Variable __instance zugewiesen. Bei jedem weiteren Aufruf wird einfach diese zurück gegeben. Somit haben wir ein kleines Modul geschaffen, welches uns unser Singleton erzeugt.

var Singleton;

(function () {
    var __instance;

    Singleton = function Singleton() {

        if (__instance) {
            return __instance;
        }
    };
}());

DOM-Zugriff

Der wahrscheinlich größte Knackpunkt am DOM Scripting ist wohl das DOM selbst. Das klingt im ersten Moment recht widersprüchlich und wenn Ich es nicht besser wüsste, ist es das auch. Der Grund dafür ist, dass das DOM getrennt von der JavaScript-Engine implementiert ist, was auch gar nicht so undurchdacht ist, da man ja nicht zwangsweise immer auf das DOM zugreifen möchte.

Allerdings bringt genau dies seine Nachteile mit sich. Jeder Zugriff auf das DOM dauert. Das wiederum bedeutet, dass man die Zugriffe auf das DOM möglichst gering halten sollte. Nur wie soll das funktionieren, wenn wir doch ständig das DOM manipulieren wollen? Es gibt da ein paar Kniffe, die unserem Problem entgegen wirken.

Wenn Ihr euch Ein bisschen was über Performance in JavaScript bereits durchgelesen habt, kennt Ihr ja schon den kleinen Trick mit dem Zwischenspeichern um eure Schleifen schneller zu machen. Nun wollen wir aber auf das DOM zugreifen, was uns doch eine Menge Steine in den Weg legt, was unsere Performance angeht.

for (i = 0; i < 100; i += 1) {
    document.getElementById("foo").innerHTML += i + ", ";
}

Autsch. Wie Ihr seht, wird hier im obigen Code hundertmal iteriert. Und bei jedem Durchlauf wird auf das DOM zugegriffen. Eine sehr kostspielige Angelegenheit. Das muss nicht sein. Im folgenden Code reduzieren Wir die Zugriffe auf ein einziges Mal. Dies bedeteut zwar mehr Code, aber es lohnt sich. Je nach Browser ist der Code zehn- bis hundertfach schneller!

var i, content = "";
for (i = 0; i < 100; i += 1) {
    content += i + ", ";
}
document.getElementById("foo").innerHTML += content;

Ähnliches Vorgehen können Wir auch bei Veränderungen von Attributen vornehmen. Auch hier gilt: Zwischenspeichern rettet eurer App das Leben!

// nicht gut
var padding = document.getElementById("foo").style.padding,
    margin = document.getElementById("foo").style.margin;

// awesome
var style = document.getElementById("foo").style,
    padding = style.padding,
    margin = style.margin;

Ein weiterer guter und auch schneller Weg ist die Verwendung von Selektions-Apis. Neuere Browsers und ab IE 8 aufwärts bieten diese APIs um auf DOM-Elemente zuzugreifen. Die Selektor-Methoden sind immer schneller als eine selbst vorgenommene Selektion über andere DOM-Methoden. Gängige JavaScript-Bibliotheken verwenden diese APIs bereits, man sollte also immer auf dem aktuellsten Stand sein.

// ein bestimmtes Element
document.querySelector("#foo");

// Elemente mit einer bestimmten Klasse
document.querySelectorAll("#foo .selected");

Das DOM verändern

Selbstverständlich wollen Wir, nachdem Wir drauf zugegriffen und genug rumgerockt haben, das DOM unseren Wünschen entsprechend manipulieren. Aber auch hier haben Wir das Problem, dass die meisten Änderungen am DOM eine Menge Zeit kosten. Das Anpassen des DOM kann dazu führen, dass der Browser den Fensterinhalt neu ausgibt und häufig den "Fluss" der Elemente neu berechnet. Man spricht hier auch vom sogenannten Reflow. Paul Irish geht in einem seiner Screencasts näher drauf ein.

Nehmen Wir also an, Wir wollen einen Unterbaum erzeugen... Grundsätzlich könnte man es so machen:

var p, t;

p = document.createElement("p");
t = document.createTextNode("Text");

p.appendChild(t);
document.body.appendChild(p);

p = document.createElement("p");
t = document.createTextNode("Another one.");

p.appendChild(t);
document.body.appendChild(p);

Kann man bringen, ist aber alles andere schön. Es gibt einen besseren Weg. Wir können nämlich ein sogenanntes Dokumenten-Fragment erzeugen. Auf diesem rocken Wir rum, bis wir der Meinung sind, dass alle unsere Änderungen an das eigentliche Dokument gehängt werden können. Seht selbst.

var p, t, f;

f = document.createDocumentFragment();

p = document.createElement("p");
t = document.createTextNode("awesome");

p.appendChild(t);
f.appendChild(p);

p = document.createElement("p");
t = document.createTextNode("even more awesome");

p.appendChild(t);
f.appendChild(p);

document.body.appendChild(f);

Und schon haben Wir anstatt zwei nur noch eine Aktualisierung, was bedeutet, dass auch nur ein Reflow erzeugt wird.

Was Speaker Deck so besonders macht

Klar. Es gibt SlideShare. Und ja. SlideShare bietet einem auch genau dass, was mach will: Präsentationen jeglicher Formate uploaden und teilen. Also was ist so besonders an Speaker Deck? Speaker Deck ist einfach. Speaker Deck ist schön. Und ganz wichtig: Speaker Deck ist frei von nerviger Werbung!

Während man auf SlideShare direkt nach dem Login schnell auf das neuste Sortiment von Zalando stößt und anschließend von einem – nur relativ – übersichtlichen Design “erschlagen” wird, wird man bei Speaker Deck mit einem schicken, frischen und minimalistischen Design begrüßt. Völlig reduziert aufs wesentliche zieht der Dienst schnell seine Aufmerksamkeit auf sich. Man findet sich schnell zurecht, da man kein vollgepumptes Drop-Down-Menü bedienen muss, bei dem ein Großteil der Features eh nicht genutzt wird.

Hier lade Ich grad meine Slides von Hannover.js hoch

Zudem akzeptiert Speaker Deck nur das Format von PDF-Dateien. Ob das nun ein Vor- bzw. Nachteil ist, lässt sich meiner Meinung nach nicht sagen. Wer PowerPoint Präsentationen erzeugen kann, kann auch PDF’s erzeugen. Ein Vorteil bringt es auf jeden Fall mit sich: Während die Dimensionen einer SlideShare Präsentation begrenzt sind, sobald man diese auf anderen Websites einbindet (und die Präsentation als .pptx o.ä. geuploaded wurde), sind mit PDF formatierten Slides natürlich keine Grenzen gesetzt.

Fazit

Ich bin bereits zu Speaker Deck geswitched. Das Design und die Bedienbarkeit haben mich klar überzeugt. Und dass Ich mir bei Speaker Deck keine Zalando Werbung ansehen muss, habe Ich ja bereits erwähnt. Wer also viel Wert auf schlanke GUI’s legt, die auch noch schön sind, ist bei Speaker Deck gut aufgehoben! Wen’s interessiert: Hier gibt es die Slides von Hannover.js

Das Gute an JSLint

Kurz gesagt, gibt es an JSLint nichts, was nicht gut ist. JSLint macht euren JavaScript-Code besser. Zu Anfang werdet Ihr wahrscheinlich feststellen, dass euer JavaScript-Code gar nicht mal sooo geil ist, wie ihr bis dahin gedacht habt. Da es in JavaScript Unmengen an Möglichkeiten gibt, bestimmte Dinge zu lösen, ist es nichts Ungewöhnliches, die Best-Practices nicht von vorn herein drauf zu haben. Wenn JSLint euch sagt, dass irgendetwas nicht mit eurem Code stimmt, nimmt es euch zu Herzen und lernt aus diesen, Ich nenne es mal, “Fehlern”.

Selbstverständlich ist man zu nichts in der Welt gezwungen. Also mal ganz abgesehen davon, dass ihr auch getrost auf die Hilfe von JSLint verzichten könnt, habt ihr die Möglichkeit JSLint euren Erwartungen anzupassen. Auf der Seite seht ihr viele Konfigurationsmöglichkeiten, die die Analyse von JSLint in Hinblick auf euren Code beeinflussen. So könnt ihr zum Beispiel angeben, dass JSLint den “use-strict”-Mode tolerieren soll/kann. Und wenn ihr aus philosophischen Gründen lieber die ++ und – anstatt der += 1 und -= 1 Schreibweise verwendet, um während einer Iteration auf- und abzuzählen, lässt sich auch dies mit Leichtigkeit bewerkstelligen. Dazu muss man zum Beispiel nur den Haken bei “Tolerate ++ and –” setzen und schon ignoriert JSLint diese Fälle, beziehungsweise toleriert sie. Übersteht euer Code eine Analyse von JSLint fehlerfrei, könnt ihr sicher sein, dass euer Code konsistent ist und schon mal keine Tippfehler enthält.

JSLint und Vim sind ein Team

Ich weiß ja nicht wie’s euch geht – aber Ich liebe Vim! Vim hat schon einige Jahre auf den Buckel und erscheint im ersten Licht als einfacher Texteditor. Aber der Schein trügt! Vim ist unglaublich mächtig. Sei es allein die persönliche Konfiguration, welche man diesem Editor unterziehen kann oder die Erweiterung des Texteditors zu einer, im Produktivbereich nutzbaren, IDE. Für Vim-User ist es bestimmt keine großes Unterfangen – Ich habe mich tierisch gefreut, als Ich darauf gestoßen bin – aber für die, die Vim möglicherweise weniger gut kennen: Ja! Es gibt auch ein passendes Plugin für JSLint!

Ein JSLint-Plugin für Vim… Was soll das wohl bringen? Eigentlich liegt es klar auf der Hand. Für den Fall, dass ihr diesen Artikel lest, dadurch das erste Mal auf JSLint stoßt und wirklich vor habt, euren JavaScript-Code regelmäßig durch den Fleischwolf zu ziehen, werdet ihr sehr schnell feststellen, dass es recht nervig sein kann seinen JavaScript-Code aus der IDE in die Textarea zu kopieren. Wie einer meiner Lieblings-Geeks auch gern sagt:”Automatisiert – ist schön!”. Und genau das bewirkt das Plugin für Vim. Es ist so einfach zu installieren wie alle anderen Plugins für Vim. Eine Installationsbeschreibung findet ihr hier.

Nachdem ihr das Plugin installiert habt, brauch ihr nichts weiter tun als das Kommando “:JSLintUpdate” auszuführen. Vim prüft nun bei jeder Änderung die ihr in eurem grade zu bearbeitenden File durchführt (sofern dies ein .js-File ist), ob dieser JSLint übersteht. Vielmehr – JSLint wird direkt in Vim ausgeführt! Ihr erhaltet genau die gleichen Meldungen wie auf der Website; und nicht nur dass, Vim markiert alle Stellen in euren JavaScript-Code, an der JSLint gemeckert hat. Ist das nicht Klasse? Einfach mit dem Cursor über eine entsprechend markierte Stelle fahren und ihr erhaltet die Fehlermeldung in der Kommandozeile.

Ein bekanntes Problem

Leider kommt es bei einigen Installationen des Plugins zu einem Problem. Sobald das Plugin installiert ist, und ihr ein .js-File öffnet, dies aber noch keinen JavaScript-Code enthält, bricht das Plugin zusammen und wirft folgende Fehlermeldung: “Could not invoke JSLint!”. Leider kann Ich nicht genau sagen, wie es zu diesem Fehler kommt, da ich aus dem Code des Plugins nicht schlau wurde. Aber kein Problem, es gibt ja Google und Google ist auch unser Freund. Wenn man weiß, wie man etwas in die Suchleiste eingeben kann um etwas zu suchen (…). Ich habe also recherchiert und bin öfters auf Beiträge gestoßen, bei denen Leute das gleiche Problem hatten. Schlussendlich gibt es einen Workaround. Hier der Issue dazu. Damit dieser Workaround funktioniert, muss man allerdings Node installiert haben. Das sollte aber wohl auch kein Problem sein.

Der Objekt-Konstruktor

Der erste und stumpfsinnigste Weg ein Objekt zu erzeugen, ist mit Hilfe des Objekt-Konstruktors. Dieser Konstruktor bringt einige Kniffe mit sich, dazu komm Ich gleich. Hier erstmal ein Beispiel, wie die Verwendung eines Objekt-Konstruktors aussieht.

var Car = new Object();
Car.color = "#000000";

console.log(Car.constructor === Object);    // true
console.log(Car.color); // "#000000"

Damit zeige ich euch wahrscheinlich nichts Neues. Aber schauen wir uns den Code mal genauer an. Wir erzeugen also ein Objekt Car mit Hilfe des Objekt-Konstruktors. Das Ergebnis ist wie erwartet, wir erhalten ein Objekt und können dieses mit Eigenschaften und Methoden füllen. Würden wir an Stelle des Objekt-Konstruktors Objekt-Literale verwenden, erhalten wir das gleiche Ergebnis.

Objekt-Literale

var Car = {};    // leeres Objekt
Car.color = "#000000";

// Oder alles in einem Rutsch

var Car = {
    color: "#000000"
};

Mit diesem Code erhalten wir also das gleiche Ergebnis, wie mit der Verwendung des Objekt-Konstruktors. Aber welche Variante soll man denn nun verwenden? Ganz einfach. Vergleichen wir beide Lösungen, stellen wir schnell fest, dass das Schreiben von Objekt-Literalen weniger Arbeit in Anspruch nimmt – also weniger Code. Ein weiter Grund den Objekt-Konstruktor nicht zu verwenden ist folgender:

Man kann dem Objekt-Konstruktor einen Parameter mitgeben. Das Ergebnis einer Objektinstanziierung mit Verwendung dieser Parameter kann sehr verwirrend sein. Übergeben wir nämlich einen Parameter, delegiert JavaScript die Objekterzeugung direkt weiter an einen der primitiven Datentypen. Hier ein Code zur Verdeutlichung.

var o = new Object();
console.log(o.constructor === Object);   // true

var o = new Object(2);
console.log(o.constructor === Number);   // true

var o = new Object(true);
console.log(o.constructor === Boolean);    // true

Ouh. Habt ihr das gewusst? Also. Wenn es keinen Grund gibt, den Objekt-Konstruktor zu verwenden, verzichtet drauf. Verwendet lieber Objekt-Literale. Hier gibt es keine hässlichen Seiteneffekte und schlankeren Code hat man auch noch dazu.

Die Konstruktor-Funktion

Der dritte Weg ein Objekt zu erzeugen, wäre eine selbst implementierte Konstruktor-Funktion. In so einem Fall macht man nichts weiter, als eine Funktion zu definieren, welche irgendwas macht. Anschließend kann diese Funktion als Konstruktor-Funktion verwendet werden, in dem man den new-Operator benutzt, um ein Objekt zu erzeugen. Und auch hier gibt es einige Kniffe. Schaut selbst.

function Car(manufacturer) {
    this.manufacturer = manufacturer;
    this.engineStarted = false;

    this.startEngine = function() {
        if (this.engineStarted === false) {
            this.engineStarted = true;
        }
    };
}

var bmw = new Car('BMW');
bmw.startEngine();

Nun haben wir einen simplen Konstruktor um Autos zu erzeugen. Einen Haken hat dieses Muster allerdings noch. Angenommen, ein weiterer Entwickler verwendet euren Code und möchte ebenfalls Autos erzeugen, weiß allerdings nicht, dass er den new-Operator verwenden muss. Momentmal… “verwenden MUSS”?! Yepp. Wird die Konstruktor-Funktion ohne new-Operator aufgerufen, befindet sich unser Konstruktor nicht im Objekt-Kontext und ist nichts weiter, als eine normale Funktion. Was wiederum bedeutet, das this keine Referenz auf unser Auto ist, sondern auf das globale Objekt zeigt. Keine Sorge. Auch für diesen Fall gibt es natürlich eine schöne Lösung.

Das “new” erzwingen

Mit dem Erzwingen ist an dieser Stelle aber nicht gemeint, den Benutzer eures Codes zu zwingen den new-Operator zu verwenden und er andernfalls mächtigen Ärger bekommt, sondern viel mehr, die interne Nutzung von new ohne es explizit aufrufen zu müssen bzw. auf jeden Fall unser das entsprechende Objekt zurück zugeben. Das Ergebnis soll also so aussehen, dass es möglich ist, unsere Konstruktor-Funktion entweder mit, oder ohne new aufzurufen, man aber trotzdem das gleiche Ergebnis erhält. Nämlich unser Objekt.

Um das in die Wege zu leiten, gibt es mehrere Möglichkeiten. Die erste Möglichkeit wäre die Verwendung von that. Anstatt also innerhalb unseres Konstruktors auf this zu referenzieren, erzeugen wir ein leeres Objekt mit den Objekt-Literalen, füllen dies mit Eigenschaften und Methoden und geben dieses auch zurück. Somit bekommen wir in jedem fall unser Objekt.

function Car(manufacturer) {
    var that = {};

    that.manufacturer = manufacturer;
    that.engineStarted = false;

    that.startEngine = function() {
        if (that.engineStarted === false) {
            that.engineStarted = true;
        }
    };

    return that;
}

var bmw = new Car('BMW');
bmw.startEngine();

var vw = Car('VW');
vw.startEngine();

that ist in diesem Fall ein eingespielter Bezeichner. Man könnte auch einen anderen Namen verwenden. Wie man sieht, bekommen wir unser Auto-Objekt, selbst wenn wir unsere Konstruktor-Funktion nicht mit dem new-Operator aufrufen.

Die zweite Variante wäre einfach ein anonymes Objekt zurück zugeben. Hat ein bisschen was vom Modul-Pattern und ist im Großen und Ganzen eine etwas kürzere Variante des obigen Codes.

function Car(manufacturer) {
    return {
        manufacturer: manufacturer,
        engineStarted: false,
        startEngine: function () {
            if (this.engineStarted === false) {
                this.engineStarted = true;
            }
        }
    };
}

Easy hah? Nur gibt es – wie immer – bei diesen beiden Lösungswegen ein Problem. Da wir nicht this zurück geben (was wir auch nicht explizit tun müssen, da JavaScript in einem Objekt-Kontext ganz von allein this zurück gibt), sondern einfach ein weiteres Objekt zurück geben, um dieses auf jeden Fall zu erhalten, geht der Prototype unseres Konstruktors verloren. Also brauchen wir eine Lösung, in der wir sicher stellen, das unser Konstruktor in jedem Fall mit new aufgerufen wird. Klingt ein bisschen verdreht, ist aber gar nicht so schwer. Wir müssen nicht weiter tun, als zu prüfen, ob es sich bei this im aktuellen Kontext um eine Referenz auf unser Auto-Objekt handelt. Ist dies nicht der Fall, müssen wir es eben explizit mit new erzwingen.

function Car() {

    if (!(this instance of Car)) {
        return new Car();
    }

    this.prop = "this is a property";
}

Car.prototype.vehicle = "Bus";

var car = new Car();
var second_car = Car();

console.log(car.prop); // "this is a property"
console.log(second_car.prop); // "this is a property"

console.log(car.vehicle); // "Bus"
console.log(second_car.vehicle); // "Bus"

Caching rettet eurer App das leben

Denkt man kurz darüber nach, mag es auf den ersten Blick kaum Dinge geben, die man an einer for-Schleife ändern sollte, um diese performanter zu machen. Aber der Teufel steckt im Detail. Besonders die Verwendung der hauseigenen length-Eigenschaft kann in Verbindung einer for-Schleife eine Menge Zeit kosten. Hier mal ein üblicher Fall.

for (var i = 0; i < my_array.length; i++) {
    // mach was
}

Was wir hier sehen ist nichts sonderlich Ungewöhnliches. Wir haben unser Array und verwenden dessen Länge, um über einen bestimmten Bereich zu iterieren und irgendwas zu machen. Ganz normale Schleife, ganz normale Verwendung. Und genau das ist das Problem. Im obigen Code, muss bei jedem Durchlauf die Länge unseres Arrays ermittelt werden und zwar ganz allein durch den Aufruf der length-Eigenschaft.

Würden wir nun über das DOM iterieren, arbeiten wir mit HTMLCollection-Objects. Und das, meine Damen und Herren, reißt unsere Performance NOCH ein Stückchen runter ins verderben. Und zwar ein ziemlich Großes. Wenn man sich das mal durch den Kopf gehen lässt, schreit es förmlich nach Optimierung. Warum? Ganz einfach. Die Länge unseres Arrays ist in diesem Fall konstant. Es muss nicht jedes mal ermittelt werden. Was also tun? Es ist einfach. Die Länge des Arrays muss nur zwischen gespeichert werden.

for(var i = 0; var length = my_array.length; i < length; i++) {
    // mach was
}

Und schon haben wir das Problem umgangen. Die Länge unseres Arrays wird initial einmal einer Variablen zugewiesen und von dort an als konstanter Wert verwendet, um den Bereich für die Iteration festzulegen.

Wir können den Code noch ein bisschen verkürzen, in dem wir das Single-Var-Pattern verwenden. Damit sparen wir uns die var-Anweisungen innerhalb der for-Schleife:

var i = 0,
    my_array = [],
    length;

    for (; length = my_array.length; i < length; i++;) {
        // mach was
    }

Oder wir lassen length einfach weg und zählen von i auf 0 runter – noch weniger Code!

var i = my_array.length;

for(; i > 0; i--) {
    // mach was
}

Cool! Und es geht NOCH kürzer!! Wie? Mit einer while-Schleife

var i = my_array.length;

while(i--) {
    // mach was
}

Awesome! Dieser Code übersteht JSLint zwar nicht, aber wenn wir unsere Prioritäten ein wenig verlegen, sollte das kein Problem sein.