Can someone with relevant expertise in this field comment on Google's decision to fork WebKit?
Since Google and Apple are competitors in this space, my knee-jerk reaction is to suspect that this is some kind of power play against Apple. However, there could be a legitimate reason, from a technical standpoint, that I don't know of.
Anyone care to share?
Google's splash with their multi-process architecture in WebKit got upstaged by a more scalable solution, WebKit2 designed by Apple.
Opera looks to be anchoring its port to Blink.
Meanwhile, Apple, KDE/Qt Port, GTK+/Epiphany, and the rest who have actually joined Apple's WebKit2 have hitched their focus with Apple's Engineering designs.
LLVM/Clang 3.3 will actually be the first release, top-to-bottom that Apple uses to build all of WebKit/WebCore their custom JavascriptCore engine and the rest of Safari.
LLVM/Clang 3.3 is released this June with a C11 complete profile, AMD GPGPU OpenCL/OpenGL work that Mesa and AMD both benefit from seeing as Intel, Adobe, Nvidia, AMD, Sony, IBM, Cray, ARM and others are all in with LLVM/Clang. Google is working two paths [LLVM/Clang and GCC]. Nvidia, AMD and Intel have made sure both LLVM/Clang and GCC all support their hardware options, but all their GPGPU OpenCL/CUDA coding leverages LLVM/Clang.
Google has chosen to keep that architecture which has not a damn thing to do with so many other Target architectures to maintain seeing as CPU specific stuff is handled elsewhere, and if they are indeed specifically hard coding bits for specific ARM, Intel or what not they forked so not as to deal with the fact their code submissions had to be in a wait state due to the simple fact Apple, GNOME and any other WebKit2 solution got sick and tired of WebKit trunk being broken.
It was inevitable the day Apple announced WebKit 2 that Google would fork.
Google wants a unified solution around their architecture for ChromeOS and Android that they dictate and thus the fork which allows both Webkit.org and Blink to maintain clean archives.
If and when each side has something valuable to offer I'm sure they'll merge those bits in back and forth.
Personally, I could give a rat's ass about Google's Blink. Chrome is a pig and Chromium is also a pig in design and resources.
Rubbish. It will be far better for consumers and the web in general. It will be more work for developers but if they stick to standards it won't be bad. With this move the good outweighs the bad like Adele outweighs Taylor Swift.
-kpluck
If they are going to stick to standards why fork? Google has something new they want to control and not be a standard apparently.
Don't blink. Blink and your dead. Don't turn your back. Don't look away. And don't Blink.
Best episode of Doctor Who… EVER! Brilliantly written for sci-fi or anything on TV in general. Steven Moffat is absolutely brilliant with the wibbly wobbly timey wimey stuff.
If they are going to stick to standards why fork? Google has something new they want to control and not be a standard apparently.
They do have Chrome OS. They might want to fork so they can do things that couldn't do with the direction WebKit is moving. I can certainly imagine Blink adding certain extensions that only work with Chrome and Google web apps, but that doesn't mean they can't be added to WebKit, Trident or Gecko.
Can someone with relevant expertise in this field comment on Google's decision to fork WebKit?
Since Google and Apple are competitors in this space, my knee-jerk reaction is to suspect that this is some kind of power play against Apple. However, there could be a legitimate reason, from a technical standpoint, that I don't know of.
Anyone care to share?
Well sure...coordinating is a pain in the rear and having code for functionality you don't want leads to increased bloat and bugs. With your own dev team and your own codebase you don't need to get consensus on design, features or schedule. You optimize for what you need and want.
If you were going to invest a lot of money on devs anyway, total control is the way to go.
What is the downside?
Idiots who see this as a good thing for WebKit and the web simply haven't looked at this graph:
See all that green? Google commits.
Commits on left, Developers on right side.
See all the green on the right side? The 42% of devs will be gone. A good chunk of the 27% other will follow (because Google is the darling of open source for some unknown reason). All the opera devs will not join webkit but Blink.
Speed forward will be slower and "competition" will mean deliberately introduced incompatibilities. Google was more than willing to attempt to fork the web with VP8 and they're going to try again both through code in Blink and through the standards body by ramming VP8 down everyone's throats via WebRTC as mandatory to implement.
"In short: we won't use vendor prefixes for new features. Instead, we’ll expose a single setting (in about:flags) to enable experimental DOM/CSS features for you to see what's coming, play around, and provide feedback, much as we do today with the “Experimental WebKit Features” flag. Only when we're ready to see these features ship to stable will they be enabled by default in the dev/canary channels."
It's open source and they are free to fork....but **** em and Opera too.
yeah innovation is nice, give US web developers another browser to test with and to figure hacks for is the problem. It's already bad enough to have to deal with IE that now we need a brand new engine...
Has anyone else noticed how this new engine (regardless of what one thinks of forking), is named after the most hated HTML tag of all time and the very tag that was perhaps emblematic of web fragmentation? The tag that essentially *started* the problem with web fragmentation?
Was there this much fuss over Chrome when Google replaced WebKit's JavaScriptCore with their own V8? I certainly can't recall any? Has JavaScript been fragmented and the web broken by Google designing their own engine or have other JS engines been made better by this increased activity?
Was there this much fuss over Chrome when Google replaced WebKit's JavaScriptCore with their own V8? I certainly can't recall any? Has JavaScript been fragmented and the web broken by Google designing their own engine or have other JS engines been made better by this increased activity?
As someone who uses Node.js, I must say V8 is a great piece of technology. Javascript on V8 is one of, if not the quickest dynamic language I've ever encountered....
Split already happened long time ago, very little of Google's commits got into Safari (and more generally WebKit2) anyway. So, this is really no big deal for Webkit. What is the big deal is that Webkit now have virtually no presence on Windows.
also, FYI; A monopoly (from Greekmonos ????? (alone or single) + polein ?????? (to sell)) exists when a specific person or enterprise is the only supplier of a particular commodity
So technically, yes, HTML and CSS have a monopoly.
You are so very wrong.
HTML is not the only markup language in use, and the internet can freely transmit any document in any markup language, therefore HTML is not a monopoly. It's certainly the most widely used, but not the only one in use:
Comments
Google's splash with their multi-process architecture in WebKit got upstaged by a more scalable solution, WebKit2 designed by Apple.
Opera looks to be anchoring its port to Blink.
Meanwhile, Apple, KDE/Qt Port, GTK+/Epiphany, and the rest who have actually joined Apple's WebKit2 have hitched their focus with Apple's Engineering designs.
LLVM/Clang 3.3 will actually be the first release, top-to-bottom that Apple uses to build all of WebKit/WebCore their custom JavascriptCore engine and the rest of Safari.
LLVM/Clang 3.3 is released this June with a C11 complete profile, AMD GPGPU OpenCL/OpenGL work that Mesa and AMD both benefit from seeing as Intel, Adobe, Nvidia, AMD, Sony, IBM, Cray, ARM and others are all in with LLVM/Clang. Google is working two paths [LLVM/Clang and GCC]. Nvidia, AMD and Intel have made sure both LLVM/Clang and GCC all support their hardware options, but all their GPGPU OpenCL/CUDA coding leverages LLVM/Clang.
Google has chosen to keep that architecture which has not a damn thing to do with so many other Target architectures to maintain seeing as CPU specific stuff is handled elsewhere, and if they are indeed specifically hard coding bits for specific ARM, Intel or what not they forked so not as to deal with the fact their code submissions had to be in a wait state due to the simple fact Apple, GNOME and any other WebKit2 solution got sick and tired of WebKit trunk being broken.
It was inevitable the day Apple announced WebKit 2 that Google would fork.
Google wants a unified solution around their architecture for ChromeOS and Android that they dictate and thus the fork which allows both Webkit.org and Blink to maintain clean archives.
If and when each side has something valuable to offer I'm sure they'll merge those bits in back and forth.
Personally, I could give a rat's ass about Google's Blink. Chrome is a pig and Chromium is also a pig in design and resources.
Quote:
Originally Posted by kpluck
Rubbish. It will be far better for consumers and the web in general. It will be more work for developers but if they stick to standards it won't be bad. With this move the good outweighs the bad like Adele outweighs Taylor Swift.
-kpluck
If they are going to stick to standards why fork? Google has something new they want to control and not be a standard apparently.
Best episode of Doctor Who… EVER! Brilliantly written for sci-fi or anything on TV in general. Steven Moffat is absolutely brilliant with the wibbly wobbly timey wimey stuff.
They do have Chrome OS. They might want to fork so they can do things that couldn't do with the direction WebKit is moving. I can certainly imagine Blink adding certain extensions that only work with Chrome and Google web apps, but that doesn't mean they can't be added to WebKit, Trident or Gecko.
Quote:
Originally Posted by Robin Huber
Sounds evil-ish to me
Sounds very open source-ish to me. If there's one thing they do, it's fork.
Duck. Duck now!
Quote:
Originally Posted by am8449
Can someone with relevant expertise in this field comment on Google's decision to fork WebKit?
Since Google and Apple are competitors in this space, my knee-jerk reaction is to suspect that this is some kind of power play against Apple. However, there could be a legitimate reason, from a technical standpoint, that I don't know of.
Anyone care to share?
Well sure...coordinating is a pain in the rear and having code for functionality you don't want leads to increased bloat and bugs. With your own dev team and your own codebase you don't need to get consensus on design, features or schedule. You optimize for what you need and want.
If you were going to invest a lot of money on devs anyway, total control is the way to go.
What is the downside?
Idiots who see this as a good thing for WebKit and the web simply haven't looked at this graph:
See all that green? Google commits.
Commits on left, Developers on right side.
See all the green on the right side? The 42% of devs will be gone. A good chunk of the 27% other will follow (because Google is the darling of open source for some unknown reason). All the opera devs will not join webkit but Blink.
http://blog.bitergia.com/2013/02/06/report-on-the-activity-of-companies-in-the-webkit-project/
Speed forward will be slower and "competition" will mean deliberately introduced incompatibilities. Google was more than willing to attempt to fork the web with VP8 and they're going to try again both through code in Blink and through the standards body by ramming VP8 down everyone's throats via WebRTC as mandatory to implement.
"In short: we won't use vendor prefixes for new features. Instead, we’ll expose a single setting (in about:flags) to enable experimental DOM/CSS features for you to see what's coming, play around, and provide feedback, much as we do today with the “Experimental WebKit Features” flag. Only when we're ready to see these features ship to stable will they be enabled by default in the dev/canary channels."
It's open source and they are free to fork....but **** em and Opera too.
deleted
It's already bad enough to have to deal with IE that now we need a brand new engine...
Quote:
Originally Posted by JamieLeSouef
Considering Webkit is software, and HTML5 is, in practice, a collection of languages.. i would say you're wrong.
This is pretty poor reasoning. Lots of things can create or aide in the creation of a monopoly. They don't have to be the same type of thing to do it.
Has anyone else noticed how this new engine (regardless of what one thinks of forking), is named after the most hated HTML tag of all time and the very tag that was perhaps emblematic of web fragmentation? The tag that essentially *started* the problem with web fragmentation?
Coincidence? I think not!
Quote:
Originally Posted by GTR
I like this guy.
In five posts he's insulted, not only three regular contributing posters on this forum, but a shitload of web developers.
/S
I know, he's so unnecessarily, over-the-top aggressive that it makes me think that "JamieLeSouef" is actually code for "Shia LeBoeuf."
He seems to actually know things though, so that can't be true.
Quote:
Originally Posted by tzeshan
Will Google make Blink open source too?
They have to, the core parts of Webkit are LGPL licensed (from the KHTML days).....
Quote:
Originally Posted by SolipsismX
Was there this much fuss over Chrome when Google replaced WebKit's JavaScriptCore with their own V8? I certainly can't recall any? Has JavaScript been fragmented and the web broken by Google designing their own engine or have other JS engines been made better by this increased activity?
As someone who uses Node.js, I must say V8 is a great piece of technology. Javascript on V8 is one of, if not the quickest dynamic language I've ever encountered....
Quote:
Originally Posted by Robin Huber
Sounds evil-ish to me
Forking is part of open source. In a sense, it's a Darwinian mechanism that ensures the evolution of code...
Plus, if Google succeeds in making a better engine, Apple can always fork it back...
Split already happened long time ago, very little of Google's commits got into Safari (and more generally WebKit2) anyway. So, this is really no big deal for Webkit. What is the big deal is that Webkit now have virtually no presence on Windows.
Originally Posted by JamieLeSouef
also, FYI; A monopoly (from Greek monos ????? (alone or single) + polein ?????? (to sell)) exists when a specific person or enterprise is the only supplier of a particular commodity
So technically, yes, HTML and CSS have a monopoly.
You are so very wrong.
HTML is not the only markup language in use, and the internet can freely transmit any document in any markup language, therefore HTML is not a monopoly. It's certainly the most widely used, but not the only one in use:
List of Document markup languages
you've probably used a few without realising it.
KML for Google Earth
Wiki markup in Wikipedia
WML Wireless Markup Language for mobiles
SVG Scalable Vector Graphics
etc