Früh in meiner Karriere, als ich in Agenturen und später bei Microsoft an Edge arbeitete, hörte ich immer wieder dieselbe Klage: „Argh, warum läuft Edge nicht einfach auf Blink? Dann hätte ich Zugriff auf ALLE APIs, die ich nutzen möchte, und müsste nur in einem Browser testen!“
Ich möchte klarstellen: Ein Internet, das nur auf der Engine von Chrome, Blink, und deren Nachkommen läuft, ist nicht das Paradies, das wir uns gerne vorstellen.
Als Google Developer Expert, der an Microsoft Edge, mit Firefox und dem W3C als eingeladener Experte gearbeitet hat, habe ich einige Meinungen (und eine Reihe von Fakten), die ich zu diesem Thema loswerden möchte. Legen wir los.
Was ist ein Browser überhaupt?
Lassen Sie uns einige Begriffe klären.
Zu den beliebten Browsern, die Sie heute kennen, gehören Google Chrome, Apple Safari, Mozilla Firefox und Microsoft Edge, aber in der Vergangenheit hatten wir auch Größen wie NCSA Mosaic und Netscape Navigator. Welchen Browser Sie auch täglich nutzen (ich nutze Firefox, danke der Nachfrage), ist nur eine Schnittstellenschicht, die um eine Browser-Engine gewickelt ist. All Ihre Lesezeichen, die Vor- und Zurück-Pfeile, dieses URL-Leisten-Ding – das *ist nicht der Browser.* Das ist die Benutzeroberfläche des Browsers. Oft berühren die Leute, die die Engine des Browsers entwickeln, nie die Benutzeroberfläche!
Browser-Engines sind die Dinge, die tatsächlich das gesamte HTML, CSS und JavaScript lesen, das über das Internet heruntergeladen wird, es interpretieren und Ihnen ein hübsches Bild einer Webseite anzeigen. Sie haben eigene Namen. Die Engine von Chrome heißt Blink. Safari läuft auf WebKit. Firefox nutzt Gecko. Edge sitzt auf EdgeHTML. (Ich mag diese Namenskonvention. Gut gemacht, Edge.)
Bis auf Edge sind all diese Engines Open Source, was bedeutet, dass jeder eine nehmen, in eine neue Benutzeroberfläche einpacken und zack, seinen eigenen Browser veröffentlichen könnte – vielleicht mit einer anderen (vielleicht besseren) Benutzererfahrung – und das ist genau das, was einige Browser sind! Apple erlaubt nur WebKit-basierte Browser in seinem iOS App Store, daher funktionieren die Chrome-, Firefox- und sogar Edge-Browser auf iPads und iPhones eher wie Safari als ihre Desktop-Pendants. Oculus Browser, Brave, Vivaldi, Samsung Internet, Amazons Silk und Opera laufen alle auf Blink. Wir nennen sie „Chromium-basierte Browser“ – Chromium ist Googles Open-Source-Projekt, aus dem Chrome und seine Engine hervorgegangen sind.
Aber was steckt in einer Browser-Engine? MEHR ENGINES! Jede Browser-Engine besteht aus mehreren anderen Engines
- Eine Layout- und Rendering-Engine (oft so eng gekoppelt, dass es keine Unterscheidung gibt), die berechnet, wie die Seite aussehen soll, und alle Paints, Renderings und sogar Animationen verarbeitet.
- Eine JavaScript-Engine, die eine eigene Entität ist und sogar unabhängig vom Browser laufen kann. Zum Beispiel können Sie Googles V8-Engine oder Microsofts Edge Chakra verwenden, um Node auf einem Server auszuführen.

Ich vergleiche Browser-Engines gerne mit biologischen Zellen. So wie eine Zelle viele Organellen enthält, um verschiedene Funktionen auszuführen, so auch Browser. Man kann den Kern als Rendering-Engine betrachten, die die Baupläne für die Anzeige der Seite enthält, und die Mitochondrien als JavaScript-Engine, die unsere alltäglichen Interaktionen antreibt. (Fun Fact: Mitochondrien waren einst eigenständige Zellen und tragen sogar *ihre eigene DNA!*)
Und wissen Sie was? Eine weitere Gemeinsamkeit von Browsern mit Lebewesen ist, dass sie sich weiterentwickeln.
Browser-Evolution
Als die ersten Browser aufkamen, war es eine einfachere Zeit. CSS galt als die heiße Neuheit, als es 1996 erstmals in Microsoft Internet Explorer 3 erschien! Es gab weitaus weniger JavaScript-APIs und CSS-Spezifikationen zu implementieren als heute. Im Laufe der Jahre sind die Codebasen der Browser gewachsen, um die Anzahl neuer Funktionen zu unterstützen, die Benutzer und Entwickler für moderne Web-Erlebnisse benötigen. Es ist eine feine Evolution zwischen Benutzerbedürfnissen, Browser-Entwicklungsaufwand und Standardisierungsprozessen.
Wir haben derzeit drei Hauptlinien von Engines
- WebKit und Blink (Blink war ursprünglich ein Fork von WebKit), die Safari, Chrome und Opera antreiben
- Gecko, das Firefox antreibt
- EdgeHTML (ein Fork von Trident, auch MSHTML), das Microsoft Edge antreibt
Jede ist sehr unterschiedlich und hat unterschiedliche Stärken und Schwächen. Jede könnte das Web allein in eine andere Richtung ziehen: Die Engine von Firefox hat Servos Multithreading-Verarbeitung für blitzschnelle Grafiken. Die Engine von Edge hat die geringste Abstraktion vom Betriebssystem, was ihr mehr direkten Zugriff auf Systemressourcen ermöglicht – aber sie dadurch zu einer reinen Windows-Browser-Engine macht. Und Chromes Blink wird von den meisten Webentwicklern getestet. (Ich komme gleich darauf zurück, warum das ein „Feature“ ist.)
Erinnern Sie sich an all die Chromium-basierten Browser, über die wir gesprochen haben? Nun, keiner dieser Browser muss seine Rendering-Engine oder JavaScript-Engines von Grund auf neu entwickeln: Sie hängen einfach von Blink ab. Und wenn es neue Funktionen gibt, die sie benötigen? Sie können diese Funktionen entwickeln und für sich behalten, oder sie können diese Funktionen „upstream“ zurückgeben, um Teil der Kern-Engine zu werden, die andere Browser nutzen können. (Dieser Prozess ist oft voller Politik und Logistik – „zurückzugeben“ ist leichter gesagt als getan!)

Es ist schwer vorstellbar, dass irgendeine einzelne Entität heute die Stunden und Kosten aufbringen würde, um eine Browser-Engine von Grund auf neu zu entwickeln. Selbst die derzeitigen drei Engine-Familien sind Weiterentwicklungen von Engines, die von Anfang an im Internet vorhanden waren. Sie haben sich Stück für Stück neben uns entwickelt und sind gewachsen, um unsere Bedürfnisse zu erfüllen.
Derzeit findet die überwiegende Mehrheit des Web-Traffics auf Chrome, iOS Safari oder einer anderen Variante von Blink oder WebKit statt.
Forks, Renovierungen und Kernsanierungen
Manche Entwickler würden sagen, dass WebKit und Blink schon so lange geforkt sind, dass die beiden mittlerweile praktisch völlig unterschiedliche Browser-Engines sind und keine Beiträge mehr austauschen können. Das mag bis zu einem gewissen Grad stimmen. Aber während ein gemeiner Mauersegler und ein Kolibri im Vergleich zueinander völlig unterschiedliche Tiere sind, sind sie im Vergleich zu anderen Tierfamilien immer noch Vögel. Keines der unmittelbaren Nachkommen wird in absehbarer Zeit wahrscheinlich Zähne, Hände oder Schwänze entwickeln. Weder WebKit noch Blink verfügen über die Verarbeitungsfunktionen, die Gecko und EdgeHTML seit Jahren aufbauen.
Andere Entwickler könnten darauf hinweisen, dass Microsoft Edge angeblich eine „vollständige Neufassung“ von Internet Explorer ist. Aber der Unterschied zwischen einer „vollständigen Kernsanierung“ und einer bloßen „Renovierung“ kann eine Frage der Perspektive sein. EdgeHTML ist ein Fork von Internet Explorers Trident-Engine und trägt immer noch einen Großteil von Tridents Altlasten mit sich.
Browser-Aussterben
Das sind also die drei Browser-Engines, die wir haben: WebKit/Blink, Gecko und EdgeHTML. Wir werden in absehbarer Zeit wahrscheinlich keine brandneuen Blutlinien mehr bekommen. Das ist es.
Wenn wir eine dieser Browser-Engines verlieren, verlieren wir ihre Abstammung, jede Permutation dieser Engine, die folgen würde, und die einzigartigen Perspektiven auf das Web, die sie ermöglichen könnte.
Und sie wird wahrscheinlich nicht ersetzt werden.

Stellen Sie sich einen Planeten vor, der nur von Kolibris, Delfinen und Pferden bevölkert ist. Sagen wir, alle Delfine sterben aus. In ferner, ferner Zukunft könnten Kolibris oder Pferde sich zu etwas entwickeln, das wie ein Delfin im Ozean schwimmen könnte. Tatsächlich sahen Ichthyosaurier im Zeitalter der Dinosaurier Delfinen sehr ähnlich. Aber dieses Wesen wäre sehr anders als ein echter Delfin: Selbst Ichthyosaurier entwickelten keine Echoortung. Wir müssten sehr lange warten (möglicherweise für immer), bis sich eine Blutlinie entwickelt, die die Eigenschaften besitzt, die wir heute bereits in anderen Blutlinien vorfinden. Warum ist es also in Ordnung, dem Aussterben einer dieser wertvollen, einzigartigen Linien zuzusehen oder es sogar zu fördern?
Wir haben bereits eine verloren.
Wir hatten früher vier große Rendering-Engines, aber Opera hat die Entwicklung seiner eigenen Rendering-Engine Presto eingestellt, bevor es Blink übernahm.
Drei übrig. Gehen Sie klug damit um.
Durch unsere kombinierten Kräfte…
Manche Leute denken, dass, wenn ein Browser wie Microsoft Edge auf Blink laufen würde, die Ingenieure von Microsoft dazu beitragen könnten, ein besseres Blink zu bauen, und neue Features „upstream“ beitragen würden, von denen alle anderen Chromium-Browser profitieren könnten. Das klingt sinnvoll, oder?
Aber denken Sie daran, Blink wurde von WebKit geforkt. Jetzt gibt es WebKit-Beitragende und Blink-Beitragende, und ihre Beiträge lassen sich nicht eins zu eins übertragen. Es ist nicht unwahrscheinlich, dass ein Unternehmen wie Microsoft, ähnlich wie Samsung und Oculus, Dinge mit der Engine anders als Google machen möchte. Und wenn diese Unterschiede nicht übereinstimmen, wird das Unternehmen an einer parallelen Codebasis arbeiten und diese Arbeit nicht „upstream“ beitragen. Wir erhalten ein WebKit und ein Blink – aber ohne die tiefen Unterschiede, die aus einer Codebasis resultieren, die seit Jahrzehnten mit dem Internet wächst.
Das ist theoretisch eine schöne Idee. Aber in der Praxis landen wir in einem ähnlichen Dilemma – und mit weniger „genetischer Vielfalt“ in unserem Ökosystem von Browser-Engines.
Wettbewerb bedeutet Wachstum, nicht „Gewinnen“
Ich bin ein Fan von Wettbewerb. Der Wettbewerb mit anderen Comiczeichnern, um bessere Comics zu machen und ein größeres Publikum zu erreichen, hat mich dorthin gebracht, wo ich heute bin. (Wahre Geschichte: Ich habe meine Karriere mit dem Erstellen von Websites begonnen, als Cartoonistin, die ihre eigene Community-Seite, ihren Newsletter und ihren Warenkorb aufbaute.) Ich erinnere die Leute gerne daran, dass es beim Wettbewerb nicht darum geht, seine Konkurrenten zu vernichten. Wenn Sie das tun, stagnieren Sie und verlieren Ihr Publikum: siehe Internet Explorer 6.
Internet Explorer 6 war ein erstaunlicher Browser, als er herauskam: leistungsfähig genug, um wirklich die Funktionen zu liefern, die frühere Versionen von Internet Explorer wie das DOM, Data-Binding und asynchrones JavaScript eingeführt hatten. Sein Rivale, Netscape Navigator, konnte nicht mithalten und zerfiel zu Staub (nur damit seine Engine, Gecko, von der Mozilla Foundation von Grund auf neu geschrieben wurde, um später als Firefox wiedergeboren zu werden).
Im Glauben, das Internet „gewonnen“ zu haben, wandte sich Microsoft anderen Fronten zu, und Internet Explorer entwickelte sich kaum weiter. Das gab Firefox die Möglichkeit, Fuß zu fassen – indem es Benutzern eine bessere Erfahrung mit Funktionen wie Pop-up-Blockern und einer besseren Benutzeroberfläche bot. (Diese Schnittstellenschicht ist wirklich wichtig!) Firefox arbeitete auch mit Opera zusammen, um Web-Standards voranzubringen, die in den Tagen des IE vs. Netscape noch keine große Sache waren. Leute, die das Internet nutzten und dafür entwickelten, liebten es, und Firefox verbreitete sich wie ein Lauffeuer (</dad-joke>) durch Mundpropaganda und Graswurzel-Werbekampagnen.
Als das iPhone kam, konzentrierte sich Apple auf seinen profitablen App-Marktplatz und reduzierte die Unterstützung für Flash – die app-ähnlichste Interaktionsplattform des Webs. Apps gaben Content Creators eine Möglichkeit, ihre Bemühungen mit etwas anderem als einem Werbemodell zu monetarisieren. Da Werbung Googles Brot und Butter ist, wurde die Big G besorgt, als die Bedrohung eines geschlossenen App-Gartens, der das Internet nur für die Dateninfrastruktur nutzte, aufkam. Microsoft war in der Zwischenzeit mit dem Aufbau seines eigenen mobilen Betriebssystems beschäftigt. Also tat Google zwei Dinge: Android und Chrome.
Chrome versprach ein besseres, schnelleres Surferlebnis. Es war karg, aber Google ging sogar so weit, den berühmten (zumindest in meinen Kreisen) Comiczeichner Scott McCloud zu engagieren, um einen Comic zu erstellen, der die Mission des Browsers den Nutzern erklärt. Mit der Allgegenwart von Chrome auf jedem Betriebssystem und Android-Telefon, seinen DevTools, die sich an Firebugs beliebter Firebug-Erweiterung von Firefox orientierten, und zunehmender Beteiligung an Specs, weckte Chrome nicht nur Internet Explorer aus seinem Schlummer, es drohte fast, jede andere Browser-Engine auf dem Planeten zu vernichten!
Das Beschneiden des großen Stammbaums der Browser (oder der Sammlung von Büschen, wie man will) auf einen einzigen Zweig riecht nach fragiler Monokultur. Monokulturen werden durch ökologische und umweltbedingte Herausforderungen – durch Markt- und demografische Veränderungen – leicht gestört. Was passiert, wenn die nächste Bedrohung für das Web auftaucht, wir aber nicht die Multithreading-Fähigkeiten von Firefox haben? Oder die Systemintegration von Microsoft Edge? Werden wir schnell genug iterieren können, ohne sie? Oder werden wir uns an die Chrome-Entwickler wenden und hoffen, dass sie nicht stagnieren, wie Google es tat, als es sich nach dem „Gewinnen des Webs“ anderen Dingen widmete, so wie Microsoft es tat.
Es ist ironisch, dass der Browser, den Google baute, um zu verhindern, dass das Web gegen Apps verliert, selbst die Webentwicklung monopolisiert, ähnlich wie es Internet Explorer 6 tat.

Es ist gut, der König zu sein (des Dschungels)
Ich habe versprochen, auf „Benutzerbasisgröße als Feature“ zurückzukommen. Die überwiegende Mehrheit der Webentwicklergemeinschaft, die für Ihre Plattform entwickelt und testet, ist ein großer Wettbewerbsvorteil. Erstens ist garantiert, dass die meisten Websites in Ihrem Browser perfekt funktionieren – Sie müssen nicht so viel Zeit und Mühe darauf verwenden, Fortune-500-Websites auf diesen einen seltsamen Bug aufmerksam zu machen, der dazu führt, dass alle ihre internen Benutzer zu Ihrem Konkurrenzbrowser wechseln und nie wiederkommen. Ein Abwärtsstrudel aus weniger Benutzern, der zu weniger Entwicklertests führt, was zu weniger Benutzern führt, ist schwer zu durchbrechen.
Es erleichtert auch die Vorschlagung neuer Spezifikationen, die den Zielen Ihres Mutterkonzerns dienen (die vielleicht nicht den Zielen der Web-Community dienen) und die große Gemeinschaft von Entwicklern dazu bringen, zuerst Ihre Implementierung zu nutzen, ohne darauf warten zu müssen, dass andere Browser aufholen. Wenn ein kleinerer Browser eine Spezifikation vorschlägt, die niemand bemerkt, und Sie sie bei Bedarf aufgreifen, werden die Leute sie als Ihre Leistung in Erinnerung behalten und weiterhin Ihren Bekanntheitsgrad aufbauen, ob absichtlich oder nicht.
Dies übt Abwärtsdruck auf die Konkurrenz aus, die einfach nicht über dieselben Ressourcen verfügt oder diese nicht nutzen kann, die dem größten Browserteam zur Verfügung stehen. Es ist eine brutal effiziente Methode, ob durch Design oder Zufall.
Ist es tugendhaft? Auf der Ebene des einzelnen Beitragsenden, ja. Ist es ein Teufelskreis, durch den Unternehmen ihre Konkurrenz zur Ausrottung getrieben haben, indem sie sie gezwungen haben, begrenzte Ressourcen auszugeben, um aufzuholen? Auch ja. Und die Legionen von Leuten, die nur für Ihre Plattform bauen, helfen.
All die großartigen, wohlmeinenden, ehrlich herzensguten Leute – vom Chrome-Team bis zu den Webentwicklern – können die Hände hochheben und legitim sagen: „Ich habe nur versucht, das Web voranzubringen!“, während sie dazu beitragen, ein Unternehmensmonopol zu festigen.
Chrome verfügt über die meisten Ressourcen und ist führend beim Vorantreiben des Webs, bis zu einem Punkt, an dem wir uns nicht sicher sein können, ob wir das Web bauen, das wir wollen… oder das Web, das Google will.
Spekulative Biologie
Es gab eine Zeit, in der Microsoft Apple gerettet hat, als es kurz vor dem Untergang stand. Das lag nicht daran, dass Bill Gates und Steve Jobs Freunde waren – nein, Microsoft brauchte Apple, um erfolgreich zu sein, damit es weiterhin Betriebssystemwettbewerb gab. (Kein Unternehmen möchte als Monopolist dastehen!)
Aber bedenken Sie einen Moment, was wäre, wenn Apple *gestorben* wäre. Wie sähen Personal Computer heute aus, wenn nur noch Linux und Windows übrig geblieben wären? Wie sähe mobiles Computing aus, wenn Apple nicht da gewesen wäre, um am iPhone zu arbeiten?
Ja, es ist einfacher, in nur einem Browser zu entwickeln und zu testen. Ich bin sicher, IT-Profis hätten gerne nur eine Art von Maschine unterstützt. Aber Vielfalt schafft langfristig Chancen für uns als Entwickler. Microsofts Rettung von Apple führte zu Apps, die das Web herausforderten, was uns Chrome und die unzähligen APIs bescherte, mit denen Google voranschreitet. Wenn zu irgendeinem Zeitpunkt in dieser Kette von Ereignissen jemand gesagt hätte: „Meh, es ist viel einfacher, wenn wir alle dasselbe verwenden“, hätten wir nicht die Karrieren – oder die Welt –, die wir jetzt haben.
Entwickeln Sie in mehr als einem Browser. Testen Sie in mehr als einem Browser. Nutzen Sie mehr als einen Browser.
Sie sind sowohl Konsument als auch Produzent. Sie haben ein Mitspracherecht bei der Gestaltung der Zukunft.
Update: Ich habe diesen Beitrag aktualisiert, um ein wenig über WebKit auf iOS, die Rolle von Firefox während der Ära von IE6 und die explizite Hervorhebung von Servo zu erweitern, was wahrscheinlich das Aufregendste ist, was derzeit in Browsern passiert.
Obwohl es sich noch um ein experimentelles Projekt handelt und vielleicht nie in einem tatsächlichen Browser zu sehen sein wird, ist Mozillas und Samsungs Servo eine neue Rendering-Engine, die von Grund auf neu gestartet wird.
Was für eine tolle Lektüre. Gut gesagt!
Toller Artikel!
Ich bin mir nicht sicher, ob die Erklärung der Rettung korrekt ist. Zitat: „Das lag nicht daran, dass Bill Gates und Steve Jobs Freunde waren – nein, Microsoft brauchte Apple, um erfolgreich zu sein, damit es weiterhin Betriebssystemwettbewerb gab. (Kein Unternehmen möchte als Monopolist dastehen!)“ – Das mag teilweise richtig gewesen sein, aber Sie müssen bedenken, dass die Bedingungen für die Rettung eine cross-plattform Lizenzvereinbarung zwischen Microsoft und Apple beinhalteten, die Microsoft Zugang zum Markt verschaffte, den Mac geschaffen hatte. Zusätzlich musste Apple auf eine Klage gegen Microsoft verzichten, die Urheberrechtsverletzungen an einigen oder allen Betriebssystemen des Konkurrenten behauptete. Es war eine großartige Geschäftsstrategie. Stellen Sie sich vor, die Green Bay Packers retten die Minnesota Vikings (zwei rivalisierende NFL-Teams, deren Fans sich zum Sport gemacht haben, sich zu hassen), aber als Bedingung dafür könnte Green Bay eine Lizenz erhalten, Vikings-Merchandise und -Kleidung zu drucken und mit Gewinn zu verkaufen.
Ein wirklich brillanter Artikel. Danke und gut gemacht.
Einer der besten Artikel, die ich je hatte, sehr gut geschrieben, technisch fundiert und unterhaltsam.
Herzlichen Glückwunsch Rachel!
Ricardo
Toller Artikel. Vielen Dank!
Es könnte erwähnenswert sein, dass Webkit selbst ein Fork von KHTML aus dem KDE-Projekt war und ursprünglich im Konqueror-Browser verwendet wurde.