Hacker News new | comments | show | ask | jobs | submit login

But there's still room for competition with the same codebase. WebKit browsers differ significantly, and still compete with one another.

Though this post claims to be talking about WebKit, I see something like this:

> There’s a bug — background SVG images with a prime-numbered width disable transparency. A year later, 7328 web sites have popped up that inadvertently depend on the bug. Somebody fixes it. The websites break with dev builds.

And have to wonder if they're trying to project IE's issues onto WebKit. I used to have a lot of respect for Mozilla. But now that MDN is stagnating, Firefox is a much less inviting development environment than Chrome (oh how things have changed), and with Mozilla talking shit at every turn, I think I have to revoke all respect. Good luck, guys.




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


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.


> There is no basis for this claim.

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.


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.


You say that Chrome is way out in front of Firefox. Can you please back up this assertion?


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+++++

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.


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:

>Configuration

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.

>Developer tools

Chrome has better tools ootb, but you can install Firebug in Firefox which is mostly on par.

>Extensibility

You're talking about addon? Because Firefox's addon can be way more powerful than Chrome's addon.

>System footprint

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


> System footprint: win

Defined how?


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?


What do you mean MDN is stagnating? There's a constant upkeep going on there, which is difficult considering how fast the web moves but it's constantly being updated.


It's becoming less usable (see: JS classes, prototypes were separated in some but not in others) and the information on it isn't keeping up with standards at all. It might be fine for people who are working on browser builds as of about 24 months ago, but it is woefully inadequate for anyone who wants to use something that is even in a draft state or considered stable.

A quick example: look at document.cookie. They are referring to DOM2 information. It's undergone some (slight) changes in HTML5. Nothing is referenced, even though that section is relatively stable and marked as safe for implementation. That's a 2000 spec vs a 201x spec. Nobody's even gone in and pointed out that this has changed in HTML5.


I hate to say this, but ... it's a wiki. Have you considered just adding a note to the page pointing out that it needs updating?

For example, I had no idea document.cookie got changed in HTML5, and I bet neither did anyone else involved.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: