Javascript Performance

Mal ganz ehrlich, als ich gerade »A Study of Ajax Performance Issues« gelesen
habe, ist es mir doch ziemlich kalt den Rücken hinuntergelaufen. Ich fasse mal kurz zusammen – die folgenden Programmiertechniken sind in Zukunft zu vermeiden, da sie, auf dem
einen und/oder dem anderen Browser, einen Performanceeinbruch zur Folge haben:

  • das Anlegen von Arrays (alle) und Objekten (FF), sowie Operationen auf Arrays (alle),
    speziell „in“-Operationen (FF)
  • Operationen auf dem DOM (alle)
  • Berechnungen von computed style und des box-model
  • Manipulationen an
    Strings, jeglicher Art und seien sie noch so einfach (IE)

Die gute Nachricht: if und else sind noch erlaubt, insofern stehen uns alle
Möglichkeiten offen. Gnnpf.

CSS Reference

Wer die Sitepoint-typischen Werbeangriffe blocken oder aushalten kann, findet hier: CSS Reference alles über CSS, was man so wissen muss, um als Geek zu gelten.

Javascript Packer und Security

Was man bei SecureWorks [via] nachlesen kann entspricht genau der Diskussion, die wir vorige Woche mit unseren Serverwächtern zu führen hatten. Tenor, hier wie dort:

While the use of packers is widespread, all have drawbacks. These include:

  • The inability to easily verify and audit code
  • The administrative overhead of repacking code for each change
  • Suboptimal compression
  • The increased risk of false negatives which may lead to a site being used to spread malicious code
  • The increased risk of false positives, which may lead to a site or some of its functions being blocked by security controls
  • Noticeable negative impact on client-side performance.

Site owners, operators, developers and administrators can achieve intended results — typically reducing the number of bytes downloaded from the server — with greater degree of success and fewer side-effects using one or more alternative tactics:

  • Not compressing JavaScript code at all
  • Reliance on increases in average available bandwidth
  • Reliance on local and network caching
  • Not using more JavaScript functions than necessary (smaller library „builds“)
  • Using only safe whitespace/comment reduction techniques
  • Automatic application of safe techniques as a last step in the publishing process
  • The use of mod_deflate/mod_gzip for compressing the HTTP response data
  • The use of jar files to package JavaScript (these can be cryptographically signed to further enhance authenticity of code, and hence improve security)

OK, das ist einleuchtender, als das Voodoo-Ihr-Programmieraffen-seid-alle-blöd-Zeugs, das ich mir sonst anhören muss. Wir sind auch bereits dazu übergegangen, wieder ungepackten Code zu schicken. Teilweise sofort, teilweise wird es releaseabhängig noch ein wenig dauern.

Ich bin gar nicht so traurig, den Packer zu kicken… der Releasecycle war immer sehr nervig. Zudem bin ich mal wieder völlig leidenschaftslos, zudem ich ja auch selbst immer wieder sage, wie evil eval() ist. 😉

Langer Atem für HTML5

Ich habe es schoneinmal gesagt: wenn HTML5 fetriggestellt, verabschiedet und durchgesetzt ist, dann bin ich natürlich schon in Rente (und freue mich darüber). Bei den Webkrauts verweist man in diesem Zusammenhang auf die Mondlandung 1969, was natürlich witzig ist.

Man wird sich aber wohl leider mit langen Einführungsphasen abfinden müssen, denn obwohl sich der Inhalt des Netzes schnell ändert, ist die Technik, die auf unendliche viele anonyme Einheiten verteilt ist, nur schwerlich umstellen.

Trotzdem kann man natürlich beginnen, HTML5 zu benutzen – jedenfalls dort, wo nichts dadurch kaputt geht.Und setzt man den HTML5-Doctype ein <!DOCTYPE html>, springen alle aktuellen Browser in den Standard-Mode und IE8 wird die IE8-Renderingengine nutzen [John Resig].

Wer also schon mal schauen will: The Web Developer’s Guide to HTML 5.

This is a free concert from now on…

last.fm[me, there] war ja schon immer meine Lieblingsseite in Sachen Musik, auch wenn mir meine über die Jahre gescrobbelten Tracklists ein wenig spooky und viel zu gradlinig erscheinen. Nun kann man sich bei last.fm in den USA, UK und bei uns Musik-Titel und Alben in voller Länge und kostenlos streamen lassen, direkt auf der Website. Dazu hat man Verträge mit Universal, EMI, Sony BMG und Warner Music gemacht, hinzu kommen ca. 150.000 Titel von freien Künstlern oder Indpendent-Labels [siehe Artikel bei golem.de]. Bezahlt werden soll das von den Werbeeinnahmen der last.fm Seiten, die 20 Mio. User im Monat haben sollen [ebenda], und zwar pro gestreamten Song.

Na, da werfen alle die Hände in die Luft oder holen die Luftschlange raus… aber, es gibt natürlich eine Einschränkung: nach dem dritten Abspielen eines Titels geht ihm dann fortan ein Hinweis auf die last.fm-Partner voran, bei denen man den Track erwerben kann. Und dies alles gilt zunächst mal nur für den öffentlichen Betatest, danach wird es auch eine Art Premium-Abo geben…

X-UA-Compatible mit mir?

Wie gestern schon angemerkt, wollte ich mir ein paar Gedanken zum neuen Vorwärtskompabiltätsfeature aus dem Hause Microsoft machen. Dazu habe ich erst mal viel gelesen.

Die Gründe für die Einführung einer neuen Methode zur Sicherung der Kompabilität zwischen Code und Browser finden sich, wie so oft, in der Geschichte des Internet Explorers. Beim Wechsel von IE5 auf IE6 (bzw. schon vorher beim IE5Mac) benutzte man den sogenannten DOCTYPE switch, mit dem man via Code zwischen den Kompabilitätsstufen (Quirks- und Standardmode) des IE6 hin- und herschalten konnte (und bsi heute kann). Wissen wir alles, hat aber wohl für die Einführung des IE7 nicht so funktioniert, wie geplant:

In IE7 we made a lot more changes to improve IE’s standards compliance, particularly with CSS. We limited these behavior changes to IE’s “standards mode” only, and we expected that this would help limit compatibility problems as it had in the past. Unfortunately, and somewhat surprisingly to us, this wasn’t true; many of those changes made IE incompatible with content that was already part of the web. It turned out by the time IE7 shipped in late 2006, roughly half of the top 200 US web sites were in “standards mode”. Many of those sites had been “opted in” to standards mode by a tool that generated their content; many of them had probably been hand-coded by someone who was trying to do the right thing, and make their HTML code valid according to the W3C. Regardless, users of those sites expected them to keep working the same, even when they downloaded a new version of IE. Unfortunately, that didn’t happen.

Womit man ungefähr abschätzen kann, welchen Überblick man beim IE-Team über den Stand der Webentwicklung hat. Aber egal: mit IE8 wird alles besser (sagt man), womit man nun auch irgendwie endgültig zu gibt, das IE6 ein Witz und IE7 auch noch nicht der groß0e Wurf waren – jedenfalls gibt es noch viel zu ändern.

Um nun zu verhindern, das die eigene Website im neuen Modus des (noch nicht vorhandenen) IE8 – und vor allem zukünftige Versionen – möglicherweise falsch gerendert wird, hat man zu dem bekannten DOCTYPE switch nun eine weitere Alternative: <meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />. So kann man seine Website schützen, vor ungewollter Innovation (?) – nein, gegen plötzlich auftauchende neue IE-Versionen. Nun mal im Ernst: so kann man sich ncoh vorne hin zumindeest absichern, eventuell neue oder reparierte Features kann man ja nachziehen, in späteren Versionen nutzen. Macht also so, neben aller Häme, einen ganz interessanten Eindruck. Allerdings: die vorgesehene Standardschaltung läasst einen schon die Nase rümpfen: wenn man nicht ausdrücklich dem Browser mitteilt, das die IE-8-Engine genutzt werden soll, wird die IE7-Engine benutzt. Ohne Doctype dann sogar nur IE5.5, gnnpf.

When you put it that way, it does sound kinda nuts. No matter what future version of IE you’re using—be that IE8 or IE80—if the developer hasn’t added the appropriate meta tag, you’ll be viewing the site as if in IE7.

Streit ist da vorprogrammiert. Anne van Kersteren regt sich reichlich auf, und fragt sich wohl nicht ganz zu Unrecht, warum die Entwicklerwelt die IE folgen solle und nicht umgekehrt. Was ihn sehr wurmt ist vor allem, dass [Teile des] WSP sich zur Unterstützung der Sache haben ‚rumkriegen lassen:

It appears that they managed to convince “the experts” of the Web Standards Project to deliver the message on no less than A List Apart. Fortunately, the comment crowd does not seem to be buying it. [As it turns out the Web Standards Project as a whole was not aware of this until publication on A List Apart.]

Andy Budd sieht hier beinahe eine Chance:

Clueless developers won’t know about this behaviour so every new site they build will automatically be rendered as IE7. Clued-up developers will use this as an excuse to freeze support for IE and turn their attentions to better browsers.

Unser holländischer Kollege P.P. Koch sieht es ein wenig anders, er meint, dass uns Microsoft einen Vertrag anbietet:

There’s a second difference: the versioning switch is a contract. The IE team tells people what will happen if they insert the <meta> tag in their pages, and it’s up to individual web developers to decide whether they want to use this contract or not.

Sehr interessant.

Und die Moral von der Geschichte? Ich weiss nun immer noch nicht so genau, wie ich dazu stehe. Es ist natürlich verlockend, das einfach zu ignorieren, so lange wären unsere Sachen auf IE7 festgenagelt. Bis Microsoft es sich anderes überlegt und mit IE10 auf das mitliefern der IE7-Engine verzichtet, Vertrag hin oder her…

Update/Nachtrag: John Resig hat herausgefunden, dass der HTML5-Doctype alle Browser in den Standardsmode, und IE8 in den IE8-Renderingmodus schaltet…