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 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.
That metric is misleading as Apple activity in the webkit project is not typical :
They maintain (or maintained until end of 2010 at least. since then i stopped following) an internal webkit which is a snapshot of the open one at a release point and do maintenance and dev on that. They will then commit huge chunks commits of many bundled changes in one go. I see no reason why they would have changed their attitude since.
The reason for that is that the open source webkit can play with experimental features without impacting safari. So most of the maintenance is done on the snapshot.
In contrast, Google is a typical player with as we go commits. More, many of those commits are not webkit per se, but related to the Architecture of chromium.
As for if it is a good thing or not, that should not change much for the webkit and Apple teams.
They were doing fine without Google and would do fine now.
But it is a very bad move for interopebality. One of the basic rules of open source is that you dont fork an healthy project. The only reason to do that is when you want to do changes that would never fly with the current core team.
The "Do not evil" days of Google are really a thing of the past
Google's splash with their multi-process architecture in WebKit got upstaged by a more scalable solution, WebKit2 designed by Apple.
If my understanding is correct, WebKit2 handles the process separation stuff for you, behind it's API, whereas the Google approach required you to do it yourself. If this is true I would expect most devs would stick with the Apple solution, to prevent reinventing the wheel.
I am just grateful to never visit a site anymore that says "Internet Explorer is required to view this site". As long as us Mac folks can continue to surf without being penalized as years ago I am all for speed and diversity of choice.
What Microsoft attempted to do with Internet Explorer was anathema to some of the very reasons why HTML and WWW were created, their attempt to subjugate the web to their software sadly almost succeeded. Microsoft were effectively taking www work and making internet explorer additions to it in an attempt to force the world to use their software.
I think the current situation, where different organisations implement their own rendering engines to process the widely agreed standards, has helped push innovation with access to the info on the internet (notably mobile) and thus made life easier for the world.
Therefore, it doesn't matter what rendering engine Google comes up with providing it's working on the same www code and languages as everybody else.
Well ... having to test across different engines will suck. However one must remember that the web is forever evolving. Rendering engines will come and go and change.
If they improve on the current tech and introduce newer tech... then I say its a good thing
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! :)
Not a coincidence at all actually:
"[blink] was widely derided as the worst HTML tag ever created and so we picked the name Blink because it kind of suits our slightly ironic taste in names. We called our browser Chrome because the whole idea was to minimize the chrome. We called our computer Pixel because we tried to make all the pixels disappear. Now, we are calling this rendering engine Blink because it doesn't support the blink tag." - Linus Upson (VP of engineering on Google’s Open Web Platform team)
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?
To put it simply.
Apple wants to use WebKit as the engine for a Web Browser. (Safari)
Google wants to use Blink as the engine for an Operating System. (Chrome OS)
That metric is misleading as Apple activity in the webkit project is not typical :
They maintain (or maintained until end of 2010 at least. since then i stopped following) an internal webkit which is a snapshot of the open one at a release point and do maintenance and dev on that. They will then commit huge chunks commits of many bundled changes in one go. I see no reason why they would have changed their attitude since.
The reason for that is that the open source webkit can play with experimental features without impacting safari. So most of the maintenance is done on the snapshot.
In contrast, Google is a typical player with as we go commits. More, many of those commits are not webkit per se, but related to the Architecture of chromium.
As for if it is a good thing or not, that should not change much for the webkit and Apple teams.
They were doing fine without Google and would do fine now.
But it is a very bad move for interopebality. One of the basic rules of open source is that you dont fork an healthy project. The only reason to do that is when you want to do changes that would never fly with the current core team.
The "Do not evil" days of Google are really a thing of the past
Exactly. Anyone who argues that this won't contribute to fragmentation has their eyes closed.
What Microsoft attempted to do with Internet Explorer was anathema to some of the very reasons why HTML and WWW were created, their attempt to subjugate the web to their software sadly almost succeeded. Microsoft were effectively taking www work and making internet explorer additions to it in an attempt to force the world to use their software.
I think the current situation, where different organisations implement their own rendering engines to process the widely agreed standards, has helped push innovation with access to the info on the internet (notably mobile) and thus made life easier for the world.
Therefore, it doesn't matter what rendering engine Google comes up with providing it's working on the same www code and languages as everybody else.
Wait a second. Your first paragraph highlights the dangers involved.
Then, in your second paragraph, you simply wave your hands and pretend that the dangers disappeared. Since Google arguably has more power over the Web than Microsoft did, it's not clear how you reached that conclusion. The risk is quite real.
All Google has to do is implement new tags in Adwords or the links that allow people to insert Google Maps into their page and everyone will be forced to use the new, non-standard tags. And if those tags are not part of the open source portion, then Google can keep them proprietary. Boom. Instant fragmentation (and nightmares for developers).
What if ... what if it were Apple that did this? What if it were Apple that declared, "Webkit has grown long in the tooth, too big, too wieldy."
I imagine there would be applause all around? Perhaps it is understandable that a company that had the nerve to walk away from the floppy, the DVD and Flash would get more benefit of the doubt, whereas a company which has contributed to computer science at a level less comprehensible to the masses would have its motives questioned forever.
I think it is just fundamentally different views of how the browsers and JavaScript should work. And to be honest the fork has been long time coming. I never understood why it took them so long.
Since the Multi Process view from both are so different. If you read some of the thing Google is trying to do with Bink, they even want iframes to be in separated process. Just like how they handle Tabs. If you dont like having hundreds of process running, you are going to have even more! They want Blink to be more like a OS ( Chrome OS ? ), while Apple wanted WebKit2 to be more like um.... a small and embeddable browser engine that could be used for anything from Browsers to within Apps.
And my guess is that some of the things listed here
In theory. In practice, though, there are lots of ways around that. Look at 'Free' Android where they arbitrarily decide not to release some versions.
Which part of the Android OS are you talking about? Wikipedia says Android is licensed under Apache License 2.0 which does not require you to release the source code even though you release the binary. The kernel (Linux) on the other hand, since it is GPL, require you to release the source code once you ship the binary.
For LGPL, it's similar to GPL in the sense that you need to release the source code when you ship the binary.
you would have a problem because it has no competition, no competition leads to lack of innovation. Don't think for a second that just because something is Open Source that it's going to be innovative.. just look at open office!
You labor under a common misconception that competition and innovation have some sort of direct relationship. Don't think for a second that lack of competition hinders innovation -- in fact, the greatest innovation comes when people are creating something entirely new, where there is no competition at all -- or that competition spurs innovation -- just look at the Windows PC industry, where's the innovation there?
Innovation can occur when there's competition, and when there isn't. Competition can occur without innovation, or when it exists. But, to conclude that there's some sort of causal relationship between them is not only unfounded, but contrary to the available evidence.
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. ...
Please explain exactly how lack of standardization in browser behavior will,
a. be, "far better for consumers and the web in general," and
b. how having to develop for and test on yet another platform will, "[not] be bad [for developers."
Frankly, I can't see how you can support either of those statements. And, for those of you pointing to IE as an example of how "rendering engine monopolies" are harmful, the reason IE was bad for the web wasn't that everyone on Windows was using it and developers were ignoring other browsers. The reason it was bad was that it was a Windows only de facto standard, which is entirely contrary to the situation with WebKit, so analogies along those lines are entirely invalid.
What's the difference? Governance. Even an open source project is managed very differently from an open standard.
The problem with relying on one piece of software is that software architects have a tough time predicting the future. Software often becomes slow, bloated and crufty over time. Standards like HTML can be written and re-written very easily. Software doesn't have the same luxury. Having a newer alternative waiting in the wings is never a bad thing. It's a shame that the new alternative is controlled by one company though.
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.
Google has shown an antipathy toward standards lately, as evidenced by the whole WebM thing and their, albeit short lived, support for Flash on Android. If anything, they've shown themselves inclined to go down the same sort of paths as Microsoft by attempting to establish new de facto "standards" that they control. This all dovetails with Google's desire and intent to control access to all information on the Internet, to be the portal -- via search, email, Android, Chome, etc. -- that everyone must pass through to get to anything.
You should definitely expect to see Blink adding "extensions" that only work when the user is using Google technologies. And you should definitely expect Google to aggressively evangelize these extensions to developers. In fact, you should expect to see them attempt to create exactly the situation Microsoft had with IE, without being weighed down with a monopoly OS hanging around their necks.
That, by the way, is the analogy with IE that is correct in this situation.
Google has shown an antipathy toward standards lately, as evidenced by the whole WebM thing and their, albeit short lived, support for Flash on Android. If anything, they've shown themselves inclined to go down the same sort of paths as Microsoft by attempting to establish new de facto "standards" that they control. This all dovetails with Google's desire and intent to control access to all information on the Internet, to be the portal -- via search, email, Android, Chome, etc. -- that everyone must pass through to get to anything.
You should definitely expect to see Blink adding "extensions" that only work when the user is using Google technologies. And you should definitely expect Google to aggressively evangelize these extensions to developers. In fact, you should expect to see them attempt to create exactly the situation Microsoft had with IE, without being weighed down with a monopoly OS hanging around their necks.
That, by the way, is the analogy with IE that is correct in this situation.
WebKit is not a standard. It's an engine. Forking it does not change HTML and other code it renders. Imagine having a slightly different, but better kernel for an otherwise identical OS. If you truly think this will ruin the internet then you'll need to explain why that hasn't already happening with Google removing Nitro and replacing it with their V8 engine. Where is the total destruction of all things JavaScript?
Comments
Quote:
Originally Posted by nht
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 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/
That metric is misleading as Apple activity in the webkit project is not typical :
They maintain (or maintained until end of 2010 at least. since then i stopped following) an internal webkit which is a snapshot of the open one at a release point and do maintenance and dev on that. They will then commit huge chunks commits of many bundled changes in one go. I see no reason why they would have changed their attitude since.
The reason for that is that the open source webkit can play with experimental features without impacting safari. So most of the maintenance is done on the snapshot.
In contrast, Google is a typical player with as we go commits. More, many of those commits are not webkit per se, but related to the Architecture of chromium.
As for if it is a good thing or not, that should not change much for the webkit and Apple teams.
They were doing fine without Google and would do fine now.
But it is a very bad move for interopebality. One of the basic rules of open source is that you dont fork an healthy project. The only reason to do that is when you want to do changes that would never fly with the current core team.
The "Do not evil" days of Google are really a thing of the past
Quote:
Originally Posted by mdriftmeyer
Google's splash with their multi-process architecture in WebKit got upstaged by a more scalable solution, WebKit2 designed by Apple.
If my understanding is correct, WebKit2 handles the process separation stuff for you, behind it's API, whereas the Google approach required you to do it yourself. If this is true I would expect most devs would stick with the Apple solution, to prevent reinventing the wheel.
Originally Posted by gwmac
I am just grateful to never visit a site anymore that says "Internet Explorer is required to view this site". As long as us Mac folks can continue to surf without being penalized as years ago I am all for speed and diversity of choice.
What Microsoft attempted to do with Internet Explorer was anathema to some of the very reasons why HTML and WWW were created, their attempt to subjugate the web to their software sadly almost succeeded. Microsoft were effectively taking www work and making internet explorer additions to it in an attempt to force the world to use their software.
I think the current situation, where different organisations implement their own rendering engines to process the widely agreed standards, has helped push innovation with access to the info on the internet (notably mobile) and thus made life easier for the world.
Therefore, it doesn't matter what rendering engine Google comes up with providing it's working on the same www code and languages as everybody else.
If they improve on the current tech and introduce newer tech... then I say its a good thing
"[blink] was widely derided as the worst HTML tag ever created and so we picked the name Blink because it kind of suits our slightly ironic taste in names. We called our browser Chrome because the whole idea was to minimize the chrome. We called our computer Pixel because we tried to make all the pixels disappear. Now, we are calling this rendering engine Blink because it doesn't support the blink tag." - Linus Upson (VP of engineering on Google’s Open Web Platform team)
see first comment there: http://readwrite.com/2013/04/03/google-announces-blink-its-own-rendering-engine-for-webkit
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?
To put it simply.
Apple wants to use WebKit as the engine for a Web Browser. (Safari)
Google wants to use Blink as the engine for an Operating System. (Chrome OS)
In theory. In practice, though, there are lots of ways around that. Look at 'Free' Android where they arbitrarily decide not to release some versions.
Exactly. Anyone who argues that this won't contribute to fragmentation has their eyes closed.
Wait a second. Your first paragraph highlights the dangers involved.
Then, in your second paragraph, you simply wave your hands and pretend that the dangers disappeared. Since Google arguably has more power over the Web than Microsoft did, it's not clear how you reached that conclusion. The risk is quite real.
All Google has to do is implement new tags in Adwords or the links that allow people to insert Google Maps into their page and everyone will be forced to use the new, non-standard tags. And if those tags are not part of the open source portion, then Google can keep them proprietary. Boom. Instant fragmentation (and nightmares for developers).
I imagine there would be applause all around? Perhaps it is understandable that a company that had the nerve to walk away from the floppy, the DVD and Flash would get more benefit of the doubt, whereas a company which has contributed to computer science at a level less comprehensible to the masses would have its motives questioned forever.
Since the Multi Process view from both are so different. If you read some of the thing Google is trying to do with Bink, they even want iframes to be in separated process. Just like how they handle Tabs. If you dont like having hundreds of process running, you are going to have even more! They want Blink to be more like a OS ( Chrome OS ? ), while Apple wanted WebKit2 to be more like um.... a small and embeddable browser engine that could be used for anything from Browsers to within Apps.
And my guess is that some of the things listed here
http://www.chromium.org/blink#architectural-changes
They already have a half baked copy done secretly behind Google's closed doors and ready to land in blink.
Quote:
Originally Posted by jragosta
In theory. In practice, though, there are lots of ways around that. Look at 'Free' Android where they arbitrarily decide not to release some versions.
Which part of the Android OS are you talking about? Wikipedia says Android is licensed under Apache License 2.0 which does not require you to release the source code even though you release the binary. The kernel (Linux) on the other hand, since it is GPL, require you to release the source code once you ship the binary.
For LGPL, it's similar to GPL in the sense that you need to release the source code when you ship the binary.
Quote:
Originally Posted by JamieLeSouef
you would have a problem because it has no competition, no competition leads to lack of innovation. Don't think for a second that just because something is Open Source that it's going to be innovative.. just look at open office!
You labor under a common misconception that competition and innovation have some sort of direct relationship. Don't think for a second that lack of competition hinders innovation -- in fact, the greatest innovation comes when people are creating something entirely new, where there is no competition at all -- or that competition spurs innovation -- just look at the Windows PC industry, where's the innovation there?
Innovation can occur when there's competition, and when there isn't. Competition can occur without innovation, or when it exists. But, to conclude that there's some sort of causal relationship between them is not only unfounded, but contrary to the available evidence.
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. ...
Please explain exactly how lack of standardization in browser behavior will,
a. be, "far better for consumers and the web in general," and
b. how having to develop for and test on yet another platform will, "[not] be bad [for developers."
Frankly, I can't see how you can support either of those statements. And, for those of you pointing to IE as an example of how "rendering engine monopolies" are harmful, the reason IE was bad for the web wasn't that everyone on Windows was using it and developers were ignoring other browsers. The reason it was bad was that it was a Windows only de facto standard, which is entirely contrary to the situation with WebKit, so analogies along those lines are entirely invalid.
http://prng.net/blink-faq.html
OK, so the short version of the story seems to be this:
Google takes other people's work, changes it a bit and calls it something else to make it look like they did it all.
Deja vu anyone?
HTML is a standard, WebKit is/was a monopoly.
What's the difference? Governance. Even an open source project is managed very differently from an open standard.
The problem with relying on one piece of software is that software architects have a tough time predicting the future. Software often becomes slow, bloated and crufty over time. Standards like HTML can be written and re-written very easily. Software doesn't have the same luxury. Having a newer alternative waiting in the wings is never a bad thing. It's a shame that the new alternative is controlled by one company though.
Quote:
Originally Posted by Evilution
OK, so the short version of the story seems to be this:
Google takes other people's work, changes it a bit and calls it something else to make it look like they did it all.
Deja vu anyone?
Google has been the top contributor to WebKit over the past couple of years.
Quote:
Originally Posted by SolipsismX
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.
Google has shown an antipathy toward standards lately, as evidenced by the whole WebM thing and their, albeit short lived, support for Flash on Android. If anything, they've shown themselves inclined to go down the same sort of paths as Microsoft by attempting to establish new de facto "standards" that they control. This all dovetails with Google's desire and intent to control access to all information on the Internet, to be the portal -- via search, email, Android, Chome, etc. -- that everyone must pass through to get to anything.
You should definitely expect to see Blink adding "extensions" that only work when the user is using Google technologies. And you should definitely expect Google to aggressively evangelize these extensions to developers. In fact, you should expect to see them attempt to create exactly the situation Microsoft had with IE, without being weighed down with a monopoly OS hanging around their necks.
That, by the way, is the analogy with IE that is correct in this situation.
1: embrace- adopt webkit
2: extend - fork
3: exterminate-?
nobody has tried that before, have they? Probably the only way to get more adoption of VP8
So Google has tried to exterminate Nitro and fragment JavaScript by creating V8?
WebKit is not a standard. It's an engine. Forking it does not change HTML and other code it renders. Imagine having a slightly different, but better kernel for an otherwise identical OS. If you truly think this will ruin the internet then you'll need to explain why that hasn't already happening with Google removing Nitro and replacing it with their V8 engine. Where is the total destruction of all things JavaScript?