Comment by hkmurakami | Hacker News Reader

Comment by hkmurakami | Hacker News Reader

Parent Full thread

Back in 2011, I got my first exposure to WebKit and OSS in general as I was hanging out at my friend's office in downtown MV, 9pm on some random weekday.

I recall him working on submitting a patch (which I think got accepted after a few necessary revisions) to WebKit, and him explaining to me how WebKit is behind both Safari and Chrome, and how even though the companies and its fanboys are grabbing at each others' throats, the developers are happily working together, conversing casually on the mailing list and on twitter. It reminded me of the great sports rivalries, where the fans and media rile up the heat and hatred, but the players themselves remain respectful to their brethren on the other side of the lines.

In the years since, I've been able to help out some OSS projects as a non-coder, and I look back and think that learning about the collaboration behind WebKit certainly nudged me a little bit towards this direction.

It's a bit sad for me to see the Google and Apple teams split in this manner, since it was such a visible and prominent example of how OSS can bridge corporate divides, but I am hopeful that down the line we'll all look back at this moment in history with fondness.

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.

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.

The Law of conservation of complexity in action! :)

What about the ports? They seem to have lost out

Reply on news.ycombinator.com