Comment by general_failure | Hacker News Reader

Comment by general_failure | Hacker News Reader

Parent Full thread

general_failure

There's nothing to be sad about. Some people seem to think this is some sort of tragedy and failure of webkit the opensource project. It's not.

The fork happenned to a large extent for a want of control on the code base. So, it's mostly technical. WebKit has atleast 8 ports in trunk. Every part of it - networking, os, javascript engine, bindings, plugins, graphics has been hacked to death. And it has abstractions galore.

Now imagine you worked for WebKit. If you wanted to commit something, you had to test it against 8 ports. Many of these ports are cross platform. So, you are really talking about like gazillion combinations (mac, windows, linux, retina vs non-retina, os versions). It was not a happy place to develop and everyone in the project recognized this.

The pace of development was getting very slow because of the above. Apple faced this and said WebKit2 is all theirs and nobody else should really use it. Google faced this and decided to fork.

In short, most webkit devs are happy about this. It's worked out well for everyone.

It sounds like in a lot of ways, there was already a de facto fork in progress. In the limit case, when you have "one" browser codebase that in fact has two subsystems for every function and one and precisely one is used by each of the two "browsers", you don't have a shared codebase so much as a Frankensteinien horror with two hearts and two livers and perhaps five kidneys. You've got two people sewn together and you're calling them one, but they really aren't, and all it does is complicate matters, and inspire horror movies.

Of course this is not necessarily that limit case but it's not hard to imagine that what everybody is saying is perfectly technically true, and all that's really happening is that the fork that has already long since happened is merely being formally acknowledged, and now the shambling horror can be surgically partitioned and reassembled into two fine upstanding citizens. (And an extra kidney. How long has that been here‽)

Yeah, both sides seem to be having a "thank heavens we can get rid of all that crap we don't use" moment.

> In short, most webkit devs are happy about this. It's worked out well for everyone.

I can't say the same about front-end web devs. They are potentially looking at yet another browser family that can have its own quirks (sure, safari and chrome were different enough already, but this fork means that now they can be different at a lower level).

I believe this is pretty much the definition of "fear, uncertainty and doubt." Let's not spread it around.

Google already basically ran their own fork of WebKit — it most definitely was not the same codebase in Chrome and Safari. Now they've just made it a clean, official one. Let's not freak out about problems that may never exist and certainly don't yet.

They shared WebCore: pretty much all of HTML, CSS and JS parsing and CSS positioning. That's most of what a front-end, PSD2HTML kind of developer has to worry about.

So yeah, they will probably differentiate even more now.

I don't think it will be that bad. WebKit is already pretty well established, when they're this far along I doubt they'll diverge much. For the most part, even Firefox and WebKit render the same, even though they have no common lineage. This isn't going to be like IE6 vs Firefox.

The Law of conservation of complexity in action! :)

On mobile at least, Safari is already effectively its own browser family. Even though it's webkit-based, it has a huge range of quirks and caveats that don't apply to its desktop brother. Nothing really new here. What we will hopefully get is greater parity between desktop and mobile Chrome versions (which is already quite good), which I think will end up being an overall win.

What about the ports? They seem to have lost out

Reply on news.ycombinator.com