Pipes dienen in Javascript bekannterweise als logisches ODER. Neben dem Einsatz für Fallunterscheidungen lassen sich Pipes auch sehr gut zur direkten Wertzuweisung nutzen. Als Beispiel dient eine Methode mit einem Parameter param1, dessen Standartwert 0 sein soll, wenn kein Parameter angegeben wurde. Hierfür könnte man mit Fallunterscheidungen arbeiten, aber ist folgender Code nicht viel eleganter?

function dummy (param1) {
    var param1 = param1 || 0;
}

Ohne groß zu überlegen würde ich fehlende Dokumentation als Hauptmängel hergestellter Javascript-Quelltexte bezeichnen. In manchen Projekten würde ich gerne alle Mitentwickler in ein Seminar alá „Dokumentieren – Wie, Wann, Warum“ verfrachten. Fragt sich nur, was schlimmer ist – undokumentierter Code oder schlecht/falsch dokumentierter Code. Gerade habe ich mal wieder so etwas gefunden. Wie soll mir folgende Dokumentation helfen?

/**
 * Does some magic. Expects 2 integer params and returns the correct resultvalue for us
**/

Aah, nun bin ich schlauer… nein, nicht wirklich - wirklich nicht!

Javascript-Entwickler dieser Welt, bitte dokumentiert!

Das ist auch ganz einfach! Haltet euch an die Spezifikationen und erzeugt eine schicke Dokumentation mit dem JSDoc Toolkit. Einen besseren Weg, mich als Freund zu bekommen, gibt es nicht.

…und natürlich auch meine Javascript-Quelltexte und zwar mit dem YUI Compressor, einem Java-Programm, dass die Vorteile von Douglas Crockfords JS Minifier, Dojos Shrinksafe und Dean Edwards Packer vereint. Toll an der Java-Variante ist, dass sie ganz einfach in den Deployment-Prozess mit ant eingebunden werden kann.

Timo hat mich noch auf den Javascript and CSS Obfuscator aufmerksam gemacht. Schau ich mir auf jeden Fall mal an! Ihr auch?

Performance gegen gut wartbaren, übersichtlichen Code. Mehrfach habe ich schon geschrieben, dass ich es wichtig finde hier die richtige Balance einzuhalten. Doch wo beginnt die richtige Balance und wo endet Sie, wenn man sich sicher ist einen Quelltext eigentlich nur ein Mal anzufassen, wie beispielsweise beim Setzen einer Konstante? Als Beispiel habe ich mir Zeit ausgesucht, denn Zeit ist so wunderbar konstant und klar geregelt. In einem Snippet von mir habe ich folgende Zeilen entdeckt:

// Variante 1
TIME = {
	MILLISECOND:   1,
	SECOND:     1000,
	MINUTE:     1000 * 60,
	HOUR:       1000 * 60 * 60,
	DAY:        1000 * 60 * 60 * 24,
	WEEK:       1000 * 60 * 60 * 24 * 7,
	MONTH:      1000 * 60 * 60 * 24 * 30,
	YEAR:       1000 * 60 * 60 * 24 * 365
}

Aber muss der Browser wirklich bei jedem Aufruf diese Konstanten berechnen, wenn wir ihm nicht vorher die Arbeit abnehmen könnten? Das könnte dann kommentiert so aussehen:

// Variante 2
TIME = {
	MILLISECOND:      1, // 1
	SECOND:        1000, // 1000 *  1 
	MINUTE:       60000, // 1000 * 60
	HOUR:       3600000, // 1000 * 60 * 60
	DAY:     1000606024, // 1000 * 60 * 60 * 24
	WEEK:    7004242168, // 1000 * 60 * 60 * 24 *   7
	MONTH: 100060602430, // 1000 * 60 * 60 * 24 *  30
	YEAR:  365221198760  // 1000 * 60 * 60 * 24 * 365
}

Sean hat vor dem Verfassen des Artikels mit mir darüber sinniert, dass Variante 2 zwar eine höhere Performance hätte, aber natürlich auch wesentlich feheranfälliger wäre, da man hier nicht auf einen Blick erkennen kann, ob hohe Zahlen wirklich stimmen.

Als gangbarer Mittelweg ist uns folgender eingefallen:

// Variante 3
TIME = {
	MILLISECOND:    1,
	SECOND:      1000 * TIME.MILLISECOND,
	MINUTE:        60 * TIME.SECOND,
	HOUR:          60 * TIME.MINUTE,
	DAY:           24 * TIME.HOUR,
	WEEK:           7 * TIME.DAY,
	MONTH:         30 * TIME.MONTH,
	YEAR:         365 * TIME.DAY
}

Hier werden zwar Rechnungen vorgenommen, aber wesentlich weniger als in Variante 1 und der Code ist lesbarer als Variante 2, dadurch aber langsamer.

Fazit
Es gibt immer wieder Orte, an denen man Abstriche machen muss und viele akzeptable Lösungen, je nach Zielanspruch. Welche wir wählen, sollte von den Vorraussetzungen des Produktes abhängen.

Frage
Welche der drei oben genannten Varianten findet ihr am besten? Welche würdet ihr am ehesten in Projekten einsetzen? Habt ihr vielleicht eine noch ganz andere Idee, solche Konstanten sinnvoll zu definieren? Ich freue mich auf Kommentare!

Verschlüsselung mit Javascript ist schon immer ein Thema gewesen. Besonders dann, wenn man nicht die Möglichkeit hat einen Server mit https zu betreiben, ist es sinnvoll Logindaten (Benutzername, Passwort,…) wenigstens mit einem Pre-shared Key zu verschlüsseln. Hierzu bieten sich MD5 oder SHA1 an. Paul Johnston hat sich die Mühe gemacht und MD4, MD5 und SHA1 mit Javascript zu realisieren. Nicht wirklich der schönste Code, aber es funktioniert (und vielleicht erbarmt sich ja einmal Jemand, Diesen umzuschreiben).

Ich muss mich hoch und heilig entschuldigen. Im Oktober habe ich über Flaschenhälse und Schleifenköpfe gebloggt. Sean hatte die Idee, dass Pre-Inkremente schneller seien, als Post-Inkremente. Mit dem Profiler, den ich im Oktober genutzt habe, konnte ich keine Differenz feststellen und habe daher gebloggt, dass die Nutzung von Pre-/Post-Inkrement keinen Unterschied macht. Doch tatsächlich – es macht einen Unterschied. Pre-Inkremente sind definitiv schneller als Post-Inkremente. Eine These dazu ist, dass sich die Umgebung nicht einen Moment länger die alte Variable merken muss. Testen könnt ihr das ganze mit dem Profile.js und folgendem Quelltext:

profile([
    function() {
        var i = 0;
        i++;
        i++;
        i++;
        i++;
        i++;
        i++;
        i++;
        i++;
        i++;
        i++;
    },
    function() {
        var i = 0;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
        ++i;
    },
], 100000);

Um für zukünftige Blogartikel im Bereich Performance Javascripte plattform- und browserübergreifend auf ihre Geschwindigkeit hin testen zu können, habe ich mir hierzu ein Werkzeug gebaut. Es ist eine Javascript-Funktion, die sich um das Profiling übergebener Methoden kümmert. Übergeben wird ein Array mit Methoden, dessen Dauer getestet verglichen werden soll. Als zweiter Parameter wird die Anzahl der Durchläufe für jede Methode angegeben. Hier sollte man Werte ab 10.000 eintragen, da ein Unterschied sonst nahezu unmessbar ist. Als Resultat erhält man ein Array mit den Millisekunden, die die jeweilige Methode auf alle Cycles verbraucht hat. Die Sortierung des Arrays entspricht der Sortierung des Eingabearrays methods.

function profile(methods, cycles) {
  var methodDurations = [];
  for(var i = 0, count = methods.length; i < count; i++) {
	var methodStart = (new Date()).getTime();
	
	for(var j = 0; j < cycles; j++) {
	  methods[i]();
	}
	
	var methodEnd = (new Date()).getTime();
	methodDurations.push(methodEnd - methodStart);
  }
  return methodDurations;
}

Ideen

• Validierung der Parameter
• Möglichkeit Parameter für die aufzurufenden Methoden zu übergeben
• Andere Ausgabeformate als Array

Vorschläge
Habt ihr Ideen oder Vorschläge zum Profile.js? Was ist sinnvoll, was eher nicht? Welche Erweiterung würdet ihr euch wünschen? Fragen über Fragen, mich interessieren die Antworten. Ich freue mich auf Kommentare!

Mit Dirk habe ich mir vor einigen Tagen darüber Gedanken gemacht, ob man wohl HTML-Attribute auch in Single Quots einschliessen dürfe. Die Antwort liefert das W3C uns sie lautet eindeutig: Ja. Die Frage, die sich mir aber aufdrängt ist aber, ob das überhaupt sinnvoll ist. Bisher schreibe ich HTML-Attribute stets in Double Quotes und alles rund um Javascript in Single Quotes.

Beispiel

HTML
<a href="http://www.javascript.io" id="somelink">Javascript Blog</a>

Javascript
document.getElementById('somelink');

Frage
Wie macht ihr das? Habt ihr strikte Trennung verschiedener Quotes oder gar eine Coding Guideline für Javascript-/CSS-/HTML-Quelltext? Welche Quotes nutzt ihr für euren Preprozessor, wie PHP?

Schon in der Schule hat man gemerkt, dass es ab und zu ganz gut war, einen kleinen Spicker bei sich gehabt zu haben. So geht es mir auch ab und zu im Leben und darum stelle ich euch meine 5 täglichen Begleiter heute endlich vor.

• Javascript Cheat Sheet
• jQuery Cheat Sheet
• jQuery Cheat Sheet Übersicht - Danke Frank
• Prototype Cheat Sheet
• XSS Cheat Sheet
• Scriptaculous Cheat Sheet

Es gibt viele Orte an denen man sich über Javascript unterhalten kann. Eher ein Geheimtipp ist bisher die englischsprachige XING-Gruppe Javascript, die von Chris gegründet wurde. Wer bereits in XING verweilt ist selbstverständlich herzlich eingeladen im Sinne des Herren... – pardon Javascript – Furore im Forum zu machen. Wer bisher XING noch gar nicht nutzt kann sich hier kostenlos bei XING anmelden.