Wir haben Opera verloren, als sie 2013 zu Chrome wurden. Dasselbe gilt für Edge, als es Anfang dieses Jahres ebenfalls zu Chrome wurde. Mike Taylor nannte diese Änderungen in einem Vortrag, den ich gerne sehen würde, eine „abnehmend vielfältige Browser-Engine-Welt“.
Übrig bleiben uns also nur Chrome-Sachen, Firefox-Sachen und Safari-Sachen. Chrome und Safari haben dieselbe Abstammung, haben sich aber so weit auseinanderentwickelt, sich so unterschiedlich entwickelt und sind so voneinander abgeschottet, dass es sinnvoll ist, sie als voneinander verschieden zu betrachten.
Ich weiß, dass es dafür schickere Wörter gibt. Zum Beispiel haben Browser-Engines selbst Namen, die sich von den Namen der Browser unterscheiden.
Nehmen wir Chrome, das auf dem Open-Source-Projekt Chromium basiert, das die Rendering-Engine Blink und die JavaScript-Engine V8 verwendet.
Firefox verwendet Gecko als Browser-Engine, die sich zu Quantum entwickelt, welches Unterteile wie Servo für CSS und Rendering hat.
Safari verwendet WebKit als Browser-Engine, die Teile wie WebCore und JavaScriptCore hat.
Das ist alles irgendwie kompliziert und ich bin mir nicht einmal sicher, ob ich es ganz verstehe. Mein Gehirn denkt einfach, dass alles unter dem Schirm des Hauptbrowsers zusammengefasst ist.
Die zwei Extreme, wenn man dies aus der Perspektive abnehmender Vielfalt betrachtet
- Das ist schlecht. Abnehmende Vielfalt kann Ökosysteme daran hindern, zu konkurrieren und innovativ zu sein.
- Das ist gut. Probleme zwischen Engines sind ein großer Produktivitätsverlust für die Welt. Es wäre noch besser, auf ein einziges Ökosystem zu kommen.
Was auch immer es ist, das Schiff ist abgefahren. Wir können nur nach vorne schauen.
Zufällige Gedanken
- Vielleicht hat sich die Vielfalt einfach verschoben. Anstatt dass die Browser-Engines selbst Vielfalt darstellen, können vielleicht *Forks* der verbleibenden Engines gegeneinander konkurrieren. Vielleicht ist es ein guter Startpunkt für Innovation, von einer starken Grundlage auszugehen?
- Wenn wir, Gott bewahre, auf eine einzige Browser-Engine reduziert würden, was passiert dann mit dem Web-Standards-Prozess? Die Befürchtung wäre, dass die letzte verbleibende Engine sich nicht mehr um Interoperabilität kümmern muss und mit Implementierungen wild um sich greift. Aber bedeutet wildes Umgreifen, dass das Spielfeld nie wieder wettbewerbsfähig sein kann?
- Es ist großartig, wenn Browser um Funktionen konkurrieren, die für Benutzer großartig sind, aber Web-Standards nicht betreffen. Großartige Passwort-Manager, Funktionen zum Schutz des Benutzers, clevere Lesezeichen-Ideen, Lese-Modi, saubere Integrationen mit Zahlungs-APIs, kostenlose VPNs usw. Das war der Ansatz von Opera, und jetzt sehen wir viele weitere in die gleiche Richtung. Vivaldi setzt auf Anpassung, Brave setzt auf Datenschutz und Sicherheit, und Puma auf Monetarisierung.
Brian Kardell hat kürzlich über einige dieser Dinge in seinem Beitrag „Beyond Browser Vendors“ geschrieben. Ein interessanter Punkt ist, dass die verbleibenden Browser-Engines alle Open Source sind. Das bedeutet, dass sie externe Beiträge erhalten können und auch erhalten, was genau der Grund ist, warum CSS Grid entstanden ist.
Die meiste Arbeit an CSS Grid sowohl in WebKit als auch in Chromium (Blink) wurde nicht von Google oder Apple geleistet, sondern von Teams bei Igalia.
Denken Sie eine Minute darüber nach: Die Priorisierung ihrer Arbeit wurde in 2 Browsern nicht von einem Anbieter bestimmt, sondern durch eine Investition von Bloomberg, die die Voraussicht hatte, diese weitgehend unumstrittene Arbeit zu finanzieren.
Und nun setzt sich diese Idee fort
Dies ist keine einzigartige Geschichte, sondern nur eine wirklich wichtige und sehr sichtbare, die man sich gerne vor Augen hält. Tatsächlich haben Ingenieure bei Igalia in den letzten 6 Monaten an CSS Containment, ResizeObserver, BigInt, privaten Feldern und Methoden, responsiven Bild-Preloading, CSS Text Level 3, der Portierung von MathML nach Chromium, der Normalisierung von SVG- und MathML-DOMs und vielem mehr gearbeitet.
Was wir möglicherweise an Browser-Engine-Vielfalt verloren haben, gewinnen wir möglicherweise durch die Offenheit von Browser-Engines und das Eingreifen externer Akteure zurück.
Ich neige dazu, die abnehmende Anzahl von Browser-Engines als Reifeprozess der Web-Plattform zu betrachten.
Bei all meinen Vorträgen über den Unterschied zwischen Frontend und Backend kann ich nicht genug betonen, dass wir im Frontend nicht wissen, auf welches Gegenstück wir zielen. Während ein Backend-Entwickler immer weiß, auf welchen Server er abzielt und welche Version von PHP, Java oder was auch immer dieser Server hostet. UND: Es gibt nur EINEN Interpreter mit 100% Fähigkeiten und keinen Fehlern. Wenn ein Fehler im Backend auftritt, ist es IHR Fehler.
Wie anders das Frontend ist. Wir haben mehrere Browser-Engines, keine davon hat ein 100%iges Wissen über HTML, CSS und JS. Und selbst wenn sie es hätten, wären ihr Wissen und ihre Implementierung unterschiedlich. Es gäbe zusätzliche Unterschiede aufgrund der Betriebssysteme, insbesondere hinsichtlich der Implementierung von Formularsteuerelementen und der Kommunikation mit der Barrierefreiheits-Schicht.
Ich habe einen Traum: Es wäre gut, wenn sich alle Browser-Anbieter darauf konzentrieren könnten, die bestehenden Standards so perfekt und interoperabel wie möglich in allen bestehenden Browsern zu implementieren.
Safari ist in meinen Augen ein Witz
– Neue Probleme mit jedem Update.
– Teilweise/nicht implementierte Standards.
– Scroll-Probleme.
– Bug-Reports werden mit „wird nicht behoben“ geschlossen.
– Inkonsistenzen zwischen Desktop und Mobilgeräten.
– Und die Liste geht weiter…
Es ist im Grunde das neue IE11, unsere Codebasis ist einfach voll mit `isSafari` und `if(getVersion()…)` Aufrufen, `-webkit-` Hacks.
Als Beispiel: Ihr letztes Update (13) führte dazu, dass unsere Gradient-Layer außerhalb von Boxen mit `overflow:hidden` herauskamen. Lösung: `translateY(0)`…
Ich kann Ihnen in diesem Punkt nur zustimmen. Ich musste in der Vergangenheit einige Lösungen für Safari-Bugs finden. Es ist nicht schrecklich, aber es fühlt sich an, als würde es in die IE11-Gefilde abdriften. Da ich hauptsächlich unter Windows entwickle, verstärkt dies das Problem, da es ziemlich nervig ist, Tools wie Browserstack, andere Emulatoren und/oder eine virtuelle Maschine verwenden zu müssen, um Safari 12+ auszuführen.
Ich stimme zwar zu, dass ein Monopol nicht optimal ist, aber das Opfern von Leistung zugunsten von Vielfalt ist schlimmer als das Opfern von Vielfalt zugunsten von Leistung
Ich schaue dich an, Mozilla
Chrome und Firefox werden beide von Google finanziert. Und da Edge jetzt auch WebKit verwendet, scheint es, als hätte Google nun ein Monopol auf Web-Standards. Nun, ich sage nicht, dass das schlecht ist, da ich ein großer Fan von Google bin, aber um Sie etwas zu paraphrasieren: „Abwechslung ist die Würze des Lebens.“
Wenn nur Chrome übrig bleibt, viel Glück, mit allem Schritt zu halten, womit sie jede Woche aufwarten, was immer noch im TC39 diskutiert wird. Und wird TC39 überhaupt noch etwas wert sein? Und was ist, wenn Sie in 10 Jahren einen Browser zu entwickeln beginnen? Wie viel Zeug werden Sie implementieren müssen? Was wird Ihre Referenz sein? Nein danke, nur Google passt nicht zu mir.
Ein wichtiger Punkt fehlt oft, und das sind die Kosten. Die Entwicklung und der Betrieb eines Evergreen-Browsers sind extrem kostspielig, und das erklärt gut, warum immer weniger Organisationen sich das leisten können.
In einer interessanten Wendung tragen wir als Entwickler, die gerne Feature für Feature zu den technischen Spezifikationen hinzugefügt sehen, dazu bei, diese Kosten in die Höhe zu treiben. Und damit auch dazu, Browser zu verdrängen.
(Es wäre großartig, wenn Anbieter etwas zu den Kosten sagen könnten, ob es sich nur um Millionen oder direkt um Milliarden handelt. Konkrete Zahlen könnten helfen zu verstehen, was die Wartung eines Browsers heutzutage wirklich bedeutet.)
Sehr gute Punkte, die Sie hervorgehoben haben! Was bedeutet eine geringere Engine-Vielfalt?
Ich denke, dass Edge auf eine Chromium-Engine umgestellt hat, ist eine gute Sache. Wie erwähnt, ist die Vielfalt nur ein anderer Umfang. Microsoft hat seine Haltung dahingehend, was in Chromium und was in ihren eigenen Fork einfließt, definitiv gestärkt.
Solange die Unternehmen, die Teil von ECMA sind, Web-Standards vorantreiben, sind die Browser wahrscheinlich in guten Händen.
Vergleichen Sie das mit dem, was mit IE und Microsoft passiert ist. IE war proprietär, Microsoft hatte einen sehr festen Griff auf den Browser-Markt und Microsoft trug nicht gut zu Web-Standards bei. Sie machten ihr eigenes Ding. IE scheiterte wirklich schnell.
Während Chromium und Google das Gegenteil tun. Chromium ist Open Source und Google ist ein großer Mitwirkender an Web-Standards. Zwar hat Chrome wie früher IE einen sehr guten Marktanteil, aber wichtiger sind die Open-Source-Software und die Beiträge zu Web-Standards. Open-Source-Software bedeutet, dass jeder, der nicht an Google gebunden ist, auch beitragen kann. Und dass Google Web-Standards mit anderen Unternehmen bespricht, ist ermutigend.
Eine einfachere Anbieterlandschaft ist offensichtlich gut. Aber wenn Google am Ruder ist, wie lange wird es dauern, bis dies zu einem Kartellrechtsfall wird?
Es ist ziemlich offensichtlich, dass die meisten Browserentwickler Chromium als ihre Engine wählen. Apple macht wie üblich sein eigenes Ding und hat viel Geld und Leute, um WebKit eigenständig zu entwickeln. Mozilla hingegen sollte sich mehr vor Chromium fürchten, angesichts des schwindenden Marktanteils von Firefox. Das größte Problem bei der Dominanz von Chromium im Browser-Markt sind die Standards. Macht durch Zahlen, wie man sagt, gibt Chromium die Möglichkeit, diese festzulegen, anstatt sich nur an sie zu halten. Der offensichtliche Elefant im Raum ist die kombinierte Ingenieursleistung von Microsoft und Google bei der Entwicklung von Chromium. Kann das Firefox-Team mit einer solchen Machtbasis von Ingenieuren überhaupt mithalten? Das ist wahrscheinlich die größte Angst von Mozilla und die Suche nach Partnern scheint im Moment ein Ding der Unmöglichkeit zu sein. Ich würde Mozilla vorschlagen, Gecko aufzugeben und zu WebKit zu wechseln und mit Apple an der Entwicklung dieser Engine zusammenzuarbeiten. Andernfalls scheint Gecko der offensichtliche Verlierer zu sein.
Außer… Mozillas Engine ist jetzt WebKit weit überlegen. Viel Glück dabei, Apple dazu zu bringen, Quantum zu übernehmen und mit Mozilla zusammenzuarbeiten. Auch ich habe schon oft den Schmerz von „Safari ist das neue IE“ erlebt.
Ich bin nur überrascht, dass mehr Entwickler Apple nicht dafür hassen, dass jeder Browser auf iOS WebKit verwendet. Vielleicht, weil die meisten iOS-Benutzer gar nicht wissen, dass Edge, Opera oder Chrome nicht ihre native Engine verwenden, weil Apple es nicht zulässt. Leider ist das bei Android nicht viel anders, und angesichts der Tatsache, wie sehr Mobilgeräte das Web heute beeinflussen. Wir haben einige Probleme mit dieser Anforderung. Der andere Elefant im Raum ist, wie sowohl Chromium als auch WebKit als Open Source gelten, aber hauptsächlich von großen Privatunternehmen wie Apple, Google und Microsoft entwickelt werden. Abgesehen davon, dass sie im Geiste als Open Source gelten, sind diese Engines wirklich so offen?