blog.formatvorlage

Ich habe ihn leider noch nicht selbst testen können, aber wenn das alles stimmt, was man über den IE 9 lesen kann… Heute wurde die zweite Preview veröffentlicht, siehe dazu einen Artikel im IEBlog über JavaScript Performance und im Internet Explorer Testing Center. Hut ab, Microsoft. Ehre wem Ehre gebührt. Die grauen Haare verzeihe ich euch trotzdem nicht.

[UPDATE] Dazu (un)passend dann folgender Artikel auf TheRegister über Canvas Support in IE 9.

Während im Fenster nebenan couchdb compiled, habe ich mir nochmal Gedanken um die geeignetste JavaScript-Engine für meine Prototyp Web Framework Bastelei gemacht. Spidermonkey hat den absolut gewichtigen Vorteil von JavaScript 1.8, das aber leider nicht standardisiert ist. Und es in dieser Form auch nie wird, siehe das Gezänke um ECMAScript 4 letzten Herbst. Mit 1.8 würde ich auch E4X bekommen, was meiner Meinung die absolut heisseste Sprachumfangserweiterung ist, die mir je untergekommen ist. Also XML als First-class Datentyp mit der Möglichkeit komplexer Queries. Und mit V8 bekomme ich die zur Zeit mit Abstand schnellste JavaScript Engine. Da ich auf Framework-Ebene Geschwindigkeit als höchste Priorität ansehen würde, besonders in diesem Fall, habe ich mich für V8 plus v8cgi entschieden. Aber Generatoren, Iteratoren, E4X und ein Haufen anderes sind verdammt verlockend. Und ist nicht Entwicklereffizienz viel wichtiger als Prozessorleistung, weil letztere im Gegensatz zu ersterem eine wesentlich höhere Skalier- und Verfügbarkeit besitzt? Die Entscheidung ist nicht einfach. Superspannend ist aber, dass überhaupt eine Entscheidung nötig war. Spidermonkey war bis vor einer Weile die einzige (mir bekannte) frei verfügbare JS-Engine. Abgesehen natürlich von Rhino, ebenfalls von Mozilla, aber leider in Java geschrieben, sprich: absolutes No-go. Und seit ein paar Monaten gibt es V8. Irgendwann kommt dann auch noch Tracemonkey. Und Konkurrenz belebt das Geschäft, wie man in den letzten Monaten an den Benchmark-Duellen gesehen hat. Und es zeigt, dass JavaScript ganz gewaltig auf dem Vormarsch ist.

Die üblichen Verdächtigen, die JavaScript für eine Spielzeugsprache halten – üblicherweise übrigens häufig gerade die Gruppe von Entwicklern bei denen ich denke, dass sie ohne IDE mit Code Completion so aufgeschmissen wären, als ob sie mit verbundenen Augen aus dem Stadtzentrum von Kuala Lumpur den Weg nach Hause finden müssten – übersehen meistens eins: JavaScript ist die erste Mainstream-Programmiersprache, welche von der offenen Architektur des Web getrieben wurde. Und von der Hemdsärmeligkeit, die damit verbunden ist. Und, vielleicht am wichtigsten, aufgrund der offenen und verteilten Natur des Webs mit solchen Dingen wie der Same Origin Policy und parallelen, aber getrennten Ausführungskontexten umgehen lernen musste. Was allerdings den größten Schub geben wird: die Frontends von Web Applikationen werden sich stärker von der Middleware trennen. Massive wollmilcheierdings Web Application Frameworks und Server sind so dermaßen old school, dass jede 80er Jahre Party dagegen wie ein Tokio Hotel Konzert wirkt. Dafür werden die Client- und Serverbestandteile des Frontend stärker verschmelzen. Was man dann will, ist einfach: eine gemeinsame Code-Basis für Funktionalität, die auf beiden Systemen identisch funktionieren soll. Und, nicht zuletzt: Type Safety ist sowas von für Pussies . Aber, ich schweife einen ganzen Absatz ab und das ist eigentlich ein Thema für einen weiteren Post. Gute Nacht.

Die jüngste Zero-Day-Exploit Warnung für IE-User ist nichts ungewöhnliches, insofern ein müdes *gähn* und mein herzlichstes Beileid für alle, die noch den IE verwenden. Richtig bemerkenswert fand ich im Heise Security Artikel allerdings diesen Hinweis:

“Dazu gehört unter anderem der wenig praxistaugliche Tipp, Scripting zu deaktivieren, ohne das es auf eine[r] Reihe von Webseiten zu Problemen bei der Darstellung und Bedienung kommen kann.”

Wow, kann mich nicht erinnern, dass jemals gelesen zu haben. Normalerweise heisst es immer, “…hilft es nur, JavaScript zu deaktivieren”. Eine ziemlich nervige Gegenmaßnahme, die nicht zuletzt über Jahre hinweg  dazu beigetragen hat, JavaScript den schlechten Ruf zu verpassen, den es (noch) hat. Aber, im Jahr 2008, dem Jahr 3 von Web 2.0, scheint es ohne JavaScript nicht mehr zu gehen und die altbekannte Gegenmaßnahme gehört in die Mottenkiste. Großartig.

Irgendwie hab ich geahnt, dass es mit MultipleIE Ärger gibt. So richtig unabhängig schien das alles nicht zu sein, außerdem haben z.B. Bookmarks nicht funktioniert und brachten bei Auswahl immer den Druckdialog zum Vorschein. Auch bei der Entwicklung und Debugging hatte ich häufig den Eindruck, dass das nicht wirklich der Internet Explorer 6 war, mit dem gearbeitet habe. Die Performance war noch mieser als gewohnt und es kann zu merkwürdigen Darstellungsfehlern, die ich von Systemen ohne MultipleIE nicht kannte. Für Entwicklung und Tests auf Produktionsqualitätsniveau kann ich von MultipleIE aus meiner Erfahrung nur abraten. Glücklicherweise hat Microsoft zum richtigen Zeitpunkt neue VirtualPC Images für Internet Explorer 6, 7 und 8 mit Windows XP und Vista freigegeben. Die gelinkten Images sind gültig bis zum 3. Juli.

Ziemlich abgefahren, was man in 20 Zeilen JavaScript anstellen kann…

Nach einigen intensiven Tagen jQuery (gepriesen seiest du) habe ich gerade beim Coden eines Plugins der Standard-Versuchung “Verwende ein if-else um jeweils eine Methode in Abhängigkeit eines Boolean aufzurufen” widerstanden. Stattdessen kam das raus:

$(node)[$(node).children() ? 'append' : 'prepend'](self);

Viel schöner

Nachdem auf dem Webkit-Blog erst vor drei Tagen der JavaScript-Benchmark SunSpider vorgestellt wurde, hat sich Jeff Atwick von Coding Horror mal die Mühe gemacht, Opera 9.5, Safari 3.0.4, Internet Explorer 7 und Firefox 2 unter Windows Vista gegeneinander antreten zu lassen. Die Ergebnisse sind interessant, allerdings nur unter Vorbehalt zu betrachten. Firefox 2 schneidet mit einem dritten Platz nicht gut ab, konnte sich den allerdings nur deswegen sichern, weil der IE 7 bei der String-Performance so derbe versagt hat (4-mal langsamer als der schnellste Opera und 2-mal langsamer als Firefox). Das deckt sich mit dem, was wir bei der Arbeit an komplexen Applikationen entdeckt haben. Wenn ich mich recht erinnere, hängt das mit der insgesamt extrem schlechten Performance bei der Instantiierung von Objekten zusammen. Real-World Applikationen, die üblicherweise mit einem Haufen Strings arbeiten, kann man mit String-Pooling auf dem IE einen deutlichen Geschwindigkeitsvorteil verpassen.

Die schnelle Engine nutzt dem IE allerdings in der echten Welt allerdings wenig, da er speziell in der DOM-Performance um Längen schlechter als zum Beispiel Firefox. Das geht so weit, dass es sogar trotz der schlechten String-Performance schneller ist, größere Manipulationen am DOM nicht über die Methoden von DOM-Elementen zu erledigen, sondern durch das Zusammenkleben eines Strings mit anschließender Zuweisung mittels innerHTML.