Entwicklung Firefox

  • Ich weiss man sollte sich neuen Innovationen immer offen gegenüberstellen aber ich würde mich eher darüber freuen wenn sie zuerst Firefox fertig umbauen (XUL & XBL entfernen und C & C++ durch Rust Code ersetzen) und sich dann neuen Zielen widmen würden. Ich weiss aber dass das Servo Team in Mozillas Vision nicht einfach den neuen Fuchs darstellen wird weshalb ich die Entscheidung verstehen, aber nicht befürworten will.

  • Verstehe deinen Einwand nicht. Was haben denn Servo-Entwickler mit der XBL-Entfernung zu tun? An der Einbringung von Rust-Code in Firefox dagegen wird im Servo-Projekt ja sogar explizit gearbeitet.

  • Hätte Servo eine andere Priorität innerhalb von Mozilla gehabt hätte man es zu einem vollwertigen Browser umgewandelt und mittels einer harten Migration wären die User auf die neue Plattform migriert worden anstatt den Weg zu gehen und langsam voran zu gehen.
    Das Servo jetzt zum Virtual und Augmented Reality Team gehört heisst wohl dass Servo mehr diese Technologie enthält anstatt dass Servo darauf vorbereitet wird eines Tages Firefox komplett zu beerben.

    PS: Ja ich weiss dass es mehr ein Research Projekt ist und weniger darum geht Firefox zu ersetzen aber ich hatte mir halt gewünscht dass es anders gelaufen wäre.

  • Das ist ein völlig unrealistischer Wunsch. Seit Ende der 90er hat niemand mehr eine Browserengine komplett von Null neu entwickelt, nicht einmal Google hat sich da rangetraut. Für Mozilla wäre die Entwicklung einer neuen Browserengine niemals zu realisieren gewesen, mal davon abgesehen dass es jahrelang gedauert hätte und die User Firefox ohne Servo-Verbesserungen bis dahin wahrscheinlich noch mehr verlassen hätten.

    Ich wünschte auch Firefox hätte wieder 30% Marktanteil und mehr, aber Wünsche sind eben leider erstmal nur das.

  • miku23: Da muss ich Lurtz zustimmen, deine Vorstellung ist ziemlich weit von dem entfernt, was realistisch ist. Realistisch betrachtet existiert überhaupt keine andere Möglichkeit, als sinnvolle Architekturen, Konzepte und Komponenten von Servo Schritt für Schritt nach Gecko zu portieren. Servo zu einer vollwertigen Browser-Engine zu machen und dann drum herum einen kompletten Browser, vergleichbar zu Firefox, zu bauen, würde auch jetzt noch einen Aufwand von mehreren Jahren (!) bedeuten. Diese Idee ist eine Utopie. Vor allem: es ist auch sinnlos sowohl aus Mozilla- als auch aus Nutzer-Sicht, wenn Firefox bereits jetzt die guten Ideen von Servo haben kann. Firefox existiert und hat eine, wenn auch der Trend unschön ist, noch immer große Nutzerbasis. Fällt Mozilla mit Firefox, ist das gesamte Mozilla-Projekt in großer Gefahr, denn Mozilla wird fast komplett durch Firefox finanziert und was Mozilla auch außerhalb von Firefox für das Web tut, kostet Geld. Viel Geld. Das hat auch nichts mit fehlender Prioritätensetzung innerhalb von Mozilla zu tun. Ganz im Gegenteil: Mozilla investiert sogar ziemlich viel in Servo und auch das Rust-Ökosystem. Mozilla hat definitiv nicht die Zeit, so wichtige Verbesserungen, die jetzt Einzug in Firefox erhalten können, noch Jahre zurückzuhalten, nur weil es keinen Servo-Browser gibt. Und ein komplett neues Produkt kommt sowieso nicht in Frage. Dieses Produkt hätte noch überhaupt keine Nutzerbasis. Und eine Konkurrenz zu Firefox im eigenen Haus bei den eh schon sinkendenn Marktanteilen: ganz schlechte Idee.

    Ebenfalls wichtig zu verstehen ist, dass Firefox und Servo grundsätzlich erst einmal überhaupt nichts miteinander zu tun haben. Wie Lurtz schon sagte: Dinge wie die XBL-Entfernung aus Firefox haben wirklich gar nichts mit Servo zu tun. Das sind komplett andere Teams, ja sogar andere Produkte / Produktkomponenten (Browser-Engine Servo vs. Frontend von Firefox). Mehr Ressourcen für Servo beschleunigen an der XBL-Entfernung exakt gar nichts.

    Auch sollte man sich darüber im Klaren sein, dass Servo anders funktioniert als Gecko. Gecko ist ganz klar eine Komponente, die innerhalb von Mozilla entwickelt wird. Aber wieso ist beispielsweise nicht Mozilla der Eigentümer der Git-Repositories von Servo, sondern ein Servo-Projekt? Wieso gibt es weder seitens Rust noch Servo irgendein Mozilla-Branding? Ich denke, dass man es an solchen Details gut erkennt. Hier wurden ganz bewusst eigenständige Communities aufgebaut. Klar trägt Mozilla sehr viel zu diesen Projekten bei, sei es finanziell, Infrastruktur und natürlich Mitarbeiter. Aber Rust und Servo gehen weit über Mozilla hinaus. Auch Samsung hat beispielsweise früh schon schon einige Ressourcen in Servo investiert. Die Servo-Community schaut, dass sie die Anforderungen von Mozilla erfüllt, weil eine Integration von deren Komponenten in Firefox natürlich die beste Referenz und vor allem Beweis ist, dass die Konzepte funktionieren. Theorie ist das eine, Anwendung in einem Browser mit so vielen Millionen Nutzern noch einmal etwas vollkommen anderes. Dementsprechend geben die Ziele von Mozilla auch ein großes Stück vor, was die Ziele von Servo sind. Nichtsdestominder darf man nicht vergessen, dass Servo nicht nur eine Komponente für Firefox ist, sondern weit darüber hinaus geht. Servo soll Technologien über Firefox hinaus liefern. Und das ist letztlich auch Mozillas Ziel, denn für Mozilla geht es um das Web im Gesamten.

  • Ich weiss, ich weiss mein Wunsch ist unrealistisch aber dafür sind ja Träume da :)

    Nein ganz im Ernst; was ich mit meinem ganz ersten Beitrag eigentlich sagen wollte ist dass ich es schade finde dass ein neuer Fokus (und das passiert mit dem Wechsel der Organisation ganz sicher) auf VR und AR gelegt wird, anstatt zuerst die Technologie fertig zu bauen. Dahinter verbirgt sich natürlich auch noch meine persönliche Abneigung gegen VR und AR da ich nicht glaube dass die Technologie jemals so wichtig wird das es sich lohnt darin zu investieren. Aber hey, vielleicht liege ich ja falsch :)

  • VR/AR ist eine große Sache. Der Zug, dass es anders kommen wird, ist bereits abgefahren. ;) Software-Unternehmen wie Facebook oder Hardware-Unternehmen wie HTC tätigen Investitionen im Milliarden (!)-Bereich. Ich erlebe es übrigens hautnah, wie real das ganze Thema ist. Ich nehme ja selbst, wie jeder gute Entwickler, ab und an an Konferenzen teil, um auf dem aktuellen Stand zu bleiben. Auf der Entwickler-Messe, bei der ich letzte Woche war, sowie auf dem Barcamp tags zuvor war VR ein Riesen-Thema, vor einigen Monaten war ich auf einem Sport- & Tourismus-Event (meine Kunden sind vorrangig Hotels und Sport-Brands) und selbst für diese Zielgruppen ist VR ein Thema, mit dem sich mittlerweile ernsthaft auseinandergesetzt wird.

    Mozilla ist gut damit beraten, diese Entwicklung (es ist nicht mehr nur ein Trend!) nicht zu verschlafen, sondern ganz im Gegenteil im Software-Bereich ganz vorne mitzumischen. Denn es ist vollkommen klar, dass klassische Desktop-Browser, wie wir sie heute nutzen, nicht für immer das wichtigste Produkt für den Konsumenten bleiben werden. Wenn Mozilla in ein paar Jahren nur Firefox als einziges starkes Produkt auf dem Markt positioniert hat, dann heißt es >Tschüss Mozilla<. Wir hatten es bereits mit dem Thema Smartphones, dass Mozilla viel zu spät dran war, und wie bedeutungslos Mozilla nun im mobilen Segment ist, dürfte bekannt sein. Mozillas Marktanteile gehen mobil schlicht und ergreifend gegen nicht-existent. Den Fehler sollte Mozilla also nicht wiederholen.

    Firefox war übrigens der erste Desktop-Browser mit VR-Unterstützung, Mozillas Software A-Frame (https://aframe.io/) macht sich ebenfalls sehr gut, wird bereits von Größen wie Washington Post und Amnesty International eingesetzt, man hat eine eigene VR-Abteilung (https://vr.mozilla.org/), man ist ganz aktiv an der Entwicklung der entsprechenden Webstandards beteiligt. Also VR/AR ist bereits ein Schwerpunkt für Mozilla neben anderen Dingen wie Internet of Things (https://iot.mozilla.org/about/) oder auch Lösungen für Spracherkennung (https://blog.mozilla.org/blog/2017/11/2…-voice-dataset/) und Sprach-Datenbanken (https://voice.mozilla.org/), wie sie im Internet of Things benötigt werden. Also das ist ganz wichtig, dass man erkennt, dass Firefox nicht alles ist. Nicht, wenn man in zehn Jahren noch existieren will. Persönliche Abneigungen müssen hinten anstehen. Es geht hierbei ganz schlicht um die Daseinsberechtigung von Mozilla, auch in ein paar Jahren noch. ;)

  • Damit das ganze jetzt hier nicht noch zu Off-Topic wird schlage ich vor wir setzen uns in fünf Jahren an einen Tisch und schauen wie wichtig die Technik im Browser-Leben (noch) ist und belassen den Thread wofür es gedacht ist; Innovationen von neuen Builds und den zukünftigen zu besprechen.

  • Ergibt es Sinn, das schon in FF 60 zu aktivieren? Oder hat es dort keine Wirkung? :)


    Doch, das ist schon lange funktional. Allerdings hat es zwischendurch für so große Probleme gesorgt, dass sie es erst in Nightly 61 wieder standardmäßig aktivieren wollten.
    Auf schnellen Rechnern merkt man allerdings kaum einen Unterschied, auf langsameren durchaus.

  • So ist jetzt auch bei 61a1 und wie jede neue version immer per setup in neues verzichnis.
    Mal schauen wie lange der Hardwarebeschleuniger jetzt läuft, bei mir. ;)
    Neue funktionen und Änderungs liste noch nicht verfügbar. ;(

    PS: Nur noch auf Thunderbird 61a1 warten muss. ^^

    Windows 10 Enterprise 1809 17751.1 x64 (Fast)RTM. Firefox 63a1, ThunderBird 60 relase, MS Office 365 Personal Abo x64, Nicht vorhandene Viren Per Norton Security Premium v22.14.2.13 Killen. Es Grüßt ein Glücklicher NUR noch 64bit Kompatibler Marc Senn
    Ich Liebe dich Traumfrau Carla.

    Meine WebExtensions Addons

  • Du bist dir aber schon bewusst dass die Nightly Builds andauernd und täglich neue Funktionen erhalten und deswegen die Nummer nicht ganz so viel Gewicht hat wie bei der Beta? Sprich es ist nicht so dass sobald eine neue Nightly rauskommt die Entwickler gleich 10 neue Funktionen haben.

  • Seid ihr hier eigentlich an der Entwicklung direkt mit beteiligt oder leistet ihr nur den ehrenamtlichen Support mit dem, was man euch vorsetzt?
    Die Frage hat als Hintergrund, dass ich mir vorstellen könnte, den (deutschen) Fux zu unterstützen, allerdings nicht hinsichtlich programmiertechnischer Details, sondern aus eher wahrnehmungs-und bedienpsychologischer Sicht, sprich Usability-Unterstützung.