Warum das Web Google Chrome braucht

Seit zwei Tagen ist Google mit einem eigenen Browser am Markt, der wie kaum ein anderes Produkt polarisiert.
Während die einen einen neuen Browserkrieg am Horizont ausmachen, ächzen andere über die vermeintliche Fragmentierung des Netzes.
Doch Chrome kommt gerade recht: Lesen Sie, warum bald jeder Surfer von Chrome profitieren wird, selbst wenn er den Google-Browser nicht einsetzt.

  • Gebt den Entwicklern etwas zu spielen!

    Als vor fast zehn Jahren Netscape die Freigabe des Quellcodes beschloss, die Entwicklergemeinde Netscape 5 aber wegen seinen Altlasten zurückwies und stattdessen mit Gecko die komplette Neuimplementierung des Browsers begann, war der Grundstein für ein sehr innovatives Projekt gelegt. Viele der in den folgenden Jahren ausprobierten Konzepte waren nur dank der kleinen, aber aktiven Anwenderschaft möglich. Aus der Distanz betrachtet war der verlorene Browserkrieg ein Glücksfall für die Internetgemeinde. Heute ist Mozilla ein großes Projekt mit Millionen von Anwendern. Radikale Änderungen an der Nutzerführung oder dem internen Aufbau würden mit gewohnten Mustern brechen. Mit Chrome existiert wieder ein kleines, aber mit vielen Programmiereressourcen ausgestattetes Projekt, in dem neue Konzepte ausprobiert werden können ohne Nutzer zu verschrecken. Bewähren sich diese, werden sie ihren Weg in andere Browser finden.

  • JavaScript mit V8 nutzt Programmierern und Anwendern

    Ein großes Problem aktueller Browser ist die JavaScript-Implementierung. Die Sprache war mit ihrer halben Objektorientierung eigentlich nur dazu gedacht, lokale aktive Inhalte zu platzieren, wo man mit HTML und CSS nicht beikam. Vor einigen Jahren kam dann mit AJAX die Möglichkeit auf, Inhalte dynamisch nachzuladen. Exzessiv eingesetzt lassen sich mit JavaScript und AJAX ganze Anwendungen erstellen, die viele JS-Interpreter an den Rand der Leistungsfähigkeit bringen. Die von Google in Auftrag gegebene virtuelle Maschine V8 soll JavaScript im Hintergrund mit Klassen ausstatten und Zwischencode generieren, der wiederverwendbar ist. Die Idee dahinter ist gut und vielleicht folgen daraus Vorschläge für die Erweiterung künftiger ECMA-Script-Versionen um eine echte Objektorientierung. Und möglicherweise gibt V8 anderen Browsern Impulse, eine virtuelle Maschine wie Parrot oder die .Net-Runtime für ECMA-Script zu erweitern und so das Konzept zu übernehmen. Eigentlich ist das aber nicht nötig: V8 soll unter eine BSD-Lizenz gestellt werden, mit derart lizenziertem Code hat nicht einmal Microsoft Probleme.

  • Der Browser wird als Anwendungsplattform wahrgenommen

    In den Köpfen vieler Surfer ist der Browser ein Programm zur Anzeige von Webseiten. Tatsächlich ist er viel mehr, nämlich eine Plattform um Anwendungen auszuführen, die zufällig übers Internet geladen und aktualisiert werden. Chrome macht dies bewußt, dafür sorgen Aktionen wie Möglichkeit, einen Tab per Drag&Drop auf den Desktop zu ziehen oder AJAX-Anwendungen ganz ohne Titelleiste zu starten. Das regt auch Entwickler zum Nachdenken an: Wäre es nicht sinnvoll, wenn der Ersteller einer Seite dem Browser sagen könnte, dass er (beim herausgelösten) Start keine Titel- und Navigationsleiste braucht? Mozilla verfügt mit Prism über ein ähnlich gelagertes Projekt, das allerdings derzeit nicht den nötigen Fokus der Entwickler bekommt.

  • HTML 5 wird vorangetrieben

    HTML 4 und das daraus abgeleitete XHTML 1 tragen noch viele Altlasten der frühen 1990er in sich. Beide sind auf einfaches Parsen optimiert, auf der Strecke bleibt vor allem die Semantik des Webs. HTML 5 verspricht die Erweiterung um zusätzliche semantische Elemente, insbesondere in der Struktur eines Dokumentes. Das kommt natürlich Suchmaschinenherstellern besonders zu Gute, die das Abstract eines Textes stärker gewichten können als den folgenden Fließtext. Den Surfer dürfte an HTML 5 eher interessieren, dass zusätzliche Lese- und Navigationshilfen möglich sind. So kann ein Browser, der ein langes HTML 5 Dokument anzeigt, auf Basis der Kapitelschachtelung einen Navigationsbaum aufbauen wie er in vielen PDF-Dokumenten integriert ist. Daneben bietet HTML 5 die vereinfachte Einbindung multimedialer Inhalte und zollt mit einer Programmierschnittstelle für die lokale Datenspeicherung der Wahrnehmung von Webseiten als Anwendungen Respekt. Mit Google als Schwergewicht dürfte die weitere Spezifikation von HTML 5 neuen Schwung bekommen. Vielleicht nicht mit allen tollen Vorschlägen, aber besser bald HTML 5 und wenig später mit HTML 5.1 eine Erweiterung als ein Spezifikationsprozess, der sich noch Jahre hinzieht.

  • Mikroformate rücken ins Licht der Öffentlichkeit

    Tim Barners Lee hat das semantische Web bereits zum Web 3.0 erklärt: Webseiten müssen maschinenlesbar sein und die Kommunikation zwischen Diensten unterstützen. Was eigentlich massive Änderungen an bestehenden Konzepten erfordert (die auch mit HTML 5 nicht vollständig eingeführt sind), hat eine kleine Gruppe von Entwicklern auf Basis von HTML 4 ausgeheckt: Die Sematik wird hierbei völlig RFC-konform über Klassennamen eingebracht. Die Microformats genannte Erweiterung wird vor allem für Adressen, Termine und geographische Koordinaten eingesetzt — auf tausenden von Webseiten. Bislang braucht es Browsererweiterungen, um eine Adresse anzuklicken und die dahintersteckende Visitenkarte ins Adressbuch zu übernehmen oder das gleiche mit dem Termin des Konzerts der Lieblingsband zu machen. Google hat Mikroformate bis vor kurzem stiefmütterlich behandelt, importiert und exportiert sie aber heute. Eine gute Unterstützung für Mikroformate könnte den Komfort gerade im Umgang mit Web-Applikationen deutlich verbessern.

  • SVG, was war das doch gleich?

    Das XML-Format “Scalable Vector Graphics” ist als Austauchsformat für — richtig geraten — Vektorgrafiken außerhalb des Webs längst Usus. Eingebettet in Webseiten ermöglicht es jedoch nicht nur die Anzeige beliebig skalierbarer Grafiken, sondern auch die Manipulation mit den bekannten DOM-Operationen: Grafiken interaktiv, maschinengeneriert, skalierbar, durch Suchmaschinen indexierbar, ohne Plugin. Die Unterstützung durch Browser ist derzeit etwas dürftig: Firefox kanns solala, IE gar nicht und Safari ganz gut. Mit Chrome kommt ein weiterer Browser dazu, der SVG ganz gut können wird. Auch mit diesem Feature wird Microsoft daran erinnert, was alles fehlt. Und Google Maps ist beileibe nicht die einzige Seite, die SVG nutzt. Bald könnten es mehr werden.

Insbesondere die Angst vor einem neuen Browserkrieg ist unberechtigt. Im Gegenteil: Google möchte keinesfalls einen Großteil der Websurfer ausschließen, sondern möchte mittelfristig die — in den Augen Google’s — sinnvollen Features in allen Browsern vorfinden. Dazu benutzt Google das Prinzip “Zuckerbrot und Peitsche”. Die Peitsche ist ein sauberes Konzept, die schnelle VM für ECMA-Script und die präsente Drohung “Wenn wir noch ein paar Millionen reinbuttern, braucht Euch keiner mehr.” Das Zuckerbrot ist die angekündigte Lizenzierung vieler Komponenten unter einer BSD- oder MIT-Lizenz (Webkit steht nach wie vor unter LGPL). Dabei steht für Google nicht die Dominanz auf dem Browsermarkt an erster Stelle: Es geht darum, sicherzustellen, dass 100% aller Browser gut mit Googles Anwendungen können — notfalls wird nachgeholfen. Für Webentwickler bedeutet das die Chance, jetzt auf den Zug aufzuspringen und ganz vorne dabei zu sein, wenn sich neue Konzepte durchsetzen. Es kann ja nicht angehen, dass alleine Google vom Fortschritt profitiert — tatsächlich gewinnen besonders Anwendungen und Geschäftsmodelle, die auf pfiffige Kombinationen der neuen Features setzen, aber ersteinmal zu klein erscheinen um auf dem Radar des Großen aufzutauchen.

Alles eitel Sonnenschein? Nicht ganz: Ich werde in den nächsten Tagen darauf eingehen, warum normale User sich mit dem Einsatz von Chrome noch zurückhalten sollten. Entwickler sollten aber zuschlagen und austesten, wo die Grenzen von Chrome liegen und welche Möglichkeiten der Browser für künftige Webanwendungen bereithält: Ihr könnt sicher sein, dass die etablierten bald nachziehen.

Zum Thema