WebKit nutzen statt Optimierungswettkampf

[Neugierig]

Mal eine naive Frage:

Kann Firefox nicht einfach auf die WebKit engine setzen und statt alle Ressourcen in diesen Optimierungswettkampf zu verpulvern, diese für andere Verbesserungen einsetzen?

Ich meine was ich an Firefox liebe und auch nicht missen will sind diverse Addons, bei mir: AdBlockplus, Sage RSS, Tree style Tab, Scrapbook, Read it Later und FlashBlock.
Solange es diese Addons nicht für einen anderen Browser gibt werde ich nicht umsteigen, egal wieviel die anderen schneller sind.

Würde Firefox WebKit als Engine benutzen wären sie Geschwindigkeitsmässig immer auf gleicher Höhe mit Chrome, wurden aber die besseren Addons bieten.

Also warum macht Mozilla das nicht?

[gco]

Ich denke es bringt trotz der doppelten Arbeit ein Gewinn, es ist ein wenig Demokratie, weil der User durch die Wahl des Browsers entscheidet was Wichtig ist.
WebKit könnte auch in die falsche Richtung laufen.
Konkurrenz belebt das Geschäft, es ist viel Motivierender ein guten Gegner zu haben.
Über kurz oder lang werden sich die Apis angleichen und dann wird ein Austausch vielleicht von Dritten vorgenommen, so ähnlich wie IETab in Firefox, vielleicht gibt es schon WebKitTab.

Mfg gco

[chromi]

Neugierig schrieb:
--------------------------------------------------------------------------------
> Würde Firefox WebKit als Engine benutzen wären sie Geschwindigkeitsmässig
> immer auf gleicher Höhe mit Chrome, wurden aber die besseren Addons bieten.

Das ist Falsch. Googles Chrome/Chromium nutzt zwar die Webkit-Engine zur Darstellung der Seite, aber nicht die JavaScript-Engine. Dazu wurde eigens eine Engine namens V8 Entwickelt bzw. "entwickeln lassen", welche deutlich schneller als die in Webkit ist.

[OpenBC]

Hätte, wäre, könnte, darüber nachzudenken, ist einfach müßig. Das führt zu nichts. Der Markt bietet Vielfalt und wenn ich solche News lese, lacht mein Herz. Denn hier werden neue Ansätze und Technologien gepusht, weil die Konkurrenz es fordert. Ich bin zur Zeit noch gern mit dem Iron (seit gestern Version 6) unterwegs und zufrieden. Vorher war's bei mir immer Firefox und auch der aktuelle Opera gefällt mir gut. Jeder so, wie er mag =)

[Hans Schmucker]

Es ist auch einfach eine praktische Frage. Abgesehen davon dass meiner Meinung nach Gecko die bessere (weniger Gehhacke, daher vorhersagbarer) Engine ist verfolgen die beiden auch sehr unterschiedliche Ziele. Firefox ist ganz auf die Addons ausgelegt mit einer internen Struktur die eher an eine Webseite als eine Applikation erinnert. WebKit's relativ primitives (damit portable) System würde unter der Last zusammenbrechen.

Gegen einzelne Komponenten ist aber nichts einzuwenden. Jaegermonkey verwendet den Webkit Compiler :)

[Neugierig]

gco schrieb:
--------------------------------------------------------------------------------
> Ich denke es bringt trotz der doppelten Arbeit ein Gewinn, es ist ein wenig
> Demokratie, weil der User durch die Wahl des Browsers entscheidet was
> Wichtig ist.
> WebKit könnte auch in die falsche Richtung laufen.
> Konkurrenz belebt das Geschäft, es ist viel Motivierender ein guten Gegner
> zu haben.

Ich fände es aber interessanter wenn der wettkampf bei den features, der bedienbarkeit und bei effizienterem speicherverbrauch stattfindet, als bei Optimierungen für Benchmarks, bei denen getrickst und gefrickelt wird zu lasten den Speicherverbrauchs und eines guten codes, und am Ende der User eh kein Unterschied feststellen kann.

Grüsse
Neugierig

[edud]

Speicherverbrauch ist für viele kein thema mehr. Der Speicher den der Browser selbst frisst ist eher gering als der der geladen wird.

[masterblaster]

weil Webkit in vielen Bereichen deutlich schlechter ist als Gecko ?

Warum soll man seine Zeit mit webkit verschwenden ?
(v8 ist nicht teil von webkit)

[adshiu]

Doof, dass aber Jägermonkey gerade den JS Teil von Webkit nutzt :)

[Hans Schmucker]

Nicht den, aber ein Teilchen davon. Der Ansatz ist immer noch ein komplett anderer. Jaegermonkey ist in das Tracing integriert und fungiert als Fallback für Legacy Code. Bei Webkit gibt es nur Nitro.

Nettoergebnis:
Nitro/V8 artige Systeme sind und werden bei reinem Legacy Code schneller bleiben.
TM/JM artige Systeme sind bei sauberem Code VIEL schneller.

[asdhiu]

Ja, aber trotzdem nimmt Mozilla Nitro als Fallback, obwohl der gerade oben kritisiert wurde und V8 vorgeschlagen wurde...

Was ich mich frage: Theoretisch müsste Jägermonkey dann ja in allen Fällen mindestens so schnell sein wie Nitro und in einigen deutlich schneller. Ist da noch so viel Optimierungspotenzial oder geht da durch die Prüfung welche Engine benutzt werden soll soviel flöten?

[ScooterTooter]

masterblaster schrieb:
--------------------------------------------------------------------------------
> weil Webkit in vielen Bereichen deutlich schlechter ist als Gecko ?

zB?

> Warum soll man seine Zeit mit webkit verschwenden?

Waer' einfach schoen die wahl zu haben, mit IETab geht's auch, warum nicht ein WKTab?

[Hans Schmucker]

Da geht schon ein bissl was flöten. Die Analyse braucht einfach einen Moment und einige Sachen können auch nicht ganz so effizient gemacht werden, da die Speicherstrukturen ja vom Tracer UND dem MJIT genutzt werden müssen und was für den einen optimal ist kann beim anderen nicht ganz so ideal sein. Die Basisgeschwindigkeit ist also etwas niederer (unter der Annahme, dass beide Systeme ansonnsten optimal implementiert sind). Aber wenn das Tracing funktioniert (und hoffentlich lernen die Entwickler irgendwann ihren Performance-kritischen Code so zu schreiben) kann es leicht doppelt so schnell sein wie der MJIT.

[panzi]

Das ist einfach nicht möglich. Firefox hat weit aus mehr als nur eine HTML+JavaScript Engine. Die gesamte Oberfläche von Firefox/Thunderbird/etc. ist in XUL geschrieben, und das hängt eng mit der HTML Engine zusammen. Die Ganzen Komponentenarchitektur und wie sie mit JavaScript ansprechbar ist müsste neu geschrieben werden. Noch dazu implementiert Mozilla gewisse ECMAScript Erweiterungen (siehe JavaScript Version >= 1.7), welche sonst von keinem unterstützt werden aber von Firefox+Add-Ons schon häufig genutzt werden. Eventuell werden die auch mal zum Standard, aber das ist noch nicht der Fall.

[Hans Schmucker]

SVG Filter, JS1.8, Speicherverwaltung (z.B. gibt DataURLs nicht wieder frei), schlecht integrierte Native Widgets (probier mal ein Transform auf nem iFrame)... WebKit ist primitiver und mehr zusammengehackt.

[ThorstenMUC]

Neben all den Argumenten - Konkurrenz belebt das Geschäft.

Und Webkit hat übrigens nichts mit der Javascript-Performance zu tun - die ist für das HTML-Rendern zuständig.

Die Chrome und Safari JS-Engine heißen V8 bzw. Nitro.

[masterblaster]

asdhiu schrieb:
--------------------------------------------------------------------------------
> Ja, aber trotzdem nimmt Mozilla Nitro als Fallback, obwohl der gerade oben

Mozilla nimmt nicht Nitro als Fallback sondern Jägermonkey.
JM enthält einen sehr kleinen Teil von Nitro aber das ist auch schon alles.

Wenn Mozilla Nitro als Fallback nehmen würde dann wären die Daten nitro/Mozilla gleich.

Wie man unter http://arewefastyet.com/ sehen kann sind die aber nicht gleich. Bei http://arewefastyet.com/ wird nur die JS shell getestet und die Rendering Engine ist da nicht von belang.

[dasiuasiu]

Naja, Nitro ist schon offizieller Teil von Webkit oO

[dasiuasiu]

Naja, Nitro ist schon offizieller Teil von Webkit oO

[Youssarian]

Neugierig schrieb:

> Mal eine naive Frage:

Stimmt, die ist naiv. ;-)

> Kann Firefox nicht einfach auf die WebKit engine setzen und statt alle
> Ressourcen in diesen Optimierungswettkampf zu verpulvern, diese für andere
> Verbesserungen einsetzen?

Vor wenigen Jahren hätte diese Frage lauten müssen:

Können $ALLE_ANDEREN nicht die Mozilla Engine einsetzen, statt alle Ressourcen in anscheinend längst verlorene Schlachten zu verpulvern?