Firefox: Entwickler-Werkzeuge sollen optional werden
Die Entwickler-Werkzeuge von Firefox wurden in den letzten Jahren immer mächtiger und machen Erweiterungen wie Firebug mittlerweile überflüssig. Mozilla plant nun die Auslagerung als System-Add-on, um Verbesserungen noch schneller an die Nutzer ausliefern zu können. Außerdem sollen die Entwickler-Werkzeuge optional gemacht werden, so dass diese erst auf den ausdrücklichen Wunsch des Nutzers hin aktiviert werden.
Als Teil des Go Faster-Programms entkoppelt Mozilla einzelne Funktionen vom Firefox-Core und integriert diese als gebündelte Add-ons. Dadurch können Verbesserungen unabhängig von regulären Firefox-Updates ausgeliefert werden. Eine komplette Übersicht überalle bisherigen System-Add-ons von Firefox gibt es hier.
Ganz in diesem Sinne möchte Mozilla nun auch die Entwickler-Werkzeuge vom Firefox-Core entkoppeln und in Form eines System-Add-ons ausliefern. Die Haupt-Motivation ist auch hier wieder die Möglichkeit, Verbesserungen für die Nutzer, in dem Fall Entwickler von Webseiten, schneller ausliefern zu können und nicht an den Release-Zyklus von Firefox gebunden zu sein.
Während die meisten System-Add-ons nicht einfach per Oberfläche deaktivierbar sind (de facto ist dies ausschließlich Pocket), möchte Mozilla die Entwickler-Werkzeuge für den Nutzer optional machen, so dass diese erst auf den Wunsch des Nutzers hin aktiviert werden. Die genauen Details, wie die Integration aussehen soll, befinden sich noch in der Diskussion. Sicher ist bisher nur, dass man die Aktivierung so leicht wie möglich machen möchte. Vorbilder sind hier Apple mit Safari und Microsoft mit Edge. So ist es beispielsweise denkbar, dass Firefox auch bei deaktivierten Entwickler-Werkzeugen auf wichtige Tastenkombinationen der Entwickler-Werkzeuge reagiert, um den Nutzer zu fragen, ob die Entwickler-Werkzeuge aktiviert werden sollen.
Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, firefoxosdevices.org sowie sozone.de.
Warum sollen die Entwicklerwerkzeuge optional sein, Pocket aber nicht?
Finde ich begrüßenswert, vielleicht werden dann die "Firefox ist Bloatware"-Schreier mal leiser.
Ich hoffe die nur peripher zum Thema passende Frage ist gestattet: Wann wird Firefox eigentlich endlich eine multithreaded JavaScript-Runtime bekommen? Komplexes Javascript kann immer noch den ganzen Browser lahmlegen.
Überhaupt hat man das Gefühl, dass bei JavaScript kaum was passiert bei Mozilla :/ Der letzte Blogeintrag ist von Anfang Juli. Bei V8 gibts locker vier Einträge pro Monat, von denen sich zwei mit Performance befassen.
Laut diesem V8-Blogpost kommt der [URL="http://browserbench.org/Speedometer/"%5DSpedometer-Test%5B/URL%5D den Anforderungen realer Websites momentan am nächsten, wenn auch nicht nah genug:
[url]https://v8project.blogspot.de/2016/12/how-v8-measures-real-world-performance.html[/url]
Da ist Firefox chancenlos. 24 Runs/Minute, Chromium kommt auf 68 Runs/Minute auf einem i5 6200U. Auf einem 6700k wirds noch viel krasser. Chromium 140/Minute, Firefox 48/Minute.
Man muss auch mal sagen, dass Mozilla hier alles richtig macht. Oft wurde kritisiert Firefox würde zu einem Chromeklon werden. Man hat sich nun auf eine Stärke, die Erweiterungen, zurück besonnen und verwendet diese im Firefox Grundaufbau. Endlich weg von der eierlegenden Wollmilchsau.
Ich denke mit der Multiprozess-Architektur wird er besser den je.
Jetzt muss nur noch FirefoxOS wiederbelebt werden. 😛
@Korodny:
Du hast den Artikel aber schon gelesen, oder? Ich frage, weil ich Pocket explizit erwähnt habe und Pocket eben sehr wohl per Oberfläche deaktivierbar ist. Das ist längst Realität, während optionale Entwickler-Werkzeuge bislang nur eine Planung sind.
@blub:
Vermutlich nicht, solche Schreier schreien nur, wenn sie einen Anlass sehen, und sind ganz leise, wenn es keinen Grund zum Schreien gibt. 😉
Zunächst einmal ist JavaScript grundsätzlich single-threaded. Das ist die Natur von JavaScript. Parallelisierung ist möglich via Web Workers. Die Unterstützt Firefox:
https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
"Basis Support" sogar schon seit Firefox 3.5. Was genau vermisst du?
Das kann man kaum anhand von Blog-Einträgen bewerten. Zumal man sehr viele Blogs verfolgen müsste, um die Beiträge aller Entwickler mitzubekommen.
Die Aussage, man hätte das Gefühl, bei JavaScript würde bei Mozilla kaum was passieren, kann ich in jedem Fall überhaupt nicht nachvollziehen. Gerade JavaScript ist eine der großen Stärken von Mozilla. Innovationen wie asm.js sind Erfindungen von Mozilla, alle anderen Browserhersteller sind nachgezogen. Auch bei der Implementierung neuer ECMAScript-Features ist Mozilla ganz vorne dabei. Mozilla war es außerdem, die mit Entwicklern von Spiele-Engines wie Unreal zusammengearbeitet haben, um richtige Spiele-Engines für den Browser zu portieren – das wäre vor wenigen Jahren noch vollkommen unvorstellbar gewesen.
Benchmarks sind grundsätzlich mit Vorsicht zu genießen. Jeder Benchmark zeigt nur genau das, was abgebildet werden soll. Mozilla hat auch seinen eigenen JavaScript-Benchmark, Kraken. Der bildet nach Mozillas Ansicht die Realität am besten ab. Und dort sind die Ergebnisse ganz anders. Die Testcases von Kraken basieren übrigens auf echten Anwendungen und echten Bibliotheken, Kraken ist also im Gegensatz zu den meisten Benchmarks wirklich realitätsnah und nicht nur theoretisch. Im Google-Benchmark ist Chrome vorne, im Microsoft-Benchmark ist Edge vorne. Also das zeigt wirklich nur, dass alle Browser Bereiche haben, in denen sie besonders glänzen.
Ich muss blub leider zustimmen. Ich arbeite an sehr JavaScript-lastigen Webprojekten und ich kann zur Entwicklung Firefox teilweise einfach nicht verwenden, da dieser leider einfach lahm ist. Ich weiß nicht warum und es geht da nicht um 5 oder 10 % längere Wartezeiten. Gefühlt ist Chrome doppelt so schnell und das seit vielen Jahren.
Es tut mir leid und ich nutze Firefox trotz seiner Langsamkeit trotzdem als Haupt-Browser, aber er ist einfach im täglichen Einsatz merklich langsamer als Chrome. Ob die Benchmarks das zeigen oder nicht ist mir auch egal, im Alltag merkt man das.
Seine Aussage war "dass bei JavaScript kaum was passiert bei Mozilla" und das kann man über Mozilla auf gar keinen Fall sagen, siehe meine Ausführungen. Geschwindigkeit ist nur ein Aspekt, der unter diese Aussage fällt. Wobei es für mich nicht nachvollziehbar bleibt. Benchmarks interessieren mich nur eingeschränkt, weil Benchmarks nicht mehr als Machbarkeitsstudien sind, mich interessiert die Realität, Anwendungen, die ich nutze. Zumal wie gesagt in manchen Benchmacks Chrome vorne ist, in anderen Firefox, in anderen Edge, in anderen Safari.
Und seit ich Firefox nutze, hatte ich noch nie Performance-Probleme irgendeiner Art. Ich hatte auch nie schlechte Hardware, also Leistung war immer vorhanden. Auf verschiedensten Geräten.
Aussagen wie "Gefühlt ist Chrome doppelt so schnell und das seit vielen Jahren" betrachte ich daher immer sehr skeptisch. Die meisten Anwendungen (und nochmal: um Benchmarks sollte es hier bitte nicht gehen) sind so schnell, dass so große Geschwindigkeitsunterschiede gar nicht möglich sind. Und stellt es sich wirklich so dar, dann würde ich überprüfen, was mit der Firefox-Installation nicht stimmt. Denn das ist auf gar keinen Fall normal. Gerade die Aussage, es wäre seit Jahren so, unterstreicht das, dass irgendwas nicht stimmen kann. Denn auch Performance-mäßig hat Mozilla in den letzten Jahren richtig Gas gegeben. Ich wiederhole mein Beispiel asm.js, in dem Bereich hatte Mozilla ausnahmslos alle anderen Browser meilenweit (!) abgehängt, bis diese Mozillas Innovation angenommen und ihren eigenen Compiler implementiert haben, dort sind andere Browser mittlerweile gleichwertig. Also selbst wenn wir jetzt davon ausgehen, dass andere Browser bei asm.js sogar schneller als Firefox wären, kann die Aussage, Firefox wäre seit Jahren langsamer und das auch noch doppelt so viel einfach nicht sein.
Wie gesagt: Mich interessieren die Benchmark-Ergebnisse nicht.
Klick dich einfach mal auf solchen Seiten durch: https://material.angularjs.org/latest/demo/datepicker. Schau dir zum Beispiel den datepicker an und die Verzögerung die beim Firefox auftritt und beim Chrome nicht. Das Ruckeln beim Navigieren im Menü links etc.
Das Ganze habe ich mittlerweile mit x Firefox-Installationen auf verschiedenen Rechnern nachstellen können. Das ist weder Fehlkonfiguration noch sonst ein Problem. Möglicherweise tritt das ja nicht mit allen Rechnern so extrem auf, vielleicht hängt das auch von der Hardware ab. Ich wollte nur sagen, dass auf jedem getesteten Gerät das mir die letzten Jahre in die Hände kam, Chrome spürbar (wie gesagt, nicht ein paar Prozentpunke) flotter bei der täglichen Nutzung war.
Dazu kommt noch, dass Chrome Seiten generell schneller lädt. Woran das hängt, weiß ich auch nicht. Aber es ist schon beeindruckend wie groß die Unterschiede sein können.
Wie ich es nicht anders erwartet hatte: nicht die geringste Verzögerung oder Ruckeln feststellbar. Damit ist klar, dass wir hier von keinem allgemeinen Firefox-Problem sprechen können.
Find ich wie gesagt komisch, weil ich wie gesagt auch noch nie auf einem meiner Systeme Performance-Probleme hatte.
Kann ich absolut nicht bestätigen…
Ich vermisse das: https://www.google.com/googlebooks/chrome/big_04.html
Seit seinem Release vor fast neun Jahren bekommt jeder Tab in Chromium seinen eigenen Javascript-Thread, der unabhängig von anderen Tabs läuft.
Bei Firefox läuft trotz e10s immer noch alles Javascript zusammen. Wer mal einen Worst Case offen hat, gerade bei Web Applications, merkt sofort, dass andere offene Seiten auch betroffen sind.
Immerhin scheint Mozilla mittlerweile was tun zu wollen: https://bugzilla.mozilla.org/show_bug.cgi?id=1323066
Ich finde es nur schwer nachvollziehbar, wieso an einem so wichtigen Thema erst Ende 2016 gearbeitet wird 🙁
Wenn du bessere/mehr Quellen hast, bin ich gerne bereit diese zu studieren. Es ist nur sehr auffällig, wenn auf dem offiziellen Mozilla-Blog zu Javascript nichts passiert, während V8 alle paar Wochen von neuen Optimierungen berichtet.
Es ging mir dabei vor allem um die Performance von Javascript in Firefox selbst. Gerade da Mozilla so sehr auf Javascript setzt.
Das tut der Speedometer doch auch, wahrscheinlich noch mehr als Kraken. Das V8-Team hat ihn auf seine Ähnlichkeit mit einer Top20-Auswahl von Seiten im Web verglichen: https://2.bp.blogspot.com/-T6jYRcJVf94/WFqHAbRLVFI/AAAAAAAAByE/5go6iT2g02os4MtY4xs_4pV80aV_V33HACLcB/s1600/startup_distribution.png
Auch bei Kraken ist Chrome hier schneller, wenn auch nicht so drastisch.
Allgemein merkt man, dass Firefox immer noch sehr viel CPU-Power braucht. Von meinem i5 6200U zu meinem i7 6700k ist es ein großer Unterschied – nur haben die meisten nicht mehr so starke CPUs. Aber auch da gibt es Fälle, wo Chrome einfach merklich schneller ist. Wobei es die fairerweise auch andersherum gibt, nur seltener.
Das wiederum macht hier gar keine Probleme. Die Animation ist beim Firefox anders, aber es öffnet sich alles genauso schnell. Wobei ein i5 6200U natürlich auch keine langsame CPU ist. Da gibt es viel schlimmere Anwendungsfälle.
IMO ist immer noch die Performance über Tabs hinweg das große Problem von Firefox. e10s mit überhaupt nur zwei Contentprozessen steckt noch in der Alpha, und selbst dann sind Dinge wie Javascript nicht auf dem gleichen Multithreading-Level wie bei Chromium.
Ich glaube vor dem Neuaufbau mit Project Quantum wird das auch nichts mehr, dafür schleppt Firefox wohl zu viele Altlasten mit sich rum. Der Realität, dass die meisten modernen Geräte, auf denen Webinhalte laufen, wenig Singlecore-Performance, dafür aber viele Cores/Threads haben, kann Firefox nach wie vor nur bedingt gerecht werden.
Nur schläft Google halt auch nicht und verbessert die Technik permanent.
Das ist irreführend. Du hast von Threads gesprochen und sprichst auch hier von Threads, dort geht es aber um Prozesse. Prozesse und Threads sind nicht das Gleiche! Es bestehen wesentliche Unterschiede zwischen Prozessen und Threads.
Und wie vielleicht bekannt ist, findet erst seit kurzem überhaupt eine Ausrollung der Multiprozess-Architektur in Firefox statt, das war bislang also technisch überhaupt nicht möglich. Und wie vielleicht auch bekannt ist, stellt die Multiprozess-Architektur den größten Umbau von Firefox in der Geschichte von Firefox dar. Für Google war das damals viel einfacher. Chrome erschien erst Jahre nach Firefox und man hat viel von Firefox gelernt. Man konnte Chrome von Anfang an so bauen und musste keine Rücksicht auf Add-ons nehmen. Man kann sich vorstellen, wie Mozillas mächtiges Erweiterungs-System – und damit meine ich in erster Linie nicht das SDK und schon gar nicht WebExtensions – den gesamten Umbau erschwert und in die Länge zieht.
Noch ist Firefox an dem Punkt, an dem es neben dem Plugin-Container und dem Browser-Prozess einen einzelnen Content-Prozess gibt. Weitere Content-Prozesse und Prozesse für andere Dinge, beispielsweise ein GPU-Prozess, sind erst im Kommen. Und möchte man verschiedene JavaScript-Prozesse, wird das auch erst in Zukunft technisch überhaupt möglich sein.
Mozilla hat nicht einmal im Ansatz die Ressourcen wie Google, das betrifft nicht nur die Entwicklung, sondern vor allem auch das Marketing.
Meine Liste von Quellen zu veröffentlichen, wäre ein bisschen lang, ich prüfe täglich mehr als 100 Webseiten. Viele Links bekomme ich auch über Twitter mit, wo ich derzeit 265 Leuten folge.
Es ist aber auch nicht so, dass es jeden Tag überall was Spannendes zu lesen geben würde. Wenn ein Entwickler an etwas arbeitet und entscheidet, darüber zu schreiben, dann passiert das vermutlich auf seinem eigenen Blog. Und dann kann es auch gut sein, dass vom gleichen Mensch zwei Jahre kein weiterer Artikel erscheint. Man kann also nicht unbedingt sagen, dass ein bestimmter Blog eine generell gute Quelle wäre, auch wenn ein einzelner Artikel wirklich super und informativ ist.
In welchen realen Anwendungen gibt es deutliche Unterschiede?
Welche Performance über Tabs hinweg? Ich frage, weil ich keine Probleme spüre (Nightly-Version von Firefox 53). Und ich arbeite als Webentwickler, das heißt, ich verbringe jeden Tag mindestens acht Stunden im Browser, eher mehr.
Altlasten sind immer ein Problem. Siehe mein erster Abschnitt in diesem Kommentar. Klar ist es einfacher, etwas neu zu machen, ohne Rücksicht auf irgendetwas nehmen zu müssen.
Wenn es darum geht, modernen Geräten und deren Hardware gerecht zu werden, dann trifft das auf ausnahmslos alle aktuellen Browser-Engines zu, inklusive der von Google. All diese Architekturen stammen aus der ungefähr gleichen Zeit, unabhängig von den inkrementellen Verbesserungen seit dem. Moderne Hardware komplett auszunutzen ist nur mit einer völlig neu entwickelten Engine möglich, wie es Mozilla mit Servo macht. Aber Servo als Komplett-Ersatz für Gecko wird nicht vor in ein paar Jahren möglich sein. Daher liefert Quantum den Ansatz, einzelne Teile, die im Rahmen von Servo erforscht werden, vorab in Gecko zu integrieren.
Das stimmt, da habe ich zu unpräzise formuliert.
Ja, aber das ist eben schon ein Punkt, wo man klar feststellen kann, dass es über die letzten Jahre durchaus gewichtige Unterschiede zwischen Firefox und Chrome gab.
Dafür hat Chrome eben auch Extensions, mit denen man nicht mal eine vernünftige Sidebar oder mehr als simpelstes Tabmanagement hinbekommt.
Die Frage, was am Ende bei der täglichen Arbeit störender ist, muss wohl jeder selbst beanworten.
Fällt der V8-Blog schon unter Marketing?
Falls du Teile davon teilen möchtest, würde ich mich freuen falls du mir die per Email zukommen lassen könntest, die siehst du als Admin ja sicher.
Was für einen Anwender real und deutlich ist, schwankt meiner Erfahrung nach sehr stark. Für den einen sind sekundenlange Wartezeiten völlig normal, der andere merkt schon Verzögerungen im hohen ms-Bereich.
Ich finde es gibt durchaus Unterschiede, auch messbare, beim Laden von Seiten, vor allem wenn viele Tabs gleichzeitig laden oder bei Benutzung parallel stark javascriptlastiger Seiten. Kann man auf die Spitze treiben wenn man bspw. lesen.amazon.de nutzt und sich dann auf Facebook bewegt.
Sind nicht gerade viele Webentwickler zu Chrome abgewandert? Unter anderem wegen der Verbreitung und der zu Beginn wohl noch deutlich besseren Entwicklungstools?
Das ist grundsätzlich sicher richtig, allein das Thema Hardwarebeschleunigung ist ein ätzendes, man muss sich nur mal die ganzen Workarounds und Fehlermeldungen in chrome://gpu anschauen.
Ich bin mir aber sicher auch Google hat ein Project Quantum laufen, auch wenn sie die Erkenntnisse vielleicht anders in Chrome integrieren.
Ja, die Multiprozess-Architektur ist ein gewichtiger Unterschied. Deren Vorteil liegt aber grundsätzlich erst einmal mehr im Bereich Stabilität und Sicherheit, weniger im Bereich Performance. Tendenziell bedeutet eine Multiprozess-Architektur schließlich, dass mehr Daten bewegt werden müssen, ist also eher ein Performance-Nachteil. Dazu der RAM-Overhead, der ab einem gewissen Punkt ebenso Leistungseinbrüche zur Folge haben kann. Der Performance-Nachteil wird am Ende natürlich wieder durch andere Optimierungen ausgeglichen, so dass der Anwender im Idealfall keinen Nachteil spürt. Und vielleicht helfen andere Optimierungen sogar, den Browser noch performanter zu machen. Was ich damit sagen will: Performance wird nicht wirklich durch die Multiprozess-Architektur erreicht, dafür sind andere Faktoren viel wichtiger. Und dir ging es ja um die Performance.
Es ist übrigens vor allem auch eine Verantwortung der Webseite, dass diese performant läuft. Man kann selbst aufwändige 3D-Shooter mit Unreal-Engine flüssig im Browser darstellen. Wenn eine weniger komplexe Anwendung als das also Probleme hat, ist sie möglicherweise einfach nicht gut entwickelt worden. Das ist auch immer eine Option.
Natürlich, auch hier wieder der Idealfall: der Browser kann Programmierdefizite ausgleichen. So gesehen mag eine nicht performant programmierte Anwendung in einem Browser trotzdem flüssig sein, in einem anderen vielleicht weniger. Aber dass Chrome grundsätzlich schneller sei oder Firefox, das kann man definitiv nicht sagen. Beide verwenden unterschiedliche Engines und beide haben ihre eigenen Stärken und Schwächen und dementsprechend glänzen sowohl Chrome als auch Firefox teilweise in anderen Szenarien, genauso wie es für beide Browser Szenarien gibt, wo sich Probleme offenbaren. Es entspricht einfach nicht den Tatsachen, dass Chrome grundsätzlich performanter sei.
Dass in Chrome keine Sidebars möglich sind, ist schade. Aber vielleicht kommt das ja irgendwann. Opera besitzt nämlich eine Sidebar-API und Mozilla arbeitet derzeit an einer für die WebExtensions, welche weitestgehend API-kompatibel zu der von Opera sein wird. Kompatibilität mit zwei anderen Browsern ist kein so schlechtes Argument, die Entscheidung gegen Sidebars (die ja bewusst so getroffen wurde) vielleicht in Zukunft zu überdenken.
Du kannst davon ausgehen, dass wenn ein Firmen-Blog permanent mit Inhalten befüllt wird, jemand bezahlt wird (selbst wenn nicht explizit für den Artikel, sondern das Teil des Jobs ist) und das nicht in seiner Freizeit macht. Und Verbesserungen regelmäßig an einem zentralen Ort zu kommunizieren, fällt für mich in jedem Fall unter Marketing.
Ich kann dir einen aktuellen Stand zukommen lassen. Aber es kommen immer wieder Seiten dazu oder werden gelöscht.
Ich hatte wie gesagt noch nie nennenswerte Performance-Probleme. Und intensive Seiten wie Facebook, Twitter, Google Plus, WhatsApp und mehrere Google Drive-Dokumente sind permanent, das heißt 24/7, als angepinnte Tabs offen und werden nie geschlossen. Das sind sehr stark javascript-lastige Seiten.
Irgendwann war das sicher mal ein Thema, Firefox war sehr spät dabei, Entwickler-Werkzeuge zu integrieren. Mittlerweile sind diese extre mächtig. Mittlerweile ist es, sofern man nicht auf spezifische Features des einen oder des anderen Browsers angewiesen ist, in erster Linie eine Geschmacksfrage. Ich sehe permanent Entwickler, die kommunzieren, von Firefox zu Chrome oder umgekehrt von Chrome zu Firefox zu wechseln. Das ist ziemlich 50:50 von dem, was ich unter anderem per Twitter und anderen Quellen mitbekomme.
Firefox hat übrigens auch den Vorteil, dass man mittels Entwickler-Werkzeuge nicht nur Firefox debuggen kann, sondern Thunderbird, SeaMonkey, Chrome, und sogar Safari auf iOS. Für alles die gleichen Entwicklerwerkzeuge zu haben, ist kein so schwaches Argument.
Davon kann Mozilla ein Lied singen. 😉
Vielleicht. Vielleicht arbeitet Google ja auch im Geheimen an einer komplett neuen Engine. So kommunikativ Google vielleicht auf dem genannten v8-Blog sein mag, insgesamt verhält sich Google eher bedeckt mit Vorab-Kommunikation, verglichen mit Mozilla. Ist halt eine andere Philosophie. Chrome ist ja auch kein Open Source (große Teile als Chromium, ja, aber macht halt einen Unterschied in der Philosophie).
Hab eine E-Mail gesendet. Die Meldung des Server lässt allerdings vermuten, dass es nicht geklappt hat. :/
Action: failed
Status: 5.0.0
Remote-MTA: dns; mx00.emig.gmx.net
Diagnostic-Code: smtp; 550-Requested action not taken: mailbox unavailable 550
invalid DNS MX or A/AAAA resource record
Nachdem Chrome ja gerade auch eine kleine Schlankheitskur durchmacht und ein Entwickler da zuletzt mal wieder eine Absage zu Sidebars gemacht hat, wird das auf absehbare Zeit wohl leider nichts.
Google ist eigentlich immer nur kommunikativ, wenn es ihnen nutzt 🙂 Sprich wenn sie einen Weg gefunden haben, eine vordergründig offene Lösung dennoch als Datenlieferant zu missbrauchen. Sorry für den zynischen Blick, aber das ganze AMP-Projekt, von dem Google sogar träumt, dass es ein Webstandard werden soll, halte ich dahingehend schon wieder für hochproblematisch.
Aber geschickt machen sie das, dagegen waren die Versuche von Microsoft, das Internet Anfang der 2000er zu kontrollieren, deutlich plumper.
Hm, seltsam. @gmx.de ist definitiv die richtige Adresse. Kann ich dir meine Adresse auf anderem Weg zukommen lassen?
Sorry, das war blöd formuliert. Lass es mich anders ausdrücken:
Warum ist Pocket per Default aktiviert, die Entwicklerwerkzeuge aber nicht?
Da man ja angeblich aus der Poket-Integration keinen finanziellen Nutzen zieht, ist mir diese ganze Geschichte immer noch ein Rätsel. Jetzt muss der Nutzer bei einer Neuinstallation Pocket ausdrücklich deaktivieren, und die Entwicklerwerkzeuge ausdrücklich aktivieren. Ich persönlich finde, hier läuft was falsch.
Sie sollen beide per Default aktivieren, oder beide deaktivieren. Einen proprietären Dienst so zu pushen ohne dafür eine vernünftige Erklärung anzubieten ("we love Pocket") ist m.E. unwürdig.
Nicht unbedingt. Ich war ja auch klar dagegen, dass die Dev Tools fix drin sind.
Deshalb sage ich jetzt. Gute Entscheidung, ganz eindeutig.
Ich verstehe nicht, was das eine mit dem anderen zu tun haben soll. Für beide Dinge stellen sich jeweils ganz eigene Fragen.
Kannst du beispielsweise versehentlich mit Pocket interagieren, wenn du eine falsche Tastenkombination drückst? Und wer wird angesprochen? Mit den Entwickler-Werkzeugen, logisch, Entwickler. Mit Pocket potentiell jeder Nutzer. Ob man nun selbst Pocket nutzt, steht auf einem anderen Blatt Papier, aber es handelt sich um ein Feature, welches grundsätzlich für jeden in Frage kommt und nicht im Vorhinein seitens Mozilla ausgeschlossen werden kann. Und die 20 Millionen Nutzer, die Pocket hat, sind ja nun auch nicht so wenige.
Ich verstehe auch nicht, was genau dir ein Rätsel ist. Du sprichst über Pocket, also gehe ich davon aus, dass du weißt, was Pocket ist. Dort kannst du Webseiten ablegen, um sie später zu lesen. Braucht längst nicht jeder, ergibt grundsätzlich aber definitiv Sinn in einem Browser. Und das wie gesagt unabhängig davon, ob du Webentwickler, Klempner oder Arzt bist.
Ich sehe nicht, wieso die Entscheidung in der einen Sache in irgendeiner Weise Einfluss auf die Entscheidung in der anderen Sache haben sollte. Ganz im Gegenteil, es wäre komplett sinnlos, das eine vom anderen abhängig zu machen, weil beides einfach nichts miteinander zu tun hat.
Proprietär bedeutet übrigens nicht grundsätzlich schlecht. Du nutzt mit Sicherheit auch irgendwelche proprietäre Software. Und eine Erklärung braucht es ganz sicher nicht, wenn man den Browser um etwas erweitert, was Sinn in einem Browser ergibt.
Abgesehen davon gab es übrigens damals eine Erklärung, weil Mozilla vorher ja an einem Leselisten-Feature für Firefox gearbeitet hatte, was durch die Pocket-Integration obsolet wurde. Es hat für Mozilla ganz einfach mehr Sinn ergeben, auf eine bestehende Lösung zu setzen, die bereits etabliert ist, Nutzer hat und auf allen denkbaren Plattformen genutzt werden kann, als einen eigenen Dienst aufzusetzen.
@Tom:
Was nur einfach nur klar dagegen oder auch ein lauter Schreier? 😀
@blub:
Ich habe die Mail gestern nochmal von einer anderen E-Mail-Adresse aus versendet, da gab es keine Meldung. Das verstehe ich nicht, denn von der ursprünglichen Adresse aus konnte ich an eine andere E-Mail-Adresse erfolgreich senden.
Wie auch immer, ist es angekommen?
Mir erschließt sich noch nicht ganz, was das standardmäßige Deaktivieren der Entwicklerwerkzeuhe für den Nutzer (oder auch andere) bringt.
Aber danke für den – wie immer – tollen Artikel und deine Antwort.
1. weniger Code, der immer für alle Nutzer geladen wird
2. siehe Artikel:
Danke! 🙂