Angeregt von einem Artikel meines künftigen Arbeitgebers über die Weiterentwicklung von Firefox in den Versionen 10, 11 und 12, möchte ich ein paar Gedanken über die merkwürdige Prioritätenvergabe der Mozilla Foundation loswerden.

Die Features der drei kommenden Versionen konzentrieren sich fast ausschließlich auf Komfort und die weitere Vereinheitlichung der Benutzeroberfläche. Natürlich sind dies bei einem Browser sehr wichtige Faktoren, aber meiner Meinung nach, hat Firefox viel größere Defizite, die Angriff genommen werden sollten.

Projekt Electrolysis

Wie der Name schon sagt, geht es um die Trennung des Ganzen in seine Bestandteile. Auf Firefox bezogen, soll das Projekt Electrolysis auf eine Aufspaltung des großen Firefox-Prozesses in mehrere Prozesse ermöglichen. Google setzt eine solche Architektur von Anfang an in Chrome ein. Es gibt einen Hauptprozess und für jeden geöffneten Tab einen weiteren Prozess. Desweiteren wird jedes Plug-In sowie jede Extension in je einen weiteren Prozess ausgelagert. Damit erreicht Google einen stabilen, effizienten Browser, der den Arbeitsspeicher nicht unnötig belastet und selbst bei einem Absturz eines Tabs, Plug-Ins etc.  immer noch weiterlaufen kann. Apple und Microsoft fanden diese Idee so gut, dass Safari 5 und der Internet Explorer 9 ein ähnliches Prozess-Modell verwenden.

Mozilla wollte ebenfalls auf den Zug aufspringen und hat daher das Projekt Electrolysis ins Leben gerufen. Als ersten Schritt wurde die Ausgliederung von Plug-In-Prozessen in Angriff genommen, die mit Firefox 3.6.4 vor knapp 18 Monaten ihren Weg in die offiziellen Releases fand.

Schritt 2 war die Teilung in den Hauptprozess und Einzelprozesse für die offenen Tabs. Da Mozilla offensichtlich keine Veranlassung sah, dass dieses Feature möglichst schnell in die Desktop-Version Einzug hält, wurde es zuerst in Fennec, die mobile Version von Firefox, implementiert —  durchaus sinnvoll, um mit den begrenzten Ressourcen effizient umzugehen. Seit März vergangenen Jahres ist Fennec im Android Market erhältlich. Viel getan hat sich seit dem nichts mehr. Die Projekt-Seite im Mozilla Wiki wurde zuletzt im April 2011 aktualisiert und auch an anderer Stelle finden sich kaum Hinweise, wie es mit der Entwicklung von Electrolysis weitergeht.

In Anbetracht des hohen Speicherbedarfs von Firefox, insbesondere wenn Extensions im Spiel sind, finde ich es sehr schade, dass sich hier nicht mehr tut oder der Fortschritt nur sehr mangelhaft kommuniziert wird. Firefox würde enorm von der Prozess-Aufteilung profitieren, sei es in Sachen RAM-Verbrauch, als auch Stabilität und Geschwindigkeit.

JavaScript

Sicherlich kann man der Mozilla Foundation zu Gute halten, dass sich die JavaScript-Leistung seit dem Release von Firefox 4 und 9 signifikant verbessert hat, dennoch besteht nach wie vor großer Aufholbedarf gegenüber Chrome. Mit IonMonkey ist ein neuer JIT in Arbeit, der das bestehende Konstrukt aus JägerMonkey bzw. TraceMonkey ablösen soll. Wie die Entwickler zugegeben haben, ist die aktuelle Architektur nur sehr schwer zu optimieren und daher wird IonMonkey zum Großteil komplett neu geschrieben.

Diese Bestrebung ist sehr löblich und wird sicher auch Früchte tragen, aber sie kommt reichlich spät und wird zu dem auch viel Zeit in Anspruch nehmen. Wir können froh sein, wenn IonMonkey am Jahresende seinen Weg in die offiziellen Releases findet. Aber die Konkurrenz schläft nicht und Google hat schon ein paar mal bewiesen, dass sich massiv an der Performance-Schraube ihres eigenen JITs, V8, drehen können. Verbesserungen von 10 – 30% mit einem Release waren keine Seltenheit. Microsoft, Opera und Apple werden ebenfalls daran arbeiten die JavaScript-Leistung ihrer Browser deutlich zu verbessern.

Firefox läuft hier Gefahr ins Hintertreffen zu geraten und daher sollten die Bestrebungen für IonMonkey unbedingt verstärkt werden. JavaScript ist heute unverzichtbarer Bestandteil der meisten Websites und Rich Internet Applications werden zunehmend wichtiger, insbesondere da Microsoft endlich eingesehen hat, dass der Internet Explorer technisch weiterkommen muss.

Profile

Wenn Firefox sich seltsam verhält, oft abstürzt oder sich anderweitig unangenehm bemerkbar macht, wundern sich viele, dass eine Neuinstallation nichts bringt. Die Universalwaffe gegen Windows-Probleme versagt hier kläglich, weil die Nutzerdaten, Einstellungen und Extensions als separates Profil in den Anwendungsdaten bzw. im Home-Verzeichnis gespeichert werden und dort auch bleiben, wenn man den Browser deinstalliert. Wird Firefox neu installiert, greift er auf dasselbe Profil wie die vorherige Installation zu und hat daher auch die gleichen Probleme.

Probleme mit den Profilen ziehen sich leider immer wieder quer durch die gesamte Geschichte von Firefox und gab es auch schon vorher in der Mozilla Suite — heute besser bekannt als SeaMonkey. Warum das so ist, ist bisher nicht klar geworden. Im Verlauf der Firefox-Entwicklung hat Mozilla in den Profilen einiges verändert.

Vieles, was früher in simplen Text-Dateien gespeichert wurde, befindet sich heute in SQLite-Datenbanken. Damit konnte man z.B. Dinge wie die AwesomeBar, die intelligente Adressleiste, realisieren. Leider ergaben sich hierbei aber neue Probleme. Insbesondere die Browsing History wird sehr ausgedehnt gespeichert, damit aber sehr groß und mit der Zeit auch immer langsamer. Wer keine SSD sein Eigen nennt, kennt die teils langen Startzeiten von Firefox, die unmittelbar damit zusammenhängen. Selbst wenn das Fenster inzwischen geöffnet wurde und man etwas in die Adresszeile eingibt, kann es teilweise mehrere Sekunden dauern, bis überhaupt eine Reaktion erfolgt.

Selbst neue, frische Profile sind manchmal kein Garant dafür, dass Firefox rund läuft. Erst letztens gab es in meinem Freundeskreis den Fall, dass der Browser mit einem ein paar Wochen alten Profil plötzlich regelmäßige Aussetzer hatte und nicht mehr reagierte. Erst ein ganz neues Profil beseitigte dieses Problem.

All dies ist nur ein kleiner Teil mir bekannter Profilprobleme. Mozilla sollte daher schleunigst etwas dagegen unternehmen.

Fazit

Wie man unzweifelhaft sieht, hat Firefox viele technische Macken bishin zu wirklich großen Handicaps. Vielen Nutzern mag dies aktuell noch egal sein, weil sie nicht betroffen sind oder es ihnen egal ist, wie schnell ihr Browser ist. Derzeit ist auch der Erfolg von Chrome kein Anzeichen dafür, dass Firefox auf einem absteigenden Ast wäre. Der steigende Anteil von Chrome geht zum Großteil zu Lasten des Internet Explorers. Trotzdem sehe ich die Mozilla Foundation in der Pflicht endlich angemessen auf og. Problematiken zu reagieren.

Wie bereits erwähnt, schläft die Konkurrenz nicht. Google hat mit Chrome eindrucksvoll gezeigt, wie man einen modernen, schlanken Browser entwickelt. Mozilla tut sich offenbar schwer, Firefox und Gecko entsprechend umzustellen, was für mich als Programmierer bedeutet, dass dort noch viele Altlasten mitgeschleppt werden (müssen). Daher wäre es wohl an der Zeit, einen Strich zu ziehen und vieles komplett neu anzugehen, wie es z.B. schon bei IonMonkey getan wird. Mit einem modernen Aufbau der Interna wäre Firefox zukunftssicher und Mozilla würde sich in der Weiterentwicklung sehr viel leichter tun.

Nach etwas über einem halben Jahr wird es wieder einmal Zeit, den JavaScript Engines der aktuellen Browser-Versionen auf den Zahn zu fühlen. Die Versionssprünge im Vergleich zu den letzten Benchmarks sind beachtlich. Firefox ging von Version 3 (4 war noch Beta) auf 7, Chrome von 10 auf 15. Microsoft machte da einen vergleichsweise kleinen Schritt von 8 auf 9, während Apple und Opera bei ihren Hauptversionen 5 und 11 treu geblieben sind.

Wie üblich dient als Testplattform mein Privatrechner mit folgender Spezifikation: Intel Core i5 750, 8 GB RAM, Intel X25 G2 80 GB und Windows 7 Professional x64 SP 1.

Hier sind die Ergebnisse:

 

Es gibt auch dieses mal keinen klaren Gewinner, der sich alle drei Siege sichern konnte, aber Chrome 15 ist im Schnitt wieder die Nummer 1. Der Internet Explorer 9 mag zwar unter SunSpider der schnellste Kandidat sein, er verliert jedoch die anderen zwei Tests klar. Es liegt daher die Vermutung nahe, dass Microsoft hier einige Optimierungen vorgenommen hat — zumal sich an SunSpider schon länger nichts mehr getan hat.

Wie man schön sehen kann, hat Apple im letzten halben Jahr wirklich Fortschritte mit der Nitro Engine gemacht. Safari hat sich von der roten Laterne ins Mittelfeld vorgekämpft und überholt nun Firefox in gleich zwei Disziplinen. Es bleibt abzuwarten, ob Apple den Vorsprung halten kann. Ab Firefox 9 wird Mozillas JIT JägerMonkey durch Type Inference bis zu 30% mehr Leistung bringen. Dazu befindet sich mit IonMonkey ein neuer JIT in Arbeit, der wahrscheinlich JägerMonkey und evtl. auch TraceMonkey ersetzen wird. IonMonkey wird eine andere, moderne Architektur besitzen und damit die Wartbarkeit als auch Optimierungsmöglichkeiten für die Entwickler deutlich verbessern.

Bleibt noch Opera 11, der sich mal wieder sehr gut schlägt und die klare Nummer Zwei im Starterfeld ist.

Fazit

Chrome gewinnt — wie immer. Opera ist Zweiter und im weiteren Feld kämpft sich Safari an Firefox und Microsofts Internet Explorer vorbei.

Ich bin gespannt, ob Microsoft mit dem Internet Explorer 10 wieder aufholen kann. Vielleicht sollte man in Redmond auch die Release-Zyklen überdenken. Alle anderen Hersteller können wesentlich schneller reagieren und optimieren, während Microsoft nur jährlich neue Major Releases bringen will. Wobei ich es für fraglich halte, ob wirklich jedes Jahr eine neue Version kommen wird.

Natürlich haben theoretische Benchmarks in der Praxis weit weniger Relevanz. Meine aktuellen Experimente mit ExtJS zeigen sehr deutlich, dass bei Rich Internet Applications Firefox immer noch kein sonderlich gutes Bild abgibt. Das aufgebaute UI, das für eine RIA eh noch recht spartanisch ausgestattet ist, läuft in allen anderen Browsern wesentlich weniger träge und ruckelig. Gleiches lässt sich auf diverse andere JavaScript-lastige Seiten übertragen, z.B. GMail oder iCloud.

JägerMonkey mit Type Inference, IonMonkey und die lang erwartete Integration des Electrolysis-Projekts sind darum wichtiger denn je.

In den letzten Monaten tat sich viel in der Browser-Landschaft: Mitte Dezember kam Opera 11. Google bringt fast schon im Monatstakt neue Chrome-Versionen — erst gestern Version 10. Wie Microsoft heute mitteilte, kommt der finale Internet Explorer 9 am 14. März und Firefox 4 wird auch nicht mehr lange auf sich warten lassen. Es wird wieder Zeit, sich einen Überblick in Sachen JavaScript-Leistung zu verschaffen. Inbesondere Google und Opera treiben hier die Entwicklung stark voran, während Mozilla und Microsoft versuchen endlich aufzuschließen.

Als Testplattform diente ein Intel Core i5 750 mit 8 GB RAM, einer Intel X25-M G2 80 GB und Windows 7 Professional x64 SP1.

Hier die Ergebnisse als Diagramme:

Aufgrund der Charakteristik und Optimierungen der einzelnen Benchmarks, gibt es keinen klaren Sieger. Am neutralsten — obwohl er dem WebKit-Projekt entstammt — erscheint mir SunSpider. Es ist dabei fast schon ironisch, dass die eigene Engine “Nitro” am schlechsten abschneidet.

Im Vergleich zu den anderen Ergebnissen, sind die Einzelwerte aber recht nahe beisammen. Verwunderlich ist nur, dass der Internet Explorer 9 selbst Chrome und Opera leicht abhängt. Hier wurde ja desöfteren schon eine SunSpider-Optimierung der Engine seitens Microsoft vermutet. Belegen lässt sich das allerdings nicht. Klar ist aber, dass die JavaScript-Leistung gegenüber den Vorgängern deutlich zugenommen hat.

Bei den V8-Benchmarks ist klar ersichtlich, dass er für Chrome optimiert wurde, während der Rest des Feldes grob auf einem Niveau zu sein scheint. Ähnlich drastisch scheint Kraken auf die Tracer-Technik von TraceMonkey bzw. JägerMonkey (Mozilla) ausgerichtet zu sein. Die Tracing-Technik dominierte oft Tests, wenn sie aufgrund des Programmierung des Scripts richtig arbeiten kann. In der Praxis ist das ist leider selten der Fall, daher kam meist der herkömliche JIT in Mozillas SpiderMonkey Engine zum Einsatz. Ab Firefox 4 steht ein neuer JIT namens JaegerMonkey zur Verfügung, der zum Teil auf WebKits Nitro basiert und deutliche Vorteile gegenüber dem alten System hat.

Fazit

Ingesamt überzeugt Chrome 10 bzw. V8 mit der besten Gesamtleistung im Starterfeld. Opera 11, Firefox 4 und der Internet Explorer 9 teilen sich das Mittelfeld, wobei Opera 11 die Gruppe klar anführt und der IE 9 das Rücklicht hält. Safari 5 schneidet in zwei von drei Tests als Letzter und im dritten als Vorletzter ab. Hier sollten Apple die und anderen Initiatoren des WebKit-Projekts demnächst nachlegen, sonst wird der einstmalige ICE schnell zum Regionalzug.

Wie bei solchen Benchmarks üblich, handelt es sich hierbei natürlich in erster Linie um theoretische Ergebnisse. Praktisch betrachtet, also beim normalen Surfen, sind die Unterschiede der Testkandidaten bei weitem nicht so drastisch. Heftige Ausreißer wie noch zwischen Firefox 3.6 oder dem IE 8 und aktuellen Chrome-Versionen entfallen fast vollständig. Mozillas und Microsofts Anstrengungen wieder Anschluss zu finden, sind also geglückt.

Die Katze ist nun seit ein paar Tagen aus dem Sack und ich kann das dauernde Lamentieren über Datenschutz und Spionage nicht mehr hören. Bei einem Open Source-Projekt ist so eine Diskussion überflüssig. Jeder kann sich den Quelltext herunterladen und prüfen. Google Suggest in der Adressleiste lässt sich abschalten und die Browser-ID ebenso umgehen – letztere nutzt übrigens auch Mozilla Firefox beim Auto-Update …

Leider geht die technische Seite in diesem Theater etwas unter. Dabei ist gerade das doch die Stärke von Chrome. Eine virtuelle Maschine (im Sinne einer Java-VM) für Javascript, die dazu keinen Bytecode, sondern gleich x86-Code generiert, hat massive Geschwindigkeitsvorteile und ist durch Einkapselung auch noch sicherer. Zumindest solange keine schwerwiegenden Fehler auftreten, die es erlauben ins eigentliche Betriebssystem einzudringen.

Letztendlich wird es aber zur Philosophiefrage werden, ob man nun einen normalen Interpreter oder eine kompilierende VM benutzt. Als reiner Interpreter wird Tracemonkey in Firefox 3.1 wohl gleich auf liegen. Allerdings sind Tracemonkey, Squirrelfisch und V8 noch neu, so ist sicher noch viel Luft nach oben.

Dass die Wahl der Render Engine dagegen auf Webkit fiel, ist schon etwas verwunderlich. Schließlich ist Google der Hauptgeldgeber der Mozilla Foundation und es bleibt die Frage: warum nicht Gecko? Als Grund wurden die guten Erfahrungen mit Webkit während der Entwicklung von Android und geringer Ressourcenhunger angeführt.

Soweit so richtig, aber ich glaube eher, dass Mozilla nicht dem Tempo folgen kann, welches Google vorschwebt und man sich daher gegen Gecko entschiedt. Neue Firefox- und Thunderbird-Versionen verzögern sich meist gewaltig. Bei den anderen Projekten wie z.B. Sunbird, sieht es auch nicht besser aus.

Chrome soll offensichtlich ein schneller Schlag gegen Microsoft bzw. den Internet Explorer werden. Aus meiner Sicht als beruflicher Web-Entwickler, kann ich das nur befürworten. Die Jungs aus den Redmond müssen endlich ganz aus ihrem Dornröschenschlaf aufwachen. Zwar hat sie Firefox geweckt, aber noch taumeln sie schlaftrunken durch die Gegend.

Nach fünf Jahren absolutem Stillstand (2001 – 2006) und auch dem IE 7, muss endlich mehr passieren. Version 8 ist ein richtiger Schritt, aber Microsoft hat sicher mehr Möglichkeiten, als mehr schlecht als recht mit Gecko, Presto und Webkit gleichziehen zu können. Wir mussten und müssen uns in der Branche immer noch mit den Hinterlassenschaften dieser technischen Stagnation rumschlagen. Das kann und darf so nicht mehr weitergehen.

Darum wünsche ich Google viel Erfolg, auch wenn ich vorerst bei Firefox bleiben werde. Es gibt einfach zu viele Extensions, die inzwischen unverzichtbar geworden sind – zumindest für uns Entwickler.

Mozilla.org nahm sich viel Zeit für Firefox 3, aber das Warten hat sich gelohnt. Dem Gecko-Build nach, scheint unter Windows der Release Candidate 2 die finale Version zu sein. Momentan ist er noch nicht offiziell erhältlich, aber wie üblich befindet sich eine neue Version schon Stunden vorher auf dem Mozilla-FTP-Server.

Mehr über die Neuerungen in Firefox 3, findet Ihr hier.

Und im Gegensatz zum Release von Firefox 2, haben viele Entwickler die Beta- und RC-Phase genutzt und ihre Extensions angepasst.