I disagree entirely. This is an inflammatory piece that is factually full of nonsensical claims that don't and haven't held up. It makes HUGE assumptions that have direct contradictions in practice. I don't see how anyone could take it seriously. As for not "talking shit" about WebKit, let's look at that one claim:
> 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.
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.
Remember, my article was about incentive structure. Webkit's evolution so far has NOT been in the context of a monoculture, so pointing to past behavior as evidence for future actions within a monocultural context doesn't hold up. I would guess that at least part of the reason why webkit has been developed so aggressively and well is because they were competing with the other players. I know that much of the energy behind recent spidermonkey development came from v8 kicking our ass in the Firefox 3.6 era.
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?
> Google has maintained a PHENOMENAL rate of development on their own browser.
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.
I don't want to start a browser flame war, but for me these are clear victories and explanation is unnecessary. Their combination is sufficient for me to vote that Chrome > Firefox, and this as a person who used to use Firefox religiously until Chrome completely changed the game.
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.
You really shouldn't list subjective things like Usability, Extensibility because for me Usability is the same and Extensibility is laungably better for Firefox. Also I don't think Developer tools are that much bigger win.
I understand that you don't want to start a browser flame war, and neither i do, but:
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
There is some merit to this claim. Firefox on my 4GB 1GhZ laptop is somewhat sluggish (it could be down to several factors), especially when it comes to Flash. Chrome flies, but Nightly is actually on par with Chrome.
If developing to standard gives you the same result on each engine then the number of them does not matter.
What if I develop to standard but only test in Webkit. My page is broken in Gecko though. Whose fault is that, Webkit's, Gecko's or mine? If it's mine then why? I did everything according to standards.
So in reality you don't develop against standards (alas), you develop against their implementations, and having multiple engines helps in no way.
In reality, most web developers have no clue about what the standard says in edge cases, which is just fine: neither do most other people.
But the result is that it's very rare to find cases that are really developed "to standard".
Even worse, though, on mobile right now people aren't even trying to develop to standards. UA sniffing and locking out of non-WebKit UAs and use of -webkit-prefixed things even when standard alternatives are available is rampant and purposeful. And when you ask these people to develop to standards they just laugh at you.
In reality you develop against multiple implementations that attempt to adhere to the same standard, where they break in between is where the standard or the implementations need fixed, differences in assumptions agreed and ambiguities clarified. That was the point of the blog post?