> Backwards bug compatibility
This is obviously pointed at what IE did after years of maintaining the same bugs that people relied on. The article actually figured out WHY this happened: taking a year to fix a MAJOR issue results in people relying on it. IE was always updated very, very slowly. Nobody else really had this problem, and IE is the one who instilled major flaws as "features" and refused to correct them later on. This very much describes exactly what Microsoft did with IE.
But then they try to ascribe that, somehow, with major handwaving as a problem that will be seen if everyone uses the same code base. This coming on the heels of Opera deciding to use WebKit. It's very clear they are making the claim that the same problems IE was having would be caused by WebKit. This is called talking shit.
The problem is that these problems were caused by a well known phenomenon: taking years to fix major issues. Google has maintained a PHENOMENAL rate of development on their own browser, and they aren't even competing with Mozilla anymore, they're way out in front. Pushes to stable are slower but Canary is updated almost daily. I've seen major bugs and regressions get fixed in HOURS. And I've seen independent players issue patches to fix problems.
This is a picture that is antithetical to IE. It is the POLAR OPPOSITE of the scenario under which this problem initially became so egregious. There is no basis for this claim. And to the point that we "NEED" multiple implementations of a standard to find where things are ambiguous, please feel free to peruse the discussion groups at your leisure. Not only are these ambiguities discussed without referencing Firefox, IE, or anyone else, but they're often resolved with changes in the implementation or, rarely, in the spec. This would be an impossibility if we all worked on 1 code base, clearly.
Sure there is. Consider https://bugs.webkit.org/show_bug.cgi?id=36084 which is unfixed for many years now because of backwards compat issues with non-Web stuff on Mac that uses WebKit.
I can find you more examples if you'd like.
Sometimes WebKit is willing to break compat to make progress, but very often they are not. And if they were not competing with others, I fully expect them to be less willing to break compat: right now they mostly do it when the standards and other UAs force them to.
Look, I am not dissing webkit devs whatsoever. They're smart people doing a great job, and they're getting strong support from their employers because doing a great job really matters. But if we end up in a webkit monoculture, I imagine much of both the intrinsic and extrinsic motivation will disappear. You're running a for profit corporation. Should you continue pouring resources into a game you've already won, or should you shift them towards something else that's going to impact your bottom line? That, and only that, is the connection I would make with IE6.
If that's talking shit, then fine I'm talking shit. But I don't think it's unfair to expect webkit's caretakers to behave like rational humans.
As for needing multiple implementations to find problems, I won't challenge the assertion that people are uncovering and resolving ambiguities on discussion forums, without needing multiple implementations. But how many are found this way? Surely you would agree that some problems are found by trying something out, having it not work, testing it in a different browser, and seeing it behave differently? I assert that many, many problems are found this way. I further assert that ambiguities don't really matter to people if all browsers behave the same way - until you need to do something different (eg make something faster or add a new feature), at which time those ambiguities suddenly become critically important. Enumeration order of JS properties comes to mind here. The Web came to depend on creation order despite it not being specced. But what about indexes? What if you have some of both?
Right, this is Google now, not Google of 2018 or Google in 2030. Nothing prevents Google from saying, oh well this sucks... Let's kill Chrome. Or shift manpower to something else, slowing down rate of development.
Also I don't understand what is your point, this argument was about WebKit, not Chrome.
Usability (configuration, ease of migration of configuration, etc): win
Developer tools: win+++++
Speed: win (JS + speed of rendering, though this is a lot closer than it used to be)
System footprint: win
Availability of experimental features in beta: win (though from time to time Firefox does some crazy awesome shit in beta builds, Chrome is more consistent)
I've long said the only browser remotely close to Chrome is Firefox, but for me, they are a clear leader. It's unfortunate to see Mozilla behaving this way in public. I take Opera's choice of using Chromium as a validation of my assertion, and I really believe if they had chosen to use Mozilla's software instead of Google's, that Mozilla would be fairly silent right now.
Sometimes Chrome is easier to configure (With Firefox you need to enable click to play in about:config, while Chrome has a checkbox somewhere in the "advanced" menu), sometimes is harder (Try to configure a proxy in chrome)
>Ease of migration
I haven't tested it myself, but i know that Firefox can load your history/bookmarks from Internet Explorer and Chrome.
If you mean between the same browser, Firefox Sync is on par with Chrome for me.
Chrome has better tools ootb, but you can install Firebug in Firefox which is mostly on par.
You're talking about addon? Because Firefox's addon can be way more powerful than Chrome's addon.
Firefox usually uses less memory than Chrome (but it's more prone to memory leaks).
For the CPU, i don't know about Chrome, but my Firefox installation is currently using about ~1% of it