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‽)
> 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.
Unless I am mistaking things* it looks like there is a rather big problem brewing regarding the JS engines in webkit.
Webkit guys want to remove support for V8 (and any JS engine apart from their own JSC engine) due to maintenance and complexity conerns BUT:
* Qt 5.x uses V8 in Qt's Webkit
* Samsung uses V8 (In a unofficial fork of WebkitGTK+ by the looks of it).
* Oracle want to add support for their own JS Engine to webkit.
Resolving this one amicably should be interesting. If you want to use Webkit on windows with anything other than JSC it looks like you might want to start investigating blink in detail.
I personally have no stake in this, I am just observing from an outside perspective so I cannot really say why some groups whose webkit + V8 over JSC, you would really have to ask them.
I am guessing there are probably non-technical points (eas of commit access, architecture, roadmap etc)
FWIW, I thought of the exact same thing. I think Samsung/Oracle/BB etc. are going to end up maintaining their own WebKit or Blink forks. (Not sure why Google will agree to add stuff that doesn't benefit their cause. Just like how Apple is saying JSC or bust Google might down the line say V8 or bust.)
I sure hope so. I'm already getting sick of the "Show HN: Only Works In Chrome (only works in dev version of Chrome)" links that were starting to show up.
As a firefox user i agree, it's a little bit annoying, but don't think this fragmentation will have any effect on it.
Problem is that most developers use chrome, and chrome have more cool stuff, so they wouldn't care about safari just like they don't care about other browsers now.
There will be no-one to maintain it and a lot of the friction between the platforms was the JS engines. Both WebKit and Blink are excited to rip out the conflicting codebases and I think they've both learned lessons about maintaining multiple JS engines.
I noticed a striking lack of snark in this link and the prior announcement of Blink. Either these are pros who are working in good faith toward their respective ecosystems, or there's bad blood and vitriol all around that goes deep enough to not get expressed right away.
I'm hoping for the former, but human nature being what it is...
There is one now. And the author of the mail posted in the thread linked here and offered help, seemed professional to me. Of course, I don't know whether there was any arguing going on before that decision, but that thread doesn't seem to point to that.
Strongly disagree- many people have put years into these projects and are incredibly passionate.
They will all still have to cooperate on standards committees and I'm sure there will be a lot of interaction- the browser community is fairly small and all of the companies collaborate to some degree (even Microsoft, somewhat ;).
No reason to burn bridges, I see it as more of a sad separation of ways- each knowing it was for the best.
I was expecting something similar, but looking at the responses it seems like it was just there mostly for google. Any way , supporting v8 on webkit would be a burden when it's main developer is no longer there.
"Supports" maybe (is it up to date with WebKit security fixes?), but definitely no longer maintains or develops. Safari 6 is not available for Windows. There have been no updates to Safari for Windows in almost a year, and no new feature releases in almost two years.
On that matter, I wonder why they didn't continue to provide security updates for 5.x when they decided to continue support for Snow Leopard, like MS did with IE.
Maxthon and Qihoo are both major browser vendors in China who provide dual-engine (Trident and WebKit) browsers for Windows. I don't know whether they contribute code to the Windows WebKit port, or whether they do/will use Chromium/Blink.
How do dual-engine browsers work? Do you manually switch between engines? Is there some sort of automatic "this page looks better in this engine" determination that happens?
There's probably a whitelist of sites that still require Trident. The reason for this is that there are a lot of Chinese websites that are still only IE6-compatible (this is a result of many Chinese installs of Windows being pirated copies of XP running IE6 - they don't want to upgrade to new versions of IE or Windows for fear of losing their OS validation). The Chinese internet is currently in a transitional period, with many established sites still working only with older versions of Trident, while newer sites (particularly mobile sites, and particuarly those targeted at the middle- and upper-class) support modern engines. Such dual-engine browsers help to ease that transition.
A bunch of games use webkit for in game UI. Many of them run on windows.
I think quite a few use Webkit directly but there are some middle-ware libraries for the purpose. Awesomium I belive is reasonably frequently used. Their website says that it uses "Chromium/WebKit" though so I suppose that they may be moving to Blink as well.
Steam doesn't use bare WebKit but Chromium, presuming they stay up to date (my install registers as Chromium 18, so doubtful) and don't switch, they'll be running Blink instead.
So which browsers on the market are currently using webkit proper? I've heard that Apple uses their port called Webkit2 for Safari, and now with Chrome and Opera using Blink, who's left?
Or will Webkit2 and Blink still pull changes and improvements in from Webkit?
Chromium (kind-of) supports DartVM. The fact that they're working on Dart will be a big incentive to keep the abstractions between the browser and the scripting language implementations as clean as possible.
Undo a fork is at least an order of magnitude more difficult than making the decision to fork in the first place. Nobody has that on their minds right now.
Could you explain how this is "pumping and dumping"?
What I have learned from the material floating around is that there are fundamental difference in the architectures of Chrome and Safari and how they talk to WebKit. Google decided to go their own way because maintaining the common code base was a pain for both sets of developers.
“Safari is substantially less common than Chrome.”
Last I checked, Safari has 544 million users, whereas Chrome has 260 million users.
(There are about 1.4 billion personal computers. Chrome is on 16.45% (230 million) of those computers, Safari is on 5.31% (74 million) of those computers. There are about 30 million Android devices with Chrome. There are 470 million iOS devices with Safari.)
Given how fast the mobile market is growing (while the Windows PC market is shrinking), and given that many Android devices are sold with other browsers than Chrome, I'd say the gap is only going to get wider.
No, because it's another way to talk in social media. Now, let's not get into the semantics, we all know how much correct grammar is used in social media/web.
Not everything is pit-for-pat, juvenile disputes. Occasionally you'll find grown up professionals with valid technical or business reasons for the decisions they make.
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.