Es scheint, dass die meisten gängigen Webbrowser (Firefox, Chrome, Safari) mit C ++ entwickelt wurden. Warum ist das so?

Eine andere Möglichkeit, die Frage zu stellen, ist, welche Unterstützung ein Browser benötigt. Die kurze Liste ist:

• Unterstützung für das Parsen (erforderlich, um [X] HTML, CSS und [ECMA / Java] -Skript zu verstehen)
• Tree-Walking- / Interpretationsfunktionen (Teil der Benutzeroberfläche zum Parsen und Erstellen)
• Unterstützung für beschleunigte Grafiken
• Schnelle Vernetzung
• Für fortgeschrittene Browser: Kontrolle über Prozesse und Isolieren des Speichers zwischen Seiten
• Muss auf allen unterstützten Plattformen funktionieren

Die meisten Sprachen unterstützen das Parsen. Sie haben Parser-Generatoren für C, C ++, C #, Java usw. C und C ++ haben jedoch einige Jahre Vorsprung auf die restlichen Alternativen, sodass die Algorithmen und Implementierungen ausgereifter sind. Der Zugriff auf beschleunigte Grafiken in Java ist ein Kinderspiel, es sei denn, Sie haben einige native Erweiterungen, damit dies funktioniert. WPF auf C # bietet Zugriff auf beschleunigte Grafiken, aber es ist zu neu, um einen seriösen Browser mit dieser Technologie zu haben.

Das Netzwerk ist eigentlich der geringste Grund, sich für C ++ anstelle von Java oder C # zu entscheiden. Der Grund dafür ist, dass die Kommunikation um ein Vielfaches langsamer ist als der Rest der Verarbeitung, mit der die Seite angezeigt wird. Die Rohgeschwindigkeit des Drahtes ist der begrenzende Faktor. Sowohl Java als auch C # und C ++ unterstützen nicht blockierende E / A. Es gibt also wirklich keinen klaren Sieger in diesem Bereich.

Warum nicht Java? Haben Sie jemals versucht, eine Benutzeroberfläche mit Java zu erstellen? Es fühlt sich schwerfällig und langsam an im Vergleich zu allem anderen da draußen, weil es so ist. Keine beschleunigte Grafik ist auch hier ein großes Minus. Javas Sandboxing ist wirklich gut und kann dazu beitragen, die Sicherheit eines Browsers zu verbessern, wenn er richtig verwendet wird. Es ist jedoch mühsam, ihn zu konfigurieren und in Betrieb zu nehmen. Ganz zu schweigen davon, dass die Unterstützung des Grafikformats hinter den meisten modernen Browsern zurückbleibt.

Warum nicht C #? Wenn Ihr einziges Ziel Windows ist, kann C # tatsächlich eine gute Darstellung liefern. Das Problem tritt auf, wenn Sie etwas anderes unterstützen möchten. Mono hat nicht genug aufgeholt, um für diese Aufgabe als plattformübergreifend angesehen zu werden - insbesondere mit beschleunigter Grafikunterstützung und WPF. Wer weiß, wie lange das dauern wird.

Warum nicht C? Es gibt einen C-Compiler für nahezu jede Plattform (einschließlich eingebetteter Geräte). Es gibt jedoch eine Menge, die C nicht für Sie erledigt , bei denen Sie besonders wachsam sein müssen. Sie haben Zugriff auf alle untersten Ebenen der APIs, aber die Mehrheit der C-Entwickler macht keine GUIs. Auch die C-GUI-Bibliotheken sind objektorientiert geschrieben. Sobald Sie anfangen, über die Benutzeroberfläche zu sprechen, ergibt eine objektorientierte Sprache einen besseren Sinn.

Warum nicht Ziel C? Wenn Ihr einziges Ziel Apple ist, ist dies sehr sinnvoll. Die meisten Entwickler kennen Objective-C jedoch nicht und der einzige Grund, dies zu lernen, besteht darin, mit NeXT- oder Apple-Boxen zu arbeiten. Natürlich können Sie mit Objective-C jede C-Bibliothek verwenden, und es gibt Compiler für viele Plattformen, aber es ist schwieriger, Leute zu finden, die daran arbeiten können. Wer weiß? Vielleicht kann Apple diesen wahrgenommenen Mangel beheben.

Warum C ++? Es gibt einen C ++ - Compiler für nahezu jede Plattform. Fast jede GUI-Bibliothek hat eine C ++ - Schnittstelle, manchmal ist es besser und manchmal ist es einfach anders. Beispielsweise ist Microsofts ATL viel besser als Win32 C-Funktionsaufrufe oder sogar die MFC-Bibliothek. Es gibt C ++ - Wrapper für GTK unter Unix, und ich wäre überrascht, wenn jemand keinen C ++ - Wrapper für die Objective-C-GUI-Bibliothek von Apple hätte. Die Prozessverwaltung ist in C ++ einfacher als in Java oder C # (diese Details werden für Sie abstrahiert). Die wahrgenommene Geschwindigkeit ergibt sich eher aus der Hardwarebeschleunigung als aus der Rohleistung. C ++ kümmert sich um mehr Dinge als um rohes C (z. B. begrenzte Zeichenfolgen), gibt Ihnen aber dennoch die Freiheit, Dinge zu optimieren.

C ++ verdrängt derzeit die Alternativen.

Ich habe beschlossen, einen Roman darüber zu schreiben, in der Hoffnung, dass die Leute ihn beschönigen und mich unterstützen. Nein, nein, nur ein Scherz! Ich habe über jedes Wort gelitten. Jedes Wort, sage ich dir!

Fragen Sie 'wann' vor 'warum'

Alle gängigen Webbrowser können ihre Ursprünge bis in die 90er Jahre zurückverfolgen. Konqueror wurde Safari und Chrome; Netscape wurde zu Firefox. IE und Opera sind immer noch IE und Opera. Diese Browser haben alle einen Vorsprung von 15 Jahren auf die etablierten Betreiber.

Ich schlage vor , Sie versuchen sogar zu nennen eine akzeptable Cross-Plattform (Windows / Mac / Unix und noch schlimmer) Sprache , die in etwa 1995 verfügbar war , als moderner Browser stammte. Um den Kern in etwas anderem als C / C ++ zu erstellen, mussten Sie wahrscheinlich einen Compiler und Plattformbibliotheken erstellen oder kaufen und modifizieren.

Wie wäre es heute? Was sind die Alternativen?

Denken wir heute nur zum Spaß über das Problem nach. Ja, es gibt Alternativen, aber es gibt immer noch große Probleme.

Die Wahl der Sprache wirft zumindest folgende Probleme auf:

1. Wissensprobleme - Einstellung / Schulung von Entwicklern oder Gewinnung von Mitarbeitern
2. Organisatorische / soziale Probleme - Sprachakzeptanz
3. Sprachimplementierung: Geschwindigkeit, Plattformunterstützung, Tooling
4. Sprachgewalt

1: Wissensprobleme

Woher bekommen Sie Leute, die die Sprache kennen oder lernen können? Dies ist ein Hindernis für Sprachen wie OCaml, F #, Haskell, Common Lisp und D, die schnell und hoch genug sind, um einen Browser gut zu schreiben, aber nur wenige Anhänger haben (im Bereich von 10.000 bis 100.000), selbst wenn Sie liberal sind Zählen Sie alle Bastler und Akademiker.

2: Soziale / organisatorische Probleme

Die obige Antwort auf den Frachtkult lautet:

• Ein Open-Source-Browser, der C, C ++, C # oder Java nicht verwendet, wird angeblich Probleme mit Mitwirkenden haben.
• Ein proprietärer Browser, der nicht C, C ++, C # oder Java verwendet, wird in den meisten Organisationen von Projektmanagern heftig angeschrien.

3. Technische Probleme

Selbst in der heutigen Zeit benötigen Sie eine relativ schnelle Sprache für die rechenintensiven Teile des Renderns von Seiten und für das Ausführen von Javascript. Sie können dies durch eine Hochsprache zum Erstellen von GUI-Elementen usw. ergänzen (z. B. der Firefox-Ansatz von C ++ und Javascript), müssen jedoch eine enge Integration zwischen den Sprachen aufweisen. Sie können nicht einfach "Okay, C # und Lua" sagen. Sie müssen diese Bridge wahrscheinlich selbst erstellen und debuggen, es sei denn, Sie wählen C oder C ++ als Basissprache.

Die plattformübergreifende Entwicklung ist ein weiterer Haufen Würmer. Sie könnten C # oder F # verwenden und die Daumen drücken, wenn GTK # und Mono in Zukunft noch am Leben sind. Sie könnten versuchen , Common Lisp, Haskell, OCaml ... Viel Glück immer alles funktioniert unter Windows und Mac und Linux.

4. Sprachpower

Nach alledem müssen Sie eine enorme Menge an Funktionen erstellen. Wenn Sie sich also für eine einfache Sprache entscheiden, benötigen Sie eine noch größere Anzahl an Programmierern als zuvor. Beachten Sie, dass in etwa fünfzehn Jahren niemand wirklich einen Browser von Grund auf neu erstellt hat. Das liegt zum Teil (Überraschung!) Daran, dass es schwer ist.

Speziell ein Javascript-Interpreter ist ein Problem 3 (erwerben Sie einen) oder ein Problem 4 (erstellen Sie einen).

Fazit:

Wenn Sie heute (Anfang 2011) einen Browser mit drei Plattformen (Windows / Mac / * nix) entwickelt haben, welche Optionen stehen zur Auswahl?

• C: Siehe (2). Jeder wird nach C ++ verlangen. Viel Spaß beim Auswählen oder Erstellen eines plattformübergreifenden Toolkits (1, 2, 3 und 4). Siehe auch (4); Viel Spaß beim Erstellen eines stabilen, sicheren Browsers.
• C ++: Viel Spaß beim Auswählen oder Erstellen eines plattformübergreifenden Toolkits (1, 2, 3 und 4). Viel Spaß beim (4) Aufbau eines stabilen, sicheren Browsers.
• C oder C ++ und HLL: Ihre beste Wahl. Wählen Sie Ihr Gift auf der dynamischen Sprache aus; Siehe (1) und (2). Zu viele gute Sprachen, zu wenige Anhänger. (1, 2, 3 und 4) im Toolkit.
• Java: Zweitbeste Wette, wenn Sie das mittlere Management zufrieden stellen müssen. Siehe (4); Das Erstellen von riesigen Dingen in Java erfordert viel mehr Code als in allen anderen Dingen auf dieser Liste, aber vielleicht C.
• Scala: Beats Java auf (4); (1) und (2), aber es fängt an.
• C und Javascript: Als Sonderfall ist dies ansprechend, da Sie bereits einen Javascript-Interpreter erstellen oder erwerben und assimilieren müssen. (Daher Firefox.) (1, 2, 3 und 4) im Toolkit; Die Mozilla-Leute bauten ihr eigenes IIRC.
• Viel Spaß auf (3). Sie bleiben wahrscheinlich bei GTK # hängen, wie gut das auch sein mag, oder Sie erstellen eine eigene Ebene und einen eigenen Renderer über GTK # und Windows Forms.
• Ruby / Python / Perl / Racket / Lua / Erlange etc .: Sie haben (3) plattformübergreifende Widget-Bibliotheken und Geschwindigkeit. Moores Gesetz ist bei dir (4); Die wachsende Nachfrage nach Browsern richtet sich gegen Sie.
• OCaml, Haskell, Common Lisp, Smalltalk: (1) und (2) in Pik. Wahrscheinlich keine Geschwindigkeitsprobleme, aber (3) für die plattformübergreifende Entwicklung, und Sie müssen auf irgendeine Weise Ihr eigenes "Alles" oder eine Brücke zu C / C ++ - Bibliotheken bauen.
• Ziel C: (3) Ich bin nicht sicher, wie die plattformübergreifende Entwicklung hier ablaufen würde.

Wenn in den nächsten Jahren ein weiterer großer Browser auftaucht, würde ich wetten, dass er in C oder C ++ und einer dynamischen Sprache (wie Firefox) geschrieben wird, egal ob Open Source oder proprietär.

Edit (31. Juli 2013) : Kommentatoren in den Hacker News scheinen Rust and Go zu erwähnen (nicht speziell im Zusammenhang mit meiner Antwort), die vage in den "sonstwie schnellen" Eimer fallen. Der Versuch, diese Liste der Sprachen egalitär und auf dem neuesten Stand zu halten, wird eine Niederlage sein. Stattdessen nenne ich sie zum Zeitpunkt des Schreibens eine repräsentative Stichprobe und lasse sie in Ruhe.

Geschwindigkeit

So hässlich es auch ist, C ++ ist immer noch das, was Sie verwenden, wenn Sie eine schnelle Anwendung und vollständige Kontrolle über den Code wünschen.

Aus diesem Grund werden Spiele, nicht zum Kern gehörende Teile (z. B. Dateiimporteure) von Office und andere weiterhin in C ++ geschrieben.

Bearbeitet, um die Antwort von MSalters einzuschließen

Portabilität

Ich kann nur raten, aber Sie erwähnen Softwareprodukte, die auf mehrere Plattformen abzielen, und C ++ kann auf jeder Plattform kompiliert werden.

(Ich arbeite seit ungefähr fünf Jahren an Firefox.)

Der Fragesteller hat Recht, dass ein Großteil des Firefox-Codes C ++ ist, und tatsächlich ist C ++ die Mehrheit, wenn Sie nach Codezeilen zählen (obwohl dies nicht die ganze Geschichte erzählt, da wir viel JavaScript haben und JS mehr ist prägnanter als C ++).

In Wirklichkeit ist Firefox jedoch in vielen verschiedenen Sprachen geschrieben:

• C ++
• C (NSS, NSPR, verschiedene Bibliotheken, die wir importiert haben)
• x86- und ARM-Assembly
• JavaScript
• XUL (eine HTML-ähnliche Auszeichnungssprache) und CSS
• Ziel C (nur MacOS-Code)
• Java (nur für Android)
• Mehrere benutzerdefinierte Schnittstellendefinitionssprachen (XPIDL, IPDL)
• WebIDL (eine andere Sprache für die Schnittstellendefinition, aber diese ist nicht benutzerdefiniert, obwohl der Codegenerator dies ist)
• Python (Codegeneratoren)

Ich vergesse sicher einige.

Diese Liste ist wichtig, da sie auf die unglaubliche Komplexität hinweist, die sich hinter einem Webbrowser verbirgt.

Ja, Firefox hat viel C ++ - Code, und ja, das hat etwas damit zu tun, dass C ++ bei der Gründung von Netscape die beste Sprache für diese Art von Dingen war. Aber ich behaupte auch, dass es heute für vieles, was wir tun, keine bessere Sprache gibt.

Keine andere Sprache hat ein so starkes Bibliotheksökosystem (wir stützen uns stark auf externen Code). Nur wenige andere Sprachen bieten Ihnen eine Full-Stack-Kontrolle wie C ++ (wir optimieren regelmäßig unseren benutzerdefinierten Heap-Allokator und tun alle möglichen speichersicheren Dinge, um schneller zu sein oder weniger Speicher zu verbrauchen). Mit wenigen anderen Sprachen können Sie den größten Teil der Standardbibliothek auf vernünftige Weise neu implementieren (wir haben unsere eigenen Strings und Collections-Implementierungen, die auf unsere Bedürfnisse abgestimmt sind). In wenigen anderen Sprachen können Sie Ihren eigenen Garbage Collector implementieren. Und so weiter.

Obwohl C ++ die offensichtliche Wahl für viele unserer Aufgaben ist, sind die Leute, die vorschlagen, dass wir einen Browser in Java schreiben und gegebenenfalls unsere eigene JVM schreiben könnten, auf dem Laufenden. Dies ist im Wesentlichen das, was wir tun, aber mit JavaScript anstelle von Java. Natürlich ist ein Großteil des Browsers nicht in JavaScript geschrieben. Aber eine überraschende Menge ist.

Nun, Sie müssten die Entwickler dieser Produkte direkt fragen, um die Antwort zu erhalten, aber ich vermute, es ist eine Kombination aus Vertrautheit (das wussten die Entwickler am besten), Leistung (Kompilieren in eine native Binärdatei im Gegensatz zu Bytecode) und Tools (im Vergleich zu Sprachen wie C, C ++ ist voll von netten arbeitssparenden Gadgets wie der STL).

Geschichte

Jeder der Browser hat eine Geschichte, die die Wahl der Sprache beeinflusst.

Beispielsweise basieren sowohl Chrome als auch Safari auf WebKit, dessen Ursprung im KHTML-Teil des KDE-Projekts liegt. KDE wurde ursprünglich (teilweise) als Demonstration des Qt-GUI-Toolkits erstellt, sodass KDE insgesamt ein C ++ - Projekt ist. Alle neuen KDE-Projekte wurden zu dieser Zeit vollständig in C ++ geschrieben, daher war dies eine logische Wahl für KHTML. Es wurde inzwischen für die Verwendung anderer GUI-Toolkits portiert.

Die Presto-Engine von Opera wurde mit Blick auf Leistung und eine kleine Binärgröße geschrieben: C ++ war die logische Wahl.

Der IE von Microsoft wurde als Sammlung von ActiveX-Komponenten geschrieben, die in jeder Sprache mit COM-Bindungen geschrieben sein könnten, aber wahrscheinlich in einer Teilmenge von C ++ geschrieben wurden, da der Großteil ihrer Codebasis bereits in dieser Sprache geschrieben ist.

Mozilla von Netscape wurde wahrscheinlich in C ++ geschrieben, weil die Portabilität ein Hauptanliegen von Netscape war. C- und C ++ - Compiler sind (praktisch) allgegenwärtig, und so war es eine logische Wahl.

Es gibt keinen inhärenten technischen Grund für diese Auswahl. Es schien nur "eine gute Idee zu der Zeit."

Das Netzwerk in C und C ++ ist einfach zu optimieren, da Sie keine Bibliotheken verwenden müssen, wenn Sie dies nicht möchten. Ich vermute, dass C ++ die Sprache der Wahl ist, da es die Vorteile von C bietet:

• Geschwindigkeit
• Optimierung
• Eine gewisse Portabilität
• Kompilierte Sprache, nicht interpretiert

gepaart mit den Vorteilen von OOP:

• Erweiterbarkeit
• Einfachere Visualisierung
• Bessere Bibliotheksunterstützung für unkritische Aufgaben wie die Verarbeitung von Zeichenfolgen und Datenstrukturen

Als die ersten Codezeilen für die erste Browser-Runde geschrieben wurden, existierten C # und Java nicht. Ruby auch nicht. Python war vielleicht schon da, aber es war zu diesem Zeitpunkt noch ein winziges Homebrew-Projekt.

Grundsätzlich gab es wirklich keine anderen Optionen als C ++, die es einem ermöglichen würden, einen Browser zu erstellen, der schnell ist und auf vielen verschiedenen Plattformen ausgeführt werden kann.

Warum wurden sie in C ++ geschrieben? Weil dies die einzige Sprache war, in der sie geschrieben werden konnten.

Da die Browser (z. B. HotJava, offensichtlich in Java geschrieben), die in anderen Sprachen geschrieben wurden, nie einen wesentlichen Grad an Marktakzeptanz / -durchdringung erreicht haben.

Ich kann nichts über die aktuelle Iteration (oder die jüngste - die schon seit einiger Zeit nicht mehr aktualisiert wurde) von HotJava sagen , aber als ich sie ausprobierte, schien mir die mangelnde Marktdurchdringung (zumindest für mich) äußerst einfach zu verstehen - Es war hässlich, langsam und mit einigen Webseiten nicht vereinbar. Letztendlich schien es auf einer Prämisse zu beruhen, die nie geklärt wurde: Das Web würde hauptsächlich aus Java-Applets bestehen, wobei HTML nur ein Wrapper ist, der angibt, welche Applets wo angezeigt werden sollen.

Ein Teil davon ist wahrscheinlich auch historisch: Die meisten großen Webbrowser gibt es schon lange. Als sie zum ersten Mal geschrieben wurden, war die Landschaft ganz anders: C ++ war eine "heiße" neue Sprache und wurde daher für viele neue Entwicklungen verwendet. Browser sind zu einer der am häufigsten verwendeten Software geworden, während viele andere aus dieser Zeit in Vergessenheit geraten sind.

Ich denke, die gezeigte "Haltung" der Sprache hat auch einen Effekt: C ++ (wie C davor) hat immer auf Praktikabilität und Pragmatismus Wert gelegt. Diese Grundhaltung zieht eher Programmierer an, die auch pragmatisch sind. Viele andere Sprachen legen viel mehr Wert auf Dinge wie Eleganz - und ziehen damit Programmierer an, die genauso denken. Das Problem dabei ist, was ich den "Lisp-Effekt" nenne. Die Symptome umfassen:

1. Endlose Argumente über die meisten elegante Umsetzung der banalsten Dinge.
2. Unfähigkeit, Features einzufrieren und etwas fertigzustellen, das versendet werden kann (auch bei Fehlern)
3. Unfähigkeit zu Kompromissen. Wer mit mir nicht einverstanden ist, liegt nicht nur falsch, sondern muss entweder dumm oder böse sein.

Es gibt noch mehr, aber Sie haben eine allgemeine Vorstellung (und ja, ich übertreibe bis zu einem gewissen Grad - aber nur bis zu einem gewissen Grad). Ja, ein Teil des Codes, den Sie erhalten, wird erstaunlich schön sein - aber es besteht die Möglichkeit, dass er sechs Monate zu spät ist und größtenteils nicht mit jedem anderen Teil des Codes im System kompatibel ist (was eigentlich sein soll), und wenn Sie ihn erhalten, ist er da eine ziemlich faire Chance, dass sich etwas anderes genug geändert hat, dass Sie es überhaupt nicht nutzen können.

Es gibt auch Sprachen, die zweifellos gut funktionieren würden, aber (zu Recht oder zu Unrecht) einfach nicht den Marktanteil haben (oder zum entscheidenden Zeitpunkt nicht hatten), den irgendjemand jemals in ihnen einen Browser geschrieben hätte. Angesichts der Größe und Komplexität eines vollständigen Browsers ist die Entwicklung eines Browsers mit vielen Personen und viel Zeit verbunden. Mit dieser Art von Investition werden viele Leute relativ konservativ gegenüber Dingen wie Entwicklungswerkzeugen.

Cargo-Kult-Programmierung. Die Vorstellung, dass "C ++ schnell ist", ist immer noch da draußen (trotz schlecht durchdachter Funktionen auf Sprachebene, wie das schlecht kaputte Objektmodell, das die Dinge verlangsamt), und die Leute möchten, dass ihre Browser schnell sind, also schreiben sie in C ++ .

In einer vernünftigen Welt wären Leute, die Software für Netzwerke schreiben, entsetzt über den bloßen Gedanken, eine Sprache zu verwenden, die mit allen inhärenten Sicherheitsproblemen von C behaftet ist, und tatsächlich wäre dies eine Tat der kriminellen Nachlässigkeit. (Sehen Sie sich nur an, wie viele Pufferüberlauf-Exploits in den letzten 15 Jahren bei verschiedenen Browsern aufgetreten sind. Für wie viele Millionen Dollar Schaden sind diese Codierer verantwortlich?)

Es gibt andere kompilierte Sprachen, die in der Lage sind, schnelle Binärdateien zu erstellen. Das Problem ist, dass sie nicht die gleiche Exposition haben wie die C-Familie, und wir alle müssen darunter leiden.

Wissenswertes: Als der Morris Worm 1988 ins Internet kam, demonstrierte er abschließend die Probleme beim Schreiben von Betriebssystemen und netzwerkbasierter Software in C (die bis heute nicht behoben wurden, weil sie inhärente Sprachfehler sind) Apple hatte das fortschrittlichste Betriebssystem veröffentlicht, das die Welt bisher gesehen hatte, und das bereits seit mehreren Jahren in Pascal geschrieben wurde.

Zugriff auf APIs auf Systemebene

Alle Browser müssen sich irgendwann mit dem Betriebssystem verbinden, und die meisten großen Betriebssysteme verfügen über gut etablierte C- und C ++ - APIs und -Bibliotheken. In der Regel ist es einfacher, mit diesen APIs in C oder C ++ zu arbeiten, als Wrapper zu schreiben.

Kontrolle und Portabilität

Die meisten der Geschwindigkeitsargumente können in beide Richtungen gehen, aber überall, wo Sie präzise steuern müssen, wie etwas getan wird, regnen viele der höheren Sprachen auf Ihrer Parade. Es gibt Ausnahmen, aber die meisten von ihnen sind nicht plattformübergreifend genug, um in so etwas wie einem Browser zu zählen.

Legacy-Kompatibilität - kann alten Code nicht wegwerfen

Es hat nichts mit den Vorzügen von C ++ im Vergleich zu anderen Sprachen zu tun. Sie können mit Sicherheit einen besseren Browser von Grund auf in einer Sprache wie Haskell schreiben. Ein so wichtiges Projekt könnte sogar eine eigene JVM implementieren, wenn einige Leistungsmerkmale garantiert werden müssten. Wie Facebook seinen eigenen PHP-Compiler / Optimierer geschrieben hat.

Ein Browser, der bei nicht standardmäßigen Markups nicht funktioniert, ist schlimmer als nutzlos. Legacy-Kompatibilität ist so kritisch und komplex, dass ein Umschreiben nicht in Frage kommt. Viel Geld und Zeit wird in kampferprobte Sicherheit usw. investiert. Sie können diese Investition nicht einfach wegwerfen. Wieder so, wie Facebook immer noch in PHP geschrieben ist.