3 ms·
The post is discussing how people develop against a single engine as opposed to a standard, its not 'projecting' and certainly not 'talking shit' about webkit
by daleharvey 14y ago
The post is discussing how people develop against a single engine as opposed to a standard, its not 'projecting' and certainly not 'talking shit' about webkit
- rimantas 14y agoIf 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.
- daleharvey 14y agoIn 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?
- bzbarsky 14y agoIn 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.
- just2n 14y agoI 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.
- Ygg2 14y ago> 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.
- mwcampbell 14y agoYou say that Chrome is way out in front of Firefox. Can you please back up this assertion?
- just2n 14y agoI 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+++++ Extensibility: 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.