Stoyan Stefanov: JavaScript Patterns (Review)

Veröffentlicht am 29. November 2010

JavaScript-Patterns

Wenn man weiß, dass Stoyan Stefanov seine Brötchen bei Yahoo verdient, kann man schon erahnen, dass sein Buch JavaScript Patterns wohl kaum ein tiefer Griff ins Klo sein dürfte – und das auch nicht der Fall. Auf etwas über 200 Seiten geht es um Entwurfsmuster für JavaScript und das, was dort zu Papier gebracht wurde (ein Mix aus Best Practices und Codeschnipseln), hat sachlich absolut Hand und Fuß. Von grundlegenden Dingen wie Finger weg von new Array() über clevere Tricks mit Funktionen bis zu einem von A bis Z durchexerzierten Modulsystem ist eigentlich alles geboten und auch viele Antipatterns werden gezeigt und erklärt. Also, ein Super-Buch das man sich ohne großes Nachdenken sofort ins Regal stellen sollte? Das kommt ganz drauf an.

Das Buch dürfte für all diejenigen interessant sein, die alle JavaScript-Basics soweit auf dem Kasten haben, dass sie alle Aufgaben des täglichen Webworkertums im Schlaf erledigen und die in Zukunft planen, mehr als nur eben jene Standardaufgaben in Angriff zu nehmen. Für alle, die tendenziell eher JavaScript-Anfänger sind, bietet das Buch zu wenig Grundlagenarbeit. Für alle, die auch in Zukunft nicht vorhaben, mehr als ein paar jQuery-Animationen zusammenzuhauen, gibt es zu wenig Praxisbezug. Das Buch enthält zwar ein Kapitel über DOM-Patterns, aber falls man bereits eine JavaScript-Bibliothek verwendet (und wer tut das nicht?), wird man diese nicht wirklich brauchen. Und wer schon ein ausgewachsener JavaScript-Super-Nerd ist, dürfte sich ein wenig langweilen, denn bahnbrechend Neues werden auch nicht präsentiert. Um das Ganze grafisch darzustellen:

JavaScript Patterns kaufen oder nicht kaufen?

Das ist dem Buch nicht zum Vorwurf zu machen – es ist eben inhaltlich so konzipiert. An dem was drin steht ist absolut nichts auszusetzen, die Frage ist nur, ob der Inhalt für Jeden relevant ist. Wer noch gar kein JS kann oder mit seinen Scripts bis auf weiteres nur Websites zu dekorieren gedenkt, braucht es eher nicht. Alle anderen erhalten ein Büchlein, in dem vielleicht nicht viel Neues steht, aber das in jedem Fall zumindest ein taugliches Nachschlagewrk abgibt – und wenn man bedenkt, was für einen Bockmist eine Google-Suche nach beliebigen JavaScript-Themen zutage fördert, ist das eigentlich schon viel wert.

Internet-Explorer-Facepalm du jour

Veröffentlicht am 22. November 2010

Ich glaube ja manchmal, dass die meisten Leute da draußen gar keine Ahnung davon haben, wie verranzt der Internet Explorer tatsächlich ist. Und mit „Leute“ meine ich nicht nur Otto Normalnutzer, sondern auch manchen Webentwickler – mich eingeschlossen. Dass der IE ob seines biblischen Alters manches Feature nicht unterstützt und CSS manchmal kreativer als nötig interpretiert, ist hinreichend bekannt, aber man findet immer wieder etwas Neues.

Als ich vor ein paar Tagen über Tag-Auslassung in HTML schrieb bezog ich mich mitnichten auf eine Erfindung jüngerer Zeit, sondern auf ein Feature, das HTML seit Anbeginn der Zeiten hatte. In den Beispielen der ersten HTML-Version werden grundsätzlich Tags ausgelassen und in Version 2 der Spezifikationen heißt es explizit: Some elements only have a start-tag without an end-tag. Das ist also alles nichts Neues und HTML-Parser wissen seit jeher mit den fehlenden Tags umzugehen. Aber mit den Browsern ist es wie mit den gallischen Dörfern – irgendwer leistet immer Widerstand und das gern auch mehrere Epochen lang. Man nehme einmal folgenden hamlos aussehenden HTML-Schnipsel:

<!DOCTYPE html>
<head>
<title>Hallo</title>
<div><form>Welt</form></div>

Was hier passieren soll, ist logisch: nach dem </title>-Tag müsste der Browser merken, dass das nun folgende <div> nichts für das Head-Element ist und entsprechend ein Body-Element einfügen. Genau das machen auch alle Browser, inklusive der IE-Familie, doch letztere macht auch noch ein bisschen mehr als das:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML Strict//EN">
<html>
    <head>
        <title></title>
        <form>
            <body>
                <div>
                    Welt
                </div>
            </body>
        </form>
    </head>
    <body>
        <div>
            Welt
        </div>
    </body>
</html>

Ich bin mir noch nicht ganz darüber im klaren, was hier genau passiert, aber richtig ist dieses Ergebnis sicher nicht. Dass der Title nicht in der DOM-Ansicht des IE erscheint ist (so wie ich das sehe) normal, ebenso das Austauschen des Doctypes. Der folgende Elementsalat ist es definitiv nicht. Und sobald man an der richtigen Stelle ein <body>-Tag einfügt, macht der IE alles richtig:

<!DOCTYPE html>
<head>
<title>Hallo</title>
<body>
<div><form>Welt</form></div>

Ergebnis:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML Strict//EN">
<html>
    <head>
        <title></title>
    </head>
    <body>
        <div>
            <form>
                Welt
            </form>
        </div>
    </body>
</html>

So lange man also dem IE sagt, wo genau das Body-Element beginnen soll, passiert nichts schlimmes. Mir war diese Problematik bisher immer deshalb entgangen, weil ich immer ein Body-Starttag plus Conditional Comments verwende um CSS-Fehler im Internet Explorer auszubügeln. Ich danke Francesco für den sachdienlichen Hinweis auf diesen Internet-Explorer-Facepalm du jour.

Warum Websites ohne JavaScript zu funktionieren haben

Veröffentlicht am 9. November 2010

Ich habe noch einen halbfertigen Rant auf Halde, in dem ich am Beispiel eines gewissen, aus unerfindlichen Gründen populären E-Commerce-Systems (dessen Name mit M anfängt und mit agento aufhört) auf Websites schimpfe, die ohne JavaScript nicht funktionieren. Da ich mir aber ziemlich sicher bin, dass ich mich dort gleich mehrfach im Ton vergriffen habe, lösche ich diesen Text jetzt und lasse Jenn Lukas sprechen. Die gute Frau bringt die wichtigsten Gründe nämlich in wesentlich zivilisierterer Form vor, als ich mir das gelingen würde und liefert uns einen schönen kurzen Vortag, den man wunderbar als Munition gegen die meine-Website-muss-ohne-JS-nicht-funktionieren-Fraktion verwenden kann:

Jenn Lukas - JSConf 2010 auf Blip.tv

Alle guten Gründe hin und her – was mich an JS-untauglichen Webseiten mehr als alles irritiert, ist dass es sie überhaupt gibt. Wenn man nur kurz überlegt, bevor man draufloshackt, passieren ohne JS benutzbare Websites wie von selbst. Unobtrusive JavaScript ist kein Hexenwerk, sondern, sofern man seine Auszeichnungs- Gestaltungs- und Script-Schichten sauber trennt, fast unvermeidlich. Um Seiten zu bauen, die nur mit JavaScript funktionieren, muss man sich richtiggehend anstrengen. Und mir ist nicht wirklich klar, was in den Köpfen jener vor sich geht, die sich diese Mühe machen und derartiges HTML an die Öffentlichkeit lassen:

<button type="button" class="button" onclick="productAddToCartForm.submit()"><span><?php echo $this->__('Add to Cart') ?></span></button>

Klar, wenn man ein hyper-dynamisches neues Webapp rund um neueste JavaScript-Features herum konstruiert und das Projekt ohne JS prinzipbedingt nicht funktionieren könnte, wäre das etwas anderes. Aber eine herkömmliche Website oder einen Onlineshop mutwillig oder fahrlässig fest an JS zu binden, ist, als würde man über das Schiebedach in ein Auto einsteigen. Das kann man sicher so machen, aber wenn vorher nur kurz nachdenkt und entsprechend plant, kommt man ohne zusätzliche Mühen auch anders in die Karre – und sieht dabei dann auch nicht aus wie ein Vollhonk.

Keine Angst vor minimalem HTML(5)!

Veröffentlicht am 8. November 2010

Nach all den Jahren, in denen sich XHTML 1 größter Beliebtheit erfreute, sieht für viele Webworker so etwas aus wie ein einziger Syntaxfehler:

<!DOCTYPE html>
<meta charset="utf-8">
<title>Hallo Welt!</title>
<p class="welt">Hallo Welt!
<ul>
    <li>Lorem
    <li>Ipsum
    <li>Dolor
</ul>

Da fehlen zwar einige Start- und End-Tags, aber tatsächlich ist das ein absolut gültiges HTML(5)-Dokument. Man kann das gleiche Dokument natürlich auch so schreiben …

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <meta charset="utf-8" />
        <title>Hallo Welt!</title>
    </head>
    <body>
        <p class="welt">
            Hallo Welt!
        </p>
        <ul>
            <li>Lorem</li>
            <li>Ipsum</li>
            <li>Dolor</li>
        </ul>
    </body>
</html>

… aber hat man etwas davon? Der Browser (jeder Browser) baut aus beiden HTML-Schnipseln das exakt gleiche DOM und damit die exakt gleiche Website zusammen. Tags wie <body> und </li> werden vom HTML-Parser auf eigene Faust an den richtigen Stellen eingebaut, so dass es im Endeffekt völlig egal ist, ob man HTML in der Spar-Variante schreibt, das XHTML-Lookalike nimmt oder sich seine eigene Mischform zusammenkombiniert. Welche Tags man unter welchen Umständen auslassen kann erklären unter anderem die HTML5-Spezifikationen.

Die Präsentation des ersten HTML-Schnipsels sorgt manchmal für erhebliches Gruseln, doch wenn man mal die ersten Abwehrreflexe sieht unaufgeräumt aus und kenne ich nicht überwunden hat, wird klar, dass minimales HTML durchaus seine Vorteile hat: man tippt schließlich weniger und transferiert weniger Bytes zum Browser des Users. Das Einzige, auf das man manchmal aufpassen muss, sind die Inhalte an den Grenzen ausgelassener Tags. Angenommen dies wäre unser HTML:

<!DOCTYPE html>
<meta charset="utf-8">
<title>Hallo Welt!</title>
<script>alert("Hello World!")</script>
<p class="welt">Hallo Welt!
<!-- Saluton Mondo! -->

Wo werden hier </head> und </body> eingefügt? Landen der Kommentar und das <script>-Element außerhalb oder innerhalb des Bodys? Die Antwort: das Script landet im Head und der Kommentar als letztes Element im Body. Der Parser schließt den Head erst, wenn er das erste Element antrifft, dass keinesfalls im Head vorkommen kann, was in diesem Fall das <p> wäre. Gleiches gilt beim Kommentar, denn der könnte zwar auch erst nach dem Body kommen, aber der Parser hat keinerlei Anlass, den Body vor dem Kommentar zu schließen. Wenn es bei solchen zweideutigen Elementen wie Scripts und Kommentaren mal wirklich wichtig ist, was in solchen Grenzgebieten wo landet sind die optionalen Tags von unter anderem <html>, <body> und <li> das Mittel der Wahl, aber sonst? Kann man machen, muss man nicht.

Update: Lest das hier um zu verhindern, dass euch fehlende Body-Starttags im IE in den Hintern beißen.