3 ms·

Okay, I'll bite. Having two implementations of a browser engine is a good thing. Without competing implementations, we're writing Chrome apps, not web apps. Th

• jcranmer 7y ago
  I'll add to this: In 2007 (!) Robert O'Callahan, one of the major developers of Gecko, was advocating internally to drop Gecko and replace it with WebKit in Firefox. Instead of exposing a big rift publicly, he posted hashes of his thoughts. Last year, he finally revealed what he had written and accompanied the reveal with some commentary that he now believes that to follow that path would have been a mistake: https://robert.ocallahan.org/2018/01/ancient-browser-wars-history-md5-hashed.html https://robert.ocallahan.org/2018/01/ancient-browser-wars-hi...
• The_rationalist 7y ago
  I answer late because I was blocked for "spamm", anyway here's my long answer. Well, first of all thank you. You actually added intellectual value to the thread and help me better understand others. That said, let's analyse what is right and what might be wrong from your comment. First of all, let's name A the hypothetical scenario where Firefox switch to chromium and maitain a soft fork where disagreement might occurs. Let's name B the scenario where gecko integrate more chromium code but stay mostly gecko. In this case too, they can have soft forks of chromium libs they use,(premise 1) it should still by an order of magnitude be less maintenance effort than to maintain their own lib and (premise 2) most libs/code sharing should not necessitate even a soft fork. Analysis begin: Without competing implementations, we're writing chromium apps, not web apps. So firstly, if chromium shipped implement supports the web standard spec it implement, we're writing web apps contrary to what you say. I believe there's something more accurate and more interesting that you wanted to say: Competing implementations are useful Yes, indeed! Or more precisely, not everything deserve competing implementations, competing implementations are interesting when: The best approach design is not obvious. Or when the things you try to implement has not an obvious most performant design, most featureful, maintainable, secure one. So competing implementations help to discover empirically what is the best approach about a complex thing to implement. It is rational to have redundant competing implementations if the speculated likely benefit outweight the human resources costs. Such a case apply for many parts of a browser, especially complex features and performance critical ones. It is important to recognize that by far not all constituents of a browser needs or would benefits from competing implementations. Let's name this fact Y. So you implyed that competing implementations are useful. Firefox and chromium are today almost 100% competing implementations. This goes in contradiction with the observed fact Y. Thirdly, we don't need competing browsers to have competing implementations. I frequently read both gecko and chromium design documents to implement a feature X. It is not rare to see that they outline competing possible approaches, and that they say they will try many of them and select the one that is empirically the best. Chromium having far more resources than mozilla does this more often. But mozilla rewrites like stylo, webrender, etc are examples of competing implementations inside the same browser. I call this fact Z, and this fact Z make your implyed point competing implementations are useful and firefox and chromium are total competing implementations vacuous. Let's analyse your next sentences: The important difference there is that monopolies are self-sustaining Yes this is a property shared by many projects: Linux, systemd, git, etc. It is not a bad thing in itself but if monopolies were a bad thing for another reason, this would amplify the effect of the bad thing. Cool, you outline the reason the after: and that competition prevents Google from exercising complete control over the Web without some other player having a say in it. So that's what you worry about! I understand the fear and if that were true that would definitely be an issue! In the current situation, what prevents Google from taking control over the web and implement X non standard features / behaviors? Well it's an error of yours to say that's because of total competing browser implementations. It's other browsers marketshare that allows other player to have a say in it The issue is: Firefox marketshare is shrinking, in parts because most of their limited resources are allocated a reimplementing features already implemented by chromium instead of focusing their resources on differenciating features, marketing, performance of key parts, etc (but mostly (sadly) marketing) In A (the hypothetical scenario where Firefox switch to chromium and maitain a soft fork where disagreement might occurs.) They still have a say in the web because of soft fork where disagreement might occurs it would be far more economically viable cf fact Y and the fact that code sharing decrease or eliminate maintenance cost. So scenario A would not change the fact that marketshare prevents Google from exercising complete control over the Web in fact it would probably help Firefox (better marketing funds, differenciating, etc) to increase it's marketshare so A would help diminish Google control. This does equally apply in the scenario B (where gecko integrate more chromium code but stay mostly gecko.) But scenario B diminish far less costs for mozillas but would still be an improvement as of current situation. Your first paragraph is refuted, if you catch logical fallacies in my refutation I would love to read them and correct them. I think you might realize this, although your GitHub post was inflammatory and showed little understanding of why monocultures are a bad thing. I don't if my post was inflammatory but the rest is, by transitivity refuted. I don't think it's an economically viable solution to pick and choose Chromium or Blink components to integrate into Gecko So you do think scenario B would cost more than current situation. You think that current almost no code sharing cost less than to share more code. Then your argument is decoupling and that The same is not true of most parts of Chromium. Your argument about decoupling make sense. But you say you are not familiar with both code bases. The same is not true of most parts of Chromium. You can't say that, I can't affirm the reverse neither. Identifying standalone browsers parts, and rank the most loosely coupled ones from the most is a huge task. The subject is serious (the future of mozilla) and we can't dismiss to increase code sharing based on a pessimistic a priori heuristic of how much coupled browsers code are. This is an open quantification question that must be seriously scientifically inquired by mozilla, I hope you will understand that. I do believe there are many loosely coupled parts in a browser e.g html parser, http client, crypto library (mozilla invest or waste ressources on NSS), and we have webIDL!! Eventually Firefox would benefits (beyong perf improvements) from using the mojo ipc system which standardize many things in chromium. Reinventing the wheel is not what Firefox is doing; it's been around longer than Chrome has! Haha, you have a point, I would have wished that KHTML did not exist in the first place and that everybody would have jumped on gecko. But this is past and the past is past. Firefox does today reinvent the wheel, they must catch up so many features already implemented on chromium years ago, and probably mostly don't even look at the chromium design docs and threads of said features to try to learn from experience. A "beautiful collaboration" is a solid concept, but all it would do would be to allow Google to exercise more control over the Web. You repeat your point that has been refuted. An example: There was a recent scandal from chromium where Google in a new web extension spec revision would limit some ad blocking features. Both brave and chromium edge said they would not adopt the change (eventually soft forking). Your idea of the "missing features" in Firefox needs some actual evidence before I can take your argument seriously. Well no, you don't needs evidence of missing features to support most of my arguments. Let's say today Firefox is on par feature wise, it does not change the fact they need to reallocate their ressources on marketing and user facing changes and theirs resources today are taken on optimization catch up and implement features at the same rate as chromium. I don't need to but I will: Firstly Firefox is sub par performance wise (tremendously on Android) E.g on this recent phoronix test, they do not win even one benchmarck and loose by a huge margin https://www.phoronix.com/scan.php?page=news_item&px=Firefox-68-Chrome-76-Browsers https://www.phoronix.com/scan.php?page=news_item&px=Firefox-... As for missing features it is difficult to see the extent of feature gap I see because it needs a lot of manual knowledge. The most maintained feature comparator is caniuse.com Where chrome supports 17 features more than Firefox. It is big but not that big. but chrome 75 to 79 does not gain any features because caniuse.com is not actively maintained. Each browser has an official page where it list their supported features but each page is up to date for the browser it originate and not for other browsers. By manually comparing them I've observed on https://www.chromestatus.com/features https://www.chromestatus.com/features the real gap there is (more like 100 features missing in Firefox), I invite you to compare and see by yourself. (If only this could be automated!) Thanks for reading, as you can see, as we talk about a serious issue, we must have high epistemological requirements and intellectual riguor.