Vorwärts Männer, wir müssen zurück: Komprimieren oder Abbauen?

Mit der Kompression von Javascripten habe ich in letzter Zeit ein wenig Erfahrung gesammelt, aus gegebenem Anlass sozusagen. Dean Edwards sammelt hierzu nocheinmal die Fakten, und hat ein paar gute Tips parat. Es bleibt aber eine Krux: Komprimierung ist super, besser ist es jedoch, von Anfang an mit kleinerem Datenaufkommen arbeiten zu können (das kann man dann immer noch komprimieren). Mit dem Mißverständnis, seit »Web2.0« könne man mit ein wenig Javascript auf Webseiten so ziemlich alles veranstalten, haben zwei wesentlich Fehler Einzug in die Aufgabenstellung am Frontend genommen:

  • Javascriptanwendungen als Beigabe zu sowieso schon großen Websites – geparrt mit dem Glauben, nur weil man etwas machen könne, sei es auch gut einfach und sinnvoll: hier noch ein Widget, da noch ein Gimmick, über den “Sinn” wird sich dabei kaum oder zuwenig Gedanken gemacht.
  • Unterschätzung einiger wichtiger Faktoren in diesem Zusammenhang: wie schränkt die extensive Nutzung von Javascript die Liste der Zielbrowser ein beispielsweise, oder welchen Aufwand bedeutet ist, selbige Liste trotz JS groß zu halten; wie wirken die genannten Widgets innerhalb des Auftritts und wie werden sie angenommen.

Und so weiter, leider. Da für den Auftraggeber derlei Programmierung oft Voodoo ist, kann er keine Abschätzungen zu diesen Fragen vornehmen, für ihn ist alles immer ganz einfach. Am Ende ist die Seite dann aber zu groß. Ergo: man muss immer schon sehr frühzeitig zum Ausdruck bringen, welche Folgen der massive Einsatz von Javascripten hat und den Aufwand-Nutzen-Faktor stets in Frage stellen. Denn: wenn’s am Ende nicht klappt sind selten die Auftraggeber die Schuldigen…

Hat man den vorzeitigen Einfluss versäumt, vergeigt oder einfach nicht gehabt, kann man immer noch darauf zählen, dass die Zeit die Wunden heilt. Mit anderen Worten: man bietet zur Behebung von Problemen wie bspw. übermäßiger Seitengröße an, die kleinen Javascriptspielereien wieder zurückzubauen. Letztendlich sind es ja nur Spielereien, und eh‘ der Auftraggeber seine eigenen inhaltlichen Anteile in Frage stellt, wird er freudig zustimmen. Natürlich muss man ein wenig aufpassen, dass nicht andere mit den Rückbaumaßnahmen beauftragt werden.

Blogstats Rückblick

Einen sehr interessanten Rückblick auf die deutschen Blogstatistken gibt’s bei Wortfeld. Zusammengefasst: Blogger, die vor 40 Monaten in den Blogstats-Top-50 waren, sind in der großen Mehrheit heute noch aktiv (wenn auch nicht mehr immer in den Top50). Nachfolge-Blogs wie dieses hier mitgezählt. Lustig: ich war damals auf Platz 43 und mit dem damals noch verwendeten Textpattern eine Software-Ausnahme. Die meisten nahmen da noch Antville und Movable Type. Kein WordPress.

Britain, Britain, Britain

Hat jetzt gerade nichts mit Frontendprogrammierung zu tun, aber es muss gesagt werden: falls die Updates hier in nächster Zeit ein wenig rar werden, liegt das einzig und allein daran, dass zwei neue Staffeln Little Britain den Weg zu mir gefunden haben, was mich die nächsten Zugfahrten über ziemlich beschäftigen wird. Was man jetzt schon einmal sagen kann: Matt Lucas und David Walliams haben in Staffel 2 kräftig an der Ekelschraube gedreht… oha. In England kommt die Serie ja dermaßen gut an, dass praktisch alle Engländer nur noch in Little-Britain-Verkleidung aus dem Haus gehen, soweit würde ich jetzt nicht gehen. Schalten sie nächste Woche wieder ein, wenn sie Tom Baker aka. Doctor Who (IV) sagen hören: »Britain. .. We’ve had running water for over 10 years, an underground tunnel linking us to Peru, and we invented the cat«. Ach herrjeh: es gibt sogar ein Little Britain PS2 Game

Webfonts 2 the rescue?

Håkon Wium Lie ist mit den roundabout 10 im Web zur Verfügung stehenden Fonts langweilig geworden und darum startet er einen Aufruf für Webfonts, verpackt in einen ALA-Artikel: CSS @ Ten: The Next Big Thing. Kurzum: Fonts sollen im Netz endlich als TrueType ausgetauscht und angezeigt werden können. Hmm. Mal abgesehen davon, dass sich der ALA-Text ein wenig nach Marketing anfühlt, die gezeigten Fontbeispiele IMHO ziemlich schlecht sind und genau das Grauen der unendlichen Fontvielfalt im Netz vorwegnehmen, will ich nicht konservatv auf dem Shit beharren, den uns Browser als Fonts anbieten. Von daher: im Auge behalten.

jQuery 1.1.4

Update: jQuery 1.1.4: Faster, More Tests, Ready for 1.2.

Hui, hatte ich so schnell gar nicht mit gerechnet. Gerade noch letzte Woche habe ich die 1.1.3 gepachted (aus reiner Ungeduld), da gibt’s schon wieder eine neue Version. Der Bug mit dem wir wirklich zu hadern hatten („Latest Nightlies Crash Safari 1.3.2„) ist gelöst, wie noch 53 andere. Mit dem festen Blick auf jQuery 1.2 gibt’s auch schon ein paar neue Funktionen, andere sind dafür ab sofort deprecated. Neu ist zum Beispiel die Methode .slice(), der Selektor :has, extend() wurde erweitert. Ebenso wie .noConflict(), mit dem man jetzt sowohl jQuery und dessen Abkürzung $ umbenennen kann.

Und hatte ich vor kurzem noch die XPath-Möglichkeiten gelobt, sind sie heute schon für überholt erklärt. Empfohlen wird die Nutzung der entsprechenden CSS-Ausdrücke, und es wird darauf hingewiesen, dass es ab 1.2 ein spezielles XPath-Plugin geben wird. Da freue ich mich jetzt mal ganz optimistisch drauf.

window.onload, schon wieder

Kann ich nicht mehr hören! Seit Wochen hadere ich ernsthaft mit den typischen Problemen, die auftreten, wenn man Events nicht mit (bösen, bösen, bösen 1) inline-Eventattributen („onclick“, etc.) zuordnen will (oder eben kann). Der Ladenvorgang eines HTML-Dokuments, vor allem eines sehr großen (hüstel), ist eine wacklige Angelegenheit, soviel kann man schon mal fesstellen. Da kann viel passieren: das DOM ist fertig, da wird vom Adserver noch etwas nachgeladen, huch, hier mal ein Flashlayer, der alles zerballert, der User klickt wild in der Navi herum, die immer noch nicht initialisiert ist, da funzelt noch ein AdBlocker dazwischen…

Konkret: es gibt natürlich verschiedene Lösungsansätze für das Problem, jQuery bedient sich der Methode von Dean Edwards für ihr eigentlich wunderbares jQuery.ready(). Nur, es funktioniert nicht immer. Und: was geht, und was nicht, hängt zu gut 60% von äußeren Umständen ab, also vom Browser, zusätzlich geladenen Skripten auf die man keinen Einfluss hat (Werbung) und wie schon gesagt, auch gerne mal einem Browserplugin. Und manchmal kommt auch ein ambitionierter Kollege und überschreibt alles mit einem fröhlichem onload. 😉

Ich stehe gerade kurz davor das Ganze wieder ganz altmodisch ins <body onload=""> zu verlegen, nur damit endlich Ruhe ist. Nein, da ist mir gerade nochmal Peter Michaux dazwischen gekommen. Er hat die einzelnen Methoden und Lösungen zumindest ordentlich analysiert und kommt zu ähnlichen Ergebnissen wie ich. Und hat eine Lösung.

My suggested solution trades a minor impurity in programmer ideals for an always functional UI. It’s an “if you can’t beat them, join them” solution. It’s a compromise but like Dan Cederholm’s compromise it is fixed string of attributes that is tacked on without any thought. It may be a challenge to build an efficient implementation of this solution but there is no hacking based on brittle browser features and no exposure. This solution depends only on documented browser features and behavior. That’s a compromise I can abide.

Peter hat eine Methode erdacht, die sozusagen das beste aus beiden Welten zu vereinigen weiss, nämlich jQuery.ready() und das hervorragende LiveQuery Plugin über das ich schon gestern kurz berichtet hatte. Ich werd’s testen.

1: Die Nutzung von inline-Eventattributen steht gegen die Trennung von Inhalt und Präsentation, der ich normalerweise anhängig bin. Ich bin zwar pragmatisch genug mich von soetwas zu kicken, wenn es drauf ankommt, aber da wir mit XML-Dokumenten arbeiten, die per XSLT in HTML gestyled werden, dass mit CSS gestyled wird… da geht das schon irgendwie zum Prozess. 😉 Zudem machen unterschiedliche Leute die XSLTs und die Javascripte etc. Da sind solche Trennungen auch für den Arbeitsprozess mehr als praktisch. Wenn’s funzt zumindest.