Cleaning House(lists.webkit.org)
lists.webkit.org
Cleaning House
https://lists.webkit.org/pipermail/webkit-dev/2013-April/024388.html
10 comments
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.
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‽)
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 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.
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.
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
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 probably am.
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 probably am.
Out of curiosity, why would you have a strong preference for one of the two over the other? Both are open source and very fast,
http://www.arewefastyet.com/#machine=12&view=breakdown&#...
each beats the other on some benchmarks. Is there another reason for your preference?
http://www.arewefastyet.com/#machine=12&view=breakdown&#...
each beats the other on some benchmarks. Is there another reason for your preference?
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)
I am guessing there are probably non-technical points (eas of commit access, architecture, roadmap etc)
The Oracle project[1] is pretty interesting and uses neither. Instead it has a native java implementation.
[1] Nashorn - http://openjdk.java.net/projects/nashorn/
[1] Nashorn - http://openjdk.java.net/projects/nashorn/
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.)
Yea, it looks like we might have some pretty severe fragmentation ahead.
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.
Qt5 uses V8 for QML and JavaScriptCore for QtWebKit.
There is no way that V8 remains viable in WebKit.
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.
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.
The Qt port of WebKit uses JavaScriptCore, not V8.
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...
I'm hoping for the former, but human nature being what it is...
The lack of responses to the announcement post makes me sad. https://lists.webkit.org/pipermail/webkit-dev/2013-April/024...
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.
Probably because there is little to no hobbyist community involved. It's no one's baby, just their day job.
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.
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.
So it seems you'll need to choose Blink+v8 or WebKit+JSC, I had thought WebKit+v8 was relatively common but perhaps its just Google.
https://lists.webkit.org/pipermail/webkit-dev/2013-April/024...
https://lists.webkit.org/pipermail/webkit-dev/2013-April/024...
Phantom.js does use WebKit+JavaScriptCore, though they were musing about moving to V8: https://groups.google.com/forum/?fromgroups=#!topic/phantomj...
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.
Opera planned to adopt WebKit+v8, but since they are moving to Blink they will be fine.
Opera was planning to move to Chromium all along, not WebKit. So it was a given they would be using v8.
Also, given how recent Opera decided to switch to Chromium, surely they knew about Google’s plans?
Will Android and Windows become "tier 2" platforms in Apple's WebKit tree? Who, besides Google's Chrome team, cared about WebKit on Windows?
Well, Apple does. They use WebKit to render the iTunes store.
https://lists.webkit.org/pipermail/webkit-dev/2013-April/024...
It seems like it up to QT port to handle windows.
It seems like it up to QT port to handle windows.
https://lists.webkit.org/pipermail/webkit-dev/2013-April/024...: We are also maintaining the WebKit1 Windows port at Apple.
Apple also supports Safari on Windows.
http://support.apple.com/kb/DL1531
http://support.apple.com/kb/DL1531
"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.
[deleted]
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.
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.
The Steam overlay uses WebKit, as well as every Source game that renders HTML.
Valve's Steam gaming platform uses Webkit to render their Store and have a 40-million strong userbase at most recent count http://gamespot.com/news/steam-crosses-40-million-users-6348...
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.
https://developer.valvesoftware.com/wiki/Chromium_Embedded_F...
(Unrelated: their embedded Chromium seems to be hard-coded to Windows-like shortcuts; even in the address bar)
https://developer.valvesoftware.com/wiki/Chromium_Embedded_F...
(Unrelated: their embedded Chromium seems to be hard-coded to Windows-like shortcuts; even in the address bar)
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?
Or will Webkit2 and Blink still pull changes and improvements in from Webkit?
Webkit2 is a branch of webkit project supported by parties other than apple.
[deleted](1)
Google pumping and dumping. Seems kind of shitty to me. E: I do realise it's a very long term pump. But it has that feel.
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.
There is no pumping or dumping. Google and apple have different goals and ideas to how the projects should move forward.
Yay...common Safari beat Chrome!
What? Safari is substantially less common than Chrome. I'm confused.
“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.
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.
You are responding to a stray Apple fanboy who spelled "come on" as "common." I recommend disengaging.
Commonly used by uneducated teens and young adults
So you're trying to sound uneducated?
So you're trying to sound uneducated?
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.
HN is not Facebook. Hold yourself to a higher standard.
So it's a spelling mistake. Who would've guessed?
I'm trying to express my anger and joy at the same time. Just like how chromium has abandoned webkit, it's Webkit's time to return the favor, get it?
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.