Googles Browserengine Blink startet mit Chrome 28

Googles gerade erst angekündigte Browserengine Blink wird mit Chrome 28 starten. Das teilt Chrome-Programmierer Mike West in einem Kommentar auf Hacker News mit. Wörtlich heißt es dort: „Chrome 28 wird der erste blinkende Release sein.“ Derzeit ist Chrome 26 die aktuelle stabile Version; Updates erscheinen ungefähr alle sechs Wochen.

Dass es sich nicht um ein langfristiges Projekt handelt, sondern um direkt anstehende Änderungen, zeigt auch eine Nachricht von Eric Seidel, einem der führenden Blink-Entwickler. Er schreibt an die Gruppe Blink-dev: „Das Repository scheint größtenteils zu laufen, und die ersten Commits gehen ein. Unser Fokus ist es in dieser ersten Woche, dass jeder glatt in den Prozess einbezogen wird.“

Google hat seine neue Browser-Engine Blink nach dem gleichnamigen HTML-Tag benannt (Bild: News.com).

Zu den wichtigsten Veränderungen gegenüber WebKit wird ein massiver Frühjahrsputz gehören – um bis zu 4,5 Millionen Zeilen ungenutzten Code, wie Chrome-Programmierer Adam Barth schreibt. Seidel zum gleichen Thema: „Wir haben auch eine große Menge toten Code, der entfernt werden soll, wenn die Bots so weit sind, versehentliche Bruchstellen zu erkennen.“

Chrome und sein quelloffener Ableger Chromium konnten durch Einsatz der Browserengine WebKit einst ihren Start beschleunigen. Die Entwicklung von WebKit hatte ursprünglich mit der Engine KHTML innerhalb von KDE begonnen und ist auch Grundlage für Apples Safari. Jetzt sieht Google offenbar eine gute Gelegenheit, eigene Wege zu gehen und durch einen Fork von WebKit – eben Blink – tiefgreifende Änderungen vorzunehmen, die ihm bisher nicht möglich waren.

Eric Seidel hat WebKit in einer Abschiedsnachricht Respekt gezollt: „Ich schreibe, um mich zu bedanken – persönlich und im Namen des Chromium-Projekts. Chromium wäre ohne WebKit und seine Programmierer undenkbar.“

Einige Entwickler merken aber auch an, dass Blink nur offiziell eine Trennung vollzieht, die längst Tatsache ist. „Chrome, Safari und andere WebKit-Ports gehen seit Jahren auseinander, auch wenn sie weiter unter einem Dach wohnten“, schreibt Chrome-Programmierer Alex Russell. „Das war möglich, indem durchgängig Build-Flags eingesetzt wurden, die Ports unterschiedliche Feature-Implementierungen ermöglichten.“

Ein solches divergierendes Projekt war WebKit2, das Apple 2010 startete. Es implementierte wie Chrome Browser-Aufgaben als separate Prozesse, verwendete aber einen anderen Ansatz als der Google-Browser. Apple-Entwickler Maciej Stachowiak merkt jetzt dazu an: „Die Multiprozess-Architektur von Chrome ist reifer als das Webkit2-Konzept. Ich wünschte, wir wären nicht in die Lage gekommen, selbst so etwas entwickeln zu müssen. Aber wartet ab – wir bereiten gerade Großartiges vor.“

In einem späteren Beitrag gab er Google explizit die Schuld an der Zersplitterung: „Der Hauptgrund, dass wir eine neue Multiprozess-Architektur entwickelt haben, ist der, dass Chromiums Multiprozess-Lösung nie Eingang in WebKit fand. Der Code war immer nur Teil der abgetrennten Chromium-Entwicklung, was eine Nutzung außerhalb von Chrome sehr schwer machte.“ Auf eine direkte Anfrage hin – „bevor die erste Zeile von WebKit2 geschrieben wurde“ – habe Google es abgelehnt, seinen Multiprozess-Code in WebKit einzubringen.

Dieser Darstellung widerspricht Chrome-Programmierer Justin Schuh: „Ich verstehe diese Behauptung nicht. WebKit2 wurde ohne Vorwarnung und ohne irgendeinen Versuch der Zusammenarbeit konzipiert. Ich habe mehrere Ansätze registriert, WebKit2 als gemeinsame Architektur zu gestalten, aber es kam nichts zurück.“

Während die Aufarbeitung noch andauert, ist die Aufspaltung zum Fakt geworden. Schon im Januar fanden sich unter 18 Mitgliedern der WebKit2-Entwicklerriege 16, die zu Apple gehören. Einer ist für Nokia tätig, und der letzte arbeitet sowohl für Apple als auch Nokia.

[mit Material von Stephen Shankland, News.com]

Tipp: Wie gut kennen Sie sich mit Browsern aus? Testen Sie Ihr Wissen – mit dem Quiz auf silicon.de.