Take a Left off WebKit onto Blink
April 3, 2013 6:23 PM Subscribe
Google is forking WebKit. WebKit was a fork of KHTML and now Google is creating a new fork called Blink. Opera will contribute to it and use it too. Vendor specific prefixes will no longer be supported.
Does this herald a resurgence of the much-loved blink tag?
posted by cccorlew at 6:27 PM on April 3, 2013 [18 favorites]
posted by cccorlew at 6:27 PM on April 3, 2013 [18 favorites]
Anyone have a good read on the motivations for this change vis-a-vis Google's long-term Chrome strategy?
I imagine that's got to be the motivation, and am curious where this falls on the "Don't Be Evil"-"Capitalism Is Predicated Upon Profits" spectrum...
posted by graphnerd at 6:31 PM on April 3, 2013
I imagine that's got to be the motivation, and am curious where this falls on the "Don't Be Evil"-"Capitalism Is Predicated Upon Profits" spectrum...
posted by graphnerd at 6:31 PM on April 3, 2013
graphnerd: from what I understand, Google has features that they want to do that juggling them into the code base with what Apple wants to causing a lot of heartache, such as engine-level multithreading. It basically boils down to time-to-market for them, since they seem to be on the release-a-new-version-every-month bandwagon.
posted by Old'n'Busted at 6:34 PM on April 3, 2013 [2 favorites]
posted by Old'n'Busted at 6:34 PM on April 3, 2013 [2 favorites]
Mozilla announced today that they are also working on a new browser engine. Interesting.
posted by stopgap at 6:34 PM on April 3, 2013 [1 favorite]
posted by stopgap at 6:34 PM on April 3, 2013 [1 favorite]
In very related news, Apple recently changed the Webkit commit policy to make an Apple employee the end gatekeeper and to periodically update code in an unhelpful dump-over-the-wall style.
Opera are also making the change to the Blink fork; this isn't a matter of Google choosing to screw over the rest of the Webkit community. It's quite possible that a majority of the Webkit-using companies will shift to Blink.
posted by jaduncan at 6:35 PM on April 3, 2013 [11 favorites]
Opera are also making the change to the Blink fork; this isn't a matter of Google choosing to screw over the rest of the Webkit community. It's quite possible that a majority of the Webkit-using companies will shift to Blink.
posted by jaduncan at 6:35 PM on April 3, 2013 [11 favorites]
And here I was just getting used to designing for Gecko and Webkit (especially with Opera moving to Webkit) and just kind of waving my hands a little in the general direction of recent versions of IE. It's been so much easier the last couple of years.
Ah well. Hopefully the new fork won't diverge too far from rendering CSS stuff the way Webkit does.
posted by stavrosthewonderchicken at 6:35 PM on April 3, 2013 [3 favorites]
Ah well. Hopefully the new fork won't diverge too far from rendering CSS stuff the way Webkit does.
posted by stavrosthewonderchicken at 6:35 PM on April 3, 2013 [3 favorites]
This is because all new browsers will have to render smells for the new iPhone.
posted by It's Raining Florence Henderson at 6:38 PM on April 3, 2013 [6 favorites]
posted by It's Raining Florence Henderson at 6:38 PM on April 3, 2013 [6 favorites]
Anyone have a good read on the motivations for this change vis-a-vis Google's long-term Chrome strategy?
They don't want their only real competition controlling the nuts and bolts of what makes their web browser work. Though this does introduce the interesting problem, in that Opera and Chrome on iOS are basically removing themselves from the platform, once they transition.
posted by Blazecock Pileon at 6:38 PM on April 3, 2013
They don't want their only real competition controlling the nuts and bolts of what makes their web browser work. Though this does introduce the interesting problem, in that Opera and Chrome on iOS are basically removing themselves from the platform, once they transition.
posted by Blazecock Pileon at 6:38 PM on April 3, 2013
TBH I suspect this will have a big impact on the close-to-the-bleeding-edge HTML5 demo crowd and very little on anyone else, and those guys are basically all about handwaving browser specific code into "standards" anyway.
posted by Artw at 6:39 PM on April 3, 2013 [5 favorites]
posted by Artw at 6:39 PM on April 3, 2013 [5 favorites]
More detail on the new Apple policy:
"I'm not sure they can contribute their improvements terribly easily. Apple changed their development policies recently to be fairly hostile to non-Apple users of Webkit; basically, developers are allowed to check in changes that break the build on non-Apple platforms (which is enough to make development elsewhere a pain on its own because it breaks git bisect), and commits - including ones to non-Apple platform code, even ones that fix the build - now require the approval of an Apple employee with no knowlege of other platform and no incentive to approve changes important to them promptly."
posted by jaduncan at 6:40 PM on April 3, 2013 [5 favorites]
"I'm not sure they can contribute their improvements terribly easily. Apple changed their development policies recently to be fairly hostile to non-Apple users of Webkit; basically, developers are allowed to check in changes that break the build on non-Apple platforms (which is enough to make development elsewhere a pain on its own because it breaks git bisect), and commits - including ones to non-Apple platform code, even ones that fix the build - now require the approval of an Apple employee with no knowlege of other platform and no incentive to approve changes important to them promptly."
posted by jaduncan at 6:40 PM on April 3, 2013 [5 favorites]
Opera and Chrome on iOS are basically removing themselves from the platform, once they transition.
Yeah, interesting point. I hadn't realized until I read recently that all third-party iOS browsers are basically skins on the safari-webkit renderer.
I wonder if this means that Apple might be headed towards opening that up. Probably not, given the way these things tend to go, but it seems like a pretty big deal for Google to just ditch Chrome on iOS.
posted by stavrosthewonderchicken at 6:42 PM on April 3, 2013
Yeah, interesting point. I hadn't realized until I read recently that all third-party iOS browsers are basically skins on the safari-webkit renderer.
I wonder if this means that Apple might be headed towards opening that up. Probably not, given the way these things tend to go, but it seems like a pretty big deal for Google to just ditch Chrome on iOS.
posted by stavrosthewonderchicken at 6:42 PM on April 3, 2013
Anyone have a good read on the motivations for this change vis-a-vis Google's long-term Chrome strategy?
Chrome does some things, like multi-process, very different than vanilla webkit. They have to support all of the webkit changes, which will especially hard with Apple's new policies. This will allow them not to have to do that.
Here is a perspective from a developer.
The good news is that all new features not compatible with the specs won't be enabled by default. This is a good thing for the open web, because it makes it much less likely for a monoculture to develop.
posted by zabuni at 6:42 PM on April 3, 2013 [1 favorite]
Chrome does some things, like multi-process, very different than vanilla webkit. They have to support all of the webkit changes, which will especially hard with Apple's new policies. This will allow them not to have to do that.
Here is a perspective from a developer.
The good news is that all new features not compatible with the specs won't be enabled by default. This is a good thing for the open web, because it makes it much less likely for a monoculture to develop.
posted by zabuni at 6:42 PM on April 3, 2013 [1 favorite]
Also check Mike West's comments on Hacker News, he's the developer advocate for Chrome, and he's been answering questions about blink.
posted by zabuni at 6:46 PM on April 3, 2013 [2 favorites]
posted by zabuni at 6:46 PM on April 3, 2013 [2 favorites]
To thicken the plot, Mozilla's new engine Servo is written in their (interesting!) programming language Rust, and Samsung is funding a port of it to ARM/Android.
posted by whir at 6:46 PM on April 3, 2013 [1 favorite]
posted by whir at 6:46 PM on April 3, 2013 [1 favorite]
If the iOS versions of Chrome and Opera are just skins on somebody else's program anyway, does this really change anything for them? They were developing two separate versions of the mobile app regardless.
posted by Holy Zarquon's Singing Fish at 6:47 PM on April 3, 2013 [1 favorite]
posted by Holy Zarquon's Singing Fish at 6:47 PM on April 3, 2013 [1 favorite]
Servo's been going on for a while though, and it's really experimental, as is Rust, which has seen a lot of change over the past year or so. But apparently Rust is supposed to keep relatively stable, language-wise, as they get towards 1.0 (0.6 was released today).
posted by Monday, stony Monday at 6:52 PM on April 3, 2013
posted by Monday, stony Monday at 6:52 PM on April 3, 2013
In very related news, Apple recently changed the Webkit commit policy to make an Apple employee the end gatekeeper and to periodically update code in an unhelpful dump-over-the-wall style.
This is only for the WebKit2 api layer, which google was not using.
All in all, this makes sense for google, but i don't think they'll be able to hold on to that promise to raise the bar on what new features go in. Historically, the chrome project employs a lot of people, and google engineers tend to get bored easily and try to get away from maintenance, leading them to implement whatever api is floating around, no matter how shit the design or how bad for the ecosystem. We'll see how long they hold this behavior off.
In my opinion, the web platform should move more slowly, not faster with a single player with ADHD and too much market share.
I'm at a point where i just like to grab the popcorn and watch the world burn.
posted by palbo at 6:53 PM on April 3, 2013 [9 favorites]
This is only for the WebKit2 api layer, which google was not using.
All in all, this makes sense for google, but i don't think they'll be able to hold on to that promise to raise the bar on what new features go in. Historically, the chrome project employs a lot of people, and google engineers tend to get bored easily and try to get away from maintenance, leading them to implement whatever api is floating around, no matter how shit the design or how bad for the ecosystem. We'll see how long they hold this behavior off.
In my opinion, the web platform should move more slowly, not faster with a single player with ADHD and too much market share.
I'm at a point where i just like to grab the popcorn and watch the world burn.
posted by palbo at 6:53 PM on April 3, 2013 [9 favorites]
If the iOS versions of Chrome and Opera are just skins on somebody else's program anyway, does this really change anything for them? They were developing two separate versions of the mobile app regardless.
As far as I understand it, you are correct. Alternative browsers on iOS are fairly limited at how far down into the plumbing they can go. Chrome is more or less a different product on iOS.
posted by Brak at 6:56 PM on April 3, 2013
As far as I understand it, you are correct. Alternative browsers on iOS are fairly limited at how far down into the plumbing they can go. Chrome is more or less a different product on iOS.
posted by Brak at 6:56 PM on April 3, 2013
Anyone have a good read on the motivations for this change vis-a-vis Google's long-term Chrome strategy?
"Google is the new Apple-and-Microsoft"
posted by DU at 6:58 PM on April 3, 2013 [3 favorites]
"Google is the new Apple-and-Microsoft"
posted by DU at 6:58 PM on April 3, 2013 [3 favorites]
I think Google is slowly realizing that they're big and skilled enough to act like a monopoly, and playing well with others is not longer a benefit.
posted by meowzilla at 7:11 PM on April 3, 2013 [4 favorites]
posted by meowzilla at 7:11 PM on April 3, 2013 [4 favorites]
As far as I understand it, you are correct. Alternative browsers on iOS are fairly limited at how far down into the plumbing they can go. Chrome is more or less a different product on iOS.
Yeah, there's absolutely no reason to think that because Chrome on PCs and Android uses Blink that they'd be forced to remove it from iOS. Google already made the compromises needed to get Chrome into the App Store.
Anyone have a good read on the motivations for this change vis-a-vis Google's long-term Chrome strategy?
In my opinion, Google wants to continue what Netscape started in the 90s: they want Chrome to be a fully baked app platform. They've already made a lot of progress. It's even possible at the moment to create applications on Chrome that run just about as fast as any regular desktop app using things like NaCl and WebGL.
Taking control of the rendering engine allows them to proceed further down this path. This is important to Google because they want people to spend as much time as possible in their browsers, instead of in applications. This is because the more you use the web, the more Google can make on ad impressions.
I don't think it's a stretch to guess that this is Google's long term strategy for Chrome, especially in light of Chrome OS.
posted by zixyer at 7:20 PM on April 3, 2013 [7 favorites]
Yeah, there's absolutely no reason to think that because Chrome on PCs and Android uses Blink that they'd be forced to remove it from iOS. Google already made the compromises needed to get Chrome into the App Store.
Anyone have a good read on the motivations for this change vis-a-vis Google's long-term Chrome strategy?
In my opinion, Google wants to continue what Netscape started in the 90s: they want Chrome to be a fully baked app platform. They've already made a lot of progress. It's even possible at the moment to create applications on Chrome that run just about as fast as any regular desktop app using things like NaCl and WebGL.
Taking control of the rendering engine allows them to proceed further down this path. This is important to Google because they want people to spend as much time as possible in their browsers, instead of in applications. This is because the more you use the web, the more Google can make on ad impressions.
I don't think it's a stretch to guess that this is Google's long term strategy for Chrome, especially in light of Chrome OS.
posted by zixyer at 7:20 PM on April 3, 2013 [7 favorites]
Maybe they are being evil, But Maybe they also noticed that pasting any decent amount of text into Gmail causes half a dozen slow or unresponsive script popups one after another.Maybe they realized Wave, cool as it seemed, was unusable because of performance issues.
If they want to be a software company, deliver cloud based apps like gmail and docs, they got to make sure their platform of choice, web browsers, is up to the task.
Mozilla and Apple do not share the same concerns.
posted by Ad hominem at 7:21 PM on April 3, 2013 [4 favorites]
If they want to be a software company, deliver cloud based apps like gmail and docs, they got to make sure their platform of choice, web browsers, is up to the task.
Mozilla and Apple do not share the same concerns.
posted by Ad hominem at 7:21 PM on April 3, 2013 [4 favorites]
Anyone have a good read on the motivations for this change vis-a-vis Google's long-term Chrome strategy?
Plus Google hates Apple, in case anyone forgot that.
posted by wenestvedt at 7:27 PM on April 3, 2013
Plus Google hates Apple, in case anyone forgot that.
posted by wenestvedt at 7:27 PM on April 3, 2013
Google, Apple and Microsoft are the Google, Apple and Microsoft.
posted by Artw at 7:34 PM on April 3, 2013 [4 favorites]
posted by Artw at 7:34 PM on April 3, 2013 [4 favorites]
This was posted to twitter earlier: I don't know enough about the project and the people involved to vet it, but if true it would show that hostile feelings go back quite a while between the two, and that multi-core support conflicting was possibly Google's fault.
posted by Canageek at 7:36 PM on April 3, 2013
posted by Canageek at 7:36 PM on April 3, 2013
I've kind of been afraid of what would happen if Google pulled the plug on Mozilla's funding, partially because Rust and Servo are way, way too cool to just let die. So I'm happy as a clam on crack that Samsung is also funding Rust and Servo. Now we just need a similar benefactor for MDN, and all will be well.
posted by a snickering nuthatch at 7:50 PM on April 3, 2013 [1 favorite]
posted by a snickering nuthatch at 7:50 PM on April 3, 2013 [1 favorite]
My god Rust is so much more readable than I was expecting! I've become inured to newer functional languages (Haskell!) abstracting a lot of FP power without a *natural* narrative, so to speak. Yes, I read code as narratives, and all the algebra-expression-like statements don't help one bit.
Rust simply doesn't do that. Has a lot of Haskell-like stuff (lists!) without cumbersome syntax. It's a breath of fresh air; it's like someone dropping Pink Floyd references in a boring academic paper or something.
posted by the cydonian at 7:55 PM on April 3, 2013 [4 favorites]
Rust simply doesn't do that. Has a lot of Haskell-like stuff (lists!) without cumbersome syntax. It's a breath of fresh air; it's like someone dropping Pink Floyd references in a boring academic paper or something.
posted by the cydonian at 7:55 PM on April 3, 2013 [4 favorites]
So I'm happy as a clam on crack that Samsung is also funding Rust and Servo. Now we just need a similar benefactor for MDN, and all will be well.
It is good news for the Rust/Servo community that an entity as large as Samsung is involved.
Benefactor for MDN? Do you perceive there being a need for non-Mozilla support?
(I work for Mozilla but not on Rust, Servo or MDN.)
posted by gen at 7:59 PM on April 3, 2013
It is good news for the Rust/Servo community that an entity as large as Samsung is involved.
Benefactor for MDN? Do you perceive there being a need for non-Mozilla support?
(I work for Mozilla but not on Rust, Servo or MDN.)
posted by gen at 7:59 PM on April 3, 2013
?!
posted by limeonaire at 8:01 PM on April 3, 2013 [2 favorites]
posted by limeonaire at 8:01 PM on April 3, 2013 [2 favorites]
Ever think about how much further along mobile technology would be if it wasn't completely split between two companies that hate each other and make far-reaching decisions solely to fuck each other over? I mean, you can't tell me there's any tech reason for this and it's not just another Google-Apple pissing match.
posted by DecemberBoy at 8:13 PM on April 3, 2013 [2 favorites]
posted by DecemberBoy at 8:13 PM on April 3, 2013 [2 favorites]
Benefactor for MDN? Do you perceive there being a need for non-Mozilla support?
If Google didn't renew Mozilla's search revenue contract, how would Mozilla survive and what would the remnants of the org prioritize? I have no idea. Thinking about that more and more over the last couple months, and it's made me consider donating to Mozilla despite not having a lot to give.
Rust and Servo have a lot of potential, but MDN is already kicking ass and it's another important torch that someone should carry even if circumstances at some point dictate that Mozilla can't afford to.
posted by a snickering nuthatch at 8:15 PM on April 3, 2013
If Google didn't renew Mozilla's search revenue contract, how would Mozilla survive and what would the remnants of the org prioritize? I have no idea. Thinking about that more and more over the last couple months, and it's made me consider donating to Mozilla despite not having a lot to give.
Rust and Servo have a lot of potential, but MDN is already kicking ass and it's another important torch that someone should carry even if circumstances at some point dictate that Mozilla can't afford to.
posted by a snickering nuthatch at 8:15 PM on April 3, 2013
Ever think about how much further along mobile technology would be if it wasn't completely split between two companies that hate each other and make far-reaching decisions solely to fuck each other over? I mean, you can't tell me there's any tech reason for this and it's not just another Google-Apple pissing match.
It doesn't hurt anyone to fork it. This is how open source is supposed to work. It's also how capitalism is supposed to work. The alternative would be a monopoly, which is what we had when IE was the only game in town.
posted by empath at 8:16 PM on April 3, 2013 [4 favorites]
It doesn't hurt anyone to fork it. This is how open source is supposed to work. It's also how capitalism is supposed to work. The alternative would be a monopoly, which is what we had when IE was the only game in town.
posted by empath at 8:16 PM on April 3, 2013 [4 favorites]
Oh, cool, more css vendor specific properties, that should make things far more easier for all of us. Four was certainly not enough.
posted by alex_skazat at 8:20 PM on April 3, 2013 [1 favorite]
posted by alex_skazat at 8:20 PM on April 3, 2013 [1 favorite]
Yeah, I don't know what all the "hostile fork" rhetoric on HN is about. This shit is all GPL, even if it takes effort to merge changes between forks there is always someone up to the challenge. It's a "bazaar" right?
posted by Ad hominem at 8:25 PM on April 3, 2013
posted by Ad hominem at 8:25 PM on April 3, 2013
alex_skazat, as linked by the FPP, the Blink team has declared their intent to not deploy vendor prefixes.
posted by RichardP at 8:26 PM on April 3, 2013
posted by RichardP at 8:26 PM on April 3, 2013
I'm not sure what this "hostile fork" bit is about myself, either. If someone doesn't want to contribute (license-compatible) code upstream but you want it, you adopt it in-house. That's just called a fork. The only reason you don't adopt it is because you think it smells bad or there's license/IP/political shenanigans going on in the original fork. I don't know the multiprocessor code in webkit or chrome, so I have no idea which of these apply.
posted by introp at 8:37 PM on April 3, 2013
posted by introp at 8:37 PM on April 3, 2013
It doesn't hurt anyone to fork it. This is how open source is supposed to work. It's also how capitalism is supposed to work. The alternative would be a monopoly, which is what we had when IE was the only game in town.
Indeed. Corollary: these companies are in business to make money, not just to piss in each others' ears. Let's say for the sake of argument that Apple begged Google to push their multiprocess architecture back to WebKit and Google flat-out refused. If it's that good, then that's a sound business decision. And, in that light, it was a sound business decision to fork WebKit when supporting that multiprocess architecture got to be too painful. This introduces healthy challenges to the ecosystem.
It's sort of like the maps debacle from awhile back. People were divided into Apple sucks/Google sucks camps, but the reality was understandable from either side (I want turn-by-turn and vector tiles/I want identifiable user data and branding). The split was a question of when, not if. Splitting off mapping lit a fire under both companies, which means a not-entirely-bump-free road to improvement across the board.
This introduces competition, which means everyone wins, long run.
posted by middleclasstool at 8:39 PM on April 3, 2013 [1 favorite]
Indeed. Corollary: these companies are in business to make money, not just to piss in each others' ears. Let's say for the sake of argument that Apple begged Google to push their multiprocess architecture back to WebKit and Google flat-out refused. If it's that good, then that's a sound business decision. And, in that light, it was a sound business decision to fork WebKit when supporting that multiprocess architecture got to be too painful. This introduces healthy challenges to the ecosystem.
It's sort of like the maps debacle from awhile back. People were divided into Apple sucks/Google sucks camps, but the reality was understandable from either side (I want turn-by-turn and vector tiles/I want identifiable user data and branding). The split was a question of when, not if. Splitting off mapping lit a fire under both companies, which means a not-entirely-bump-free road to improvement across the board.
This introduces competition, which means everyone wins, long run.
posted by middleclasstool at 8:39 PM on April 3, 2013 [1 favorite]
Will one of these fix animated GIF stopping? That right there is my main will-you-fuckers-get-shit-in-order issue with Webkit-based browsers right now.
posted by mephron at 8:42 PM on April 3, 2013 [1 favorite]
posted by mephron at 8:42 PM on April 3, 2013 [1 favorite]
For a nice sarcastic view on this, http://prng.net/blink-faq.html.
posted by xiw at 8:45 PM on April 3, 2013 [12 favorites]
posted by xiw at 8:45 PM on April 3, 2013 [12 favorites]
Don't blink. Blink and you're dead.
posted by dirigibleman at 8:53 PM on April 3, 2013 [1 favorite]
posted by dirigibleman at 8:53 PM on April 3, 2013 [1 favorite]
meowzilla: "I think Google is slowly realizing that they're big and skilled enough to act like a monopoly, and playing well with others is not longer a benefit."
Pretty sure that's Apple you're thinking about.
Among other things, if Google didn't like their browser's competition, they'd probably stop funding Mozilla. Google has a vested interest in keeping web browser technology on the cutting-edge, but they don't gain much by making their browser the most popular one, if the competitors are only one or two steps behind.
That said, Google's displaying a rather strong case of "Not Invented Here" syndrome, even between its own divisions. That's one heck of a dangerous road to travel down. Remember how Microsoft (still) can't convince half of its own employees to write new code in .NET?
At least they're leaving the prefix baggage behind them, and it doesn't look like they're actually going to push for AngularJS to be adopted as web standard (yet). The last thing we need is for the internet to shard into a Google Internet, a Microsoft Internet, and a Mozilla Internet
The whole thing will be open-source, and while Google's OSS community participation has a lot of room for improvement (AOSP is a bloody mess), they've done an OK job with Chromium. Definitely a bit better than Apple has done for the past few years.
We'll see if this fork is actually hostile -- the two projects may very well choose to continue to share relevant bits of code with each other. The Blink project page lays out a fairly good technical case for why it's time for Chromium and Webkit to part ways. It sounds like it's currently a nightmare to maintain a rendering engine that's compatible with several multiprocess models and JavaScript implementations.
On the other hand, Apple may very well choose to ignore Blink out of spite -- there's certainly a lot of precedent for that as well -- the libav guys still have an unreasonably huge grudge against ffmpeg, and are notorious for refusing to accept any patches from upstream.
posted by schmod at 8:54 PM on April 3, 2013 [6 favorites]
Pretty sure that's Apple you're thinking about.
Among other things, if Google didn't like their browser's competition, they'd probably stop funding Mozilla. Google has a vested interest in keeping web browser technology on the cutting-edge, but they don't gain much by making their browser the most popular one, if the competitors are only one or two steps behind.
That said, Google's displaying a rather strong case of "Not Invented Here" syndrome, even between its own divisions. That's one heck of a dangerous road to travel down. Remember how Microsoft (still) can't convince half of its own employees to write new code in .NET?
At least they're leaving the prefix baggage behind them, and it doesn't look like they're actually going to push for AngularJS to be adopted as web standard (yet). The last thing we need is for the internet to shard into a Google Internet, a Microsoft Internet, and a Mozilla Internet
The whole thing will be open-source, and while Google's OSS community participation has a lot of room for improvement (AOSP is a bloody mess), they've done an OK job with Chromium. Definitely a bit better than Apple has done for the past few years.
We'll see if this fork is actually hostile -- the two projects may very well choose to continue to share relevant bits of code with each other. The Blink project page lays out a fairly good technical case for why it's time for Chromium and Webkit to part ways. It sounds like it's currently a nightmare to maintain a rendering engine that's compatible with several multiprocess models and JavaScript implementations.
On the other hand, Apple may very well choose to ignore Blink out of spite -- there's certainly a lot of precedent for that as well -- the libav guys still have an unreasonably huge grudge against ffmpeg, and are notorious for refusing to accept any patches from upstream.
posted by schmod at 8:54 PM on April 3, 2013 [6 favorites]
xiw: "For a nice sarcastic view on this, http://prng.net/blink-faq.html."
I'm completely baffled by this reaction. How on earth do Apple come across as the "good guys" in this situation?
Has "plays nicely with others" ever been a phrase that could be used to accurately describe Apple? I own a number of Apple products, and they're all brilliant. However, my employers are (rightly) concerned about using Macs in our business, because Apple are the most opaque and unpredictable organization on the planet. They've been known to drop products, standards, or APIs at the drop of a hat (QuickTime X and its underlying API introduced several huge regressions that are still causing us a world of pain -- 4 years later, and the problems have still not been fixed).
Let's also not forget that Apple started the entire vendor prefix nightmare.
Google are not always the good guys, but when it comes to browsers and web standards, I'm going to trust Google a lot more than I'm going to trust Apple.
posted by schmod at 9:09 PM on April 3, 2013 [6 favorites]
I'm completely baffled by this reaction. How on earth do Apple come across as the "good guys" in this situation?
Has "plays nicely with others" ever been a phrase that could be used to accurately describe Apple? I own a number of Apple products, and they're all brilliant. However, my employers are (rightly) concerned about using Macs in our business, because Apple are the most opaque and unpredictable organization on the planet. They've been known to drop products, standards, or APIs at the drop of a hat (QuickTime X and its underlying API introduced several huge regressions that are still causing us a world of pain -- 4 years later, and the problems have still not been fixed).
Let's also not forget that Apple started the entire vendor prefix nightmare.
Google are not always the good guys, but when it comes to browsers and web standards, I'm going to trust Google a lot more than I'm going to trust Apple.
posted by schmod at 9:09 PM on April 3, 2013 [6 favorites]
Google are not always the good guys, but when it comes to browsers and web standards, I'm going to trust Google a lot more than I'm going to trust Apple.
Apple would replace the entire internet with apple approved content on Apple owned servers and make it only accessible from Apple hardware if they could get away with it.
posted by empath at 9:22 PM on April 3, 2013 [4 favorites]
Apple would replace the entire internet with apple approved content on Apple owned servers and make it only accessible from Apple hardware if they could get away with it.
posted by empath at 9:22 PM on April 3, 2013 [4 favorites]
I remember someone talking about Apple giving Adobe the brush off in the late 80s / early 90s on some kind of API deprecation to which they objected at a time when Adobe products were basically the killer app driving people to Apple. As for the standards they have put in place, they've often kept them proprietary and never delivered usable implementations on other platforms (Quicktime I'm looking at you). I have no illusions that Google have my interests at heart, but Apple is the proverbial scorpion on the frog's back.
posted by BrotherCaine at 9:34 PM on April 3, 2013
posted by BrotherCaine at 9:34 PM on April 3, 2013
The more things change, the more they stay the same. At least they're not forking ie5
posted by blue_beetle at 9:55 PM on April 3, 2013
posted by blue_beetle at 9:55 PM on April 3, 2013
Oooh so much much I want to contribute to this discussion but probably shouldn't because work legal stuff.
I guess I can say that webkit is where it is because of a large number of contributors over the years (khtml, apple, nokia, google, blackberry, trolltech various other companies and individual contributors) and that it wouldn't be where it is without all those parties contributing and agreeing to work together. Everybody gained something from it. So when the situation gets simplified to that extent of just X screwing over Y, it really overlooks how complex the situation is technically, politically and historically and also misses out a whole other set of players. Essentially, every company wants to put out the best product so they need to balance moving forward with new features or improvements, protecting their advantages, contributing enough so that other companies are compelled to contribute (so they can get those advantages too and legal reasons) and somehow work together to ensure that the web standards don't fragment too much because then everyone loses. It was probably inevitable that the status quo wouldn't last forever.
Its going to take a while for the whole thing to shake out. Its the wild wild west out there and the sands are constantly shifting.
posted by captaincrouton at 10:00 PM on April 3, 2013 [4 favorites]
I guess I can say that webkit is where it is because of a large number of contributors over the years (khtml, apple, nokia, google, blackberry, trolltech various other companies and individual contributors) and that it wouldn't be where it is without all those parties contributing and agreeing to work together. Everybody gained something from it. So when the situation gets simplified to that extent of just X screwing over Y, it really overlooks how complex the situation is technically, politically and historically and also misses out a whole other set of players. Essentially, every company wants to put out the best product so they need to balance moving forward with new features or improvements, protecting their advantages, contributing enough so that other companies are compelled to contribute (so they can get those advantages too and legal reasons) and somehow work together to ensure that the web standards don't fragment too much because then everyone loses. It was probably inevitable that the status quo wouldn't last forever.
Its going to take a while for the whole thing to shake out. Its the wild wild west out there and the sands are constantly shifting.
posted by captaincrouton at 10:00 PM on April 3, 2013 [4 favorites]
they've often kept them proprietary and never delivered usable implementations on other platforms (Quicktime I'm looking at you)
Steve Jobs bragging about iTunes for Windows almost made blood squirt out of my eyes.
posted by benzenedream at 10:00 PM on April 3, 2013 [3 favorites]
Steve Jobs bragging about iTunes for Windows almost made blood squirt out of my eyes.
posted by benzenedream at 10:00 PM on April 3, 2013 [3 favorites]
I mean, you can't tell me there's any tech reason for this and it's not just another Google-Apple pissing match.
WebKit is apple's fork of the KDE project khtml, with a whole bunch of apple specific bits bolted on for OSX and iOS. Webkit itself is made up of three parts - webcore, which renders html; a javascript engine (aka nitro); and the api to actually use it in a browser (WebKit2). Chrome only uses webcore - they have their own api, and javascript engine (V8).
There's a load of WebKit2 specific bits running through webcore that google doesn't need or use - including the multiprocess stuff and sandboxing.
Google have finally reached the point where code bloat (from their point of view) in webcore isn't worth the hassle of staying in sync with upstream, so they're forking it. They say they're able to now delete some 7000 files and 4.5 million lines of code that they no longer need in blink to support WebKit2 - that they don't use.
Going the other way, this should free up the WebKit project from having to check they're not breaking chrome with every commit to WebCore, and also mean they can slim down their codebase.
The actual rendering code in webcore is relatively mature, and I don't see that itself changing in any substantial way in the immediate future. It's all the hooks into it, the front end, and the javascript engines in particular that have been getting all the love (v8 for google, nitro for apple).
To be fair to both apple and google, and the many other projects that integrate various bits of WebKit and contribute back, it's been a very successful open source project, remarkably free of territorial bullshit for what could have been a complete omnishambles. Though a certain desire to finally murder IE6 probably had something to do with it...
Blink will be under the LGPL, same as webkit, so if either side makes worthwhile changes to webcore that isn't api specific, they can easily port them back and forth. This isn't a hostile fork to try and take over the original market - it's a fork because final project objectives diverge, and the cost of sharing a codebase is higher than going separately.
There won't be separate chrome or blink rendering tags, and they intend to stick to web standards (google unsurprisingly likes everyone using standards, being arguably the world's biggest web development company).
As forks go, I see this as primarily one driven by technical need, not a political one.
posted by ArkhanJG at 10:07 PM on April 3, 2013 [20 favorites]
WebKit is apple's fork of the KDE project khtml, with a whole bunch of apple specific bits bolted on for OSX and iOS. Webkit itself is made up of three parts - webcore, which renders html; a javascript engine (aka nitro); and the api to actually use it in a browser (WebKit2). Chrome only uses webcore - they have their own api, and javascript engine (V8).
There's a load of WebKit2 specific bits running through webcore that google doesn't need or use - including the multiprocess stuff and sandboxing.
Google have finally reached the point where code bloat (from their point of view) in webcore isn't worth the hassle of staying in sync with upstream, so they're forking it. They say they're able to now delete some 7000 files and 4.5 million lines of code that they no longer need in blink to support WebKit2 - that they don't use.
Going the other way, this should free up the WebKit project from having to check they're not breaking chrome with every commit to WebCore, and also mean they can slim down their codebase.
The actual rendering code in webcore is relatively mature, and I don't see that itself changing in any substantial way in the immediate future. It's all the hooks into it, the front end, and the javascript engines in particular that have been getting all the love (v8 for google, nitro for apple).
To be fair to both apple and google, and the many other projects that integrate various bits of WebKit and contribute back, it's been a very successful open source project, remarkably free of territorial bullshit for what could have been a complete omnishambles. Though a certain desire to finally murder IE6 probably had something to do with it...
Blink will be under the LGPL, same as webkit, so if either side makes worthwhile changes to webcore that isn't api specific, they can easily port them back and forth. This isn't a hostile fork to try and take over the original market - it's a fork because final project objectives diverge, and the cost of sharing a codebase is higher than going separately.
There won't be separate chrome or blink rendering tags, and they intend to stick to web standards (google unsurprisingly likes everyone using standards, being arguably the world's biggest web development company).
As forks go, I see this as primarily one driven by technical need, not a political one.
posted by ArkhanJG at 10:07 PM on April 3, 2013 [20 favorites]
Ad hominem:
Yeah, I don't know what all the "hostile fork" rhetoric on HN is about. This shit is all GPL, even if it takes effort to merge changes between forks there is always someone up to the challenge. It's a "bazaar" right?
(or were you being ironical?)
Wasn't there a recent (MeFiHaterade) post about Evgeny Morozov regarding exactly this?
posted by graphnerd at 10:19 PM on April 3, 2013
Yeah, I don't know what all the "hostile fork" rhetoric on HN is about. This shit is all GPL, even if it takes effort to merge changes between forks there is always someone up to the challenge. It's a "bazaar" right?
(or were you being ironical?)
Wasn't there a recent (MeFiHaterade) post about Evgeny Morozov regarding exactly this?
posted by graphnerd at 10:19 PM on April 3, 2013
As forks go, I see this as primarily one driven by technical need, not a political one.
Man. I'd love to believe that, but I'm too debased by tribalist brand identification to accept a narrative that doesn't end with me calling someone a shitbird.
posted by mph at 10:36 PM on April 3, 2013 [8 favorites]
Man. I'd love to believe that, but I'm too debased by tribalist brand identification to accept a narrative that doesn't end with me calling someone a shitbird.
posted by mph at 10:36 PM on April 3, 2013 [8 favorites]
(or were you being ironical?)
As much as I dislike ESR, I think he was right about about the Bazaar. KHTML started life as part of the help system for KDE no? To give users unfamiliar with Linux something friendlier than man. Hundreds, or thousands, of contributors got it to the point where Google and Apple could squabble over it.
Everyone working on forks has to make the source available right? I don't buy the argument that Google is trying to sabotage Apple somehow, how they going to sabotage WebKit when the source is there for all to see. What incentive goes Google, or anyone else, have to ignore improvements that may live in other forks.
posted by Ad hominem at 11:12 PM on April 3, 2013
As much as I dislike ESR, I think he was right about about the Bazaar. KHTML started life as part of the help system for KDE no? To give users unfamiliar with Linux something friendlier than man. Hundreds, or thousands, of contributors got it to the point where Google and Apple could squabble over it.
Everyone working on forks has to make the source available right? I don't buy the argument that Google is trying to sabotage Apple somehow, how they going to sabotage WebKit when the source is there for all to see. What incentive goes Google, or anyone else, have to ignore improvements that may live in other forks.
posted by Ad hominem at 11:12 PM on April 3, 2013
One of the things google say they want to play with longer term is tying the DOM tighter into their javascript engine, V8, specifically the JIT part and even reimplementing the DOM code itself in javascript - that's a pretty big conceptual change to the DOM handler stuff in webcore, and would probably necessitate a fork all by itself.
For non web developers, the DOM is basically the layout. The html/xhtml that makes up a webpage is basically a load of bits of data (headings, paragraphs, images, links etc etc) with all the relationships and the styling calculated, then laid out in the DOM. To all intents and purposes, the DOM IS the webpage from the point of view of the browser, or at least the javascript part of it.
Back in the day, when webpages were mostly static, you'd render the DOM from the html, trying to stick to web standards and cope with faulty html (which is depressingly common) and you were pretty much done - and that was the job of webcore - then you'd maybe tweak little bits of it with javascript afterwards. Now of course, javascript is used heavily to alter the DOM on the fly constantly, using libraries like jquery for convenience - all the fancy web-app stuff is constantly changing the DOM, and thus how the page actually works; every time you do something, or something happens in the background, and the browser then has to display your changed DOM. Half the time, most of the page isn't even there when you start, it's a largely empty framework that is then populated with data pulled out of a database of some sort via javascript in your browser, that then manipulates the DOM to insert it on the fly, with all the heavy lifting being done on your own computer.
It's an alternative to the very common server side scripting (such as PHP) where the server works out first what the page should look like, puts it all together, and serves it up as a fairly static page for your browser to render. You can of course combine the two, and end up with some very clever webpages that act a lot more like conventional programs than just a static page of texts and links, and this an area that google is doing an awful lot - just look at google maps, or gmail.
Tighter integration between the DOM code and the javascript engine makes a lot of sense, especially when you consider how many HTML5 apps are out there (either hosted on their own servers, or run entirely in the browser, such as the chrome app store) - not least Google's own. Microsoft are doing something similar with Trident aka Internet Explorer. Given chrome uses a different javascript engine to webkit though, that's going to be a mess trying to integrate in webcore to either project's satisfaction, so a fork does make sense under those circumstances.
posted by ArkhanJG at 11:19 PM on April 3, 2013 [10 favorites]
For non web developers, the DOM is basically the layout. The html/xhtml that makes up a webpage is basically a load of bits of data (headings, paragraphs, images, links etc etc) with all the relationships and the styling calculated, then laid out in the DOM. To all intents and purposes, the DOM IS the webpage from the point of view of the browser, or at least the javascript part of it.
Back in the day, when webpages were mostly static, you'd render the DOM from the html, trying to stick to web standards and cope with faulty html (which is depressingly common) and you were pretty much done - and that was the job of webcore - then you'd maybe tweak little bits of it with javascript afterwards. Now of course, javascript is used heavily to alter the DOM on the fly constantly, using libraries like jquery for convenience - all the fancy web-app stuff is constantly changing the DOM, and thus how the page actually works; every time you do something, or something happens in the background, and the browser then has to display your changed DOM. Half the time, most of the page isn't even there when you start, it's a largely empty framework that is then populated with data pulled out of a database of some sort via javascript in your browser, that then manipulates the DOM to insert it on the fly, with all the heavy lifting being done on your own computer.
It's an alternative to the very common server side scripting (such as PHP) where the server works out first what the page should look like, puts it all together, and serves it up as a fairly static page for your browser to render. You can of course combine the two, and end up with some very clever webpages that act a lot more like conventional programs than just a static page of texts and links, and this an area that google is doing an awful lot - just look at google maps, or gmail.
Tighter integration between the DOM code and the javascript engine makes a lot of sense, especially when you consider how many HTML5 apps are out there (either hosted on their own servers, or run entirely in the browser, such as the chrome app store) - not least Google's own. Microsoft are doing something similar with Trident aka Internet Explorer. Given chrome uses a different javascript engine to webkit though, that's going to be a mess trying to integrate in webcore to either project's satisfaction, so a fork does make sense under those circumstances.
posted by ArkhanJG at 11:19 PM on April 3, 2013 [10 favorites]
For a nice sarcastic view on this, http://prng.net/blink-faq.html.
It's a decent, if droll checklist to keep an eye on.
posted by Blazecock Pileon at 11:39 PM on April 3, 2013
It's a decent, if droll checklist to keep an eye on.
posted by Blazecock Pileon at 11:39 PM on April 3, 2013
alex_skazat, as linked by the FPP, the Blink team has declared their intent to not deploy vendor prefixes.
Oh, yeah - let's trust Google on that one, I'm sure they won't do anything surprising or upsetting or against their users.
posted by alex_skazat at 11:46 PM on April 3, 2013 [1 favorite]
Oh, yeah - let's trust Google on that one, I'm sure they won't do anything surprising or upsetting or against their users.
posted by alex_skazat at 11:46 PM on April 3, 2013 [1 favorite]
The fact that we have JS, that gets compiled to bytecode, that gets JITed, and some engines use whole-method JITing and some use trace JITing, so we have no bytecode standard for the one janguage we are allowed to use,JS, is very amusing to me.
Everyone comes up with a way to run bytecode in a browser, Java applets, Silverlight, NaCL, and other people plug along putting more and more tricks into JS compilers and make them work. It is like the poor guys that invented RISC only to have Intel implement micro-ops and decomposition for CISC. Still Run your 20 year old programs and still make them faster.
posted by Ad hominem at 11:49 PM on April 3, 2013
Everyone comes up with a way to run bytecode in a browser, Java applets, Silverlight, NaCL, and other people plug along putting more and more tricks into JS compilers and make them work. It is like the poor guys that invented RISC only to have Intel implement micro-ops and decomposition for CISC. Still Run your 20 year old programs and still make them faster.
posted by Ad hominem at 11:49 PM on April 3, 2013
Oh, cool, more css vendor specific properties, that should make things far more easier for all of us. Four was certainly not enough.
If there's anybody to blame for vendor-specific prefixes, Google is not who I'm pointing fingers at.
posted by kmz at 12:21 AM on April 4, 2013 [2 favorites]
If there's anybody to blame for vendor-specific prefixes, Google is not who I'm pointing fingers at.
posted by kmz at 12:21 AM on April 4, 2013 [2 favorites]
Since the announcement of Dart, I've figured Google's long game is to make sure their apps run better and faster on Chrome than anything else so that all their app users end up on Chrome and thus even further entrenched in the Google ecosystem.
This announcement doesn't discourage me in thinking this, despite the FAQ's denials.
And I can't really blame them -- they'd actually be kind of nuts to leave themselves in a position in which other browser-makers could try to do the same to Google's disadvantage.
posted by Zed at 12:40 AM on April 4, 2013
This announcement doesn't discourage me in thinking this, despite the FAQ's denials.
And I can't really blame them -- they'd actually be kind of nuts to leave themselves in a position in which other browser-makers could try to do the same to Google's disadvantage.
posted by Zed at 12:40 AM on April 4, 2013
Here is the source
I been hearing some disturbing rumors the name comes from the Doctor Who episode of the same name. That google likens themselves to the Weeping Angels, if you take your eyes off them you end up in the past. Maybe this is more nefarious than it seems.
by rumors I mean jokes
posted by Ad hominem at 12:45 AM on April 4, 2013
I been hearing some disturbing rumors the name comes from the Doctor Who episode of the same name. That google likens themselves to the Weeping Angels, if you take your eyes off them you end up in the past. Maybe this is more nefarious than it seems.
by rumors I mean jokes
posted by Ad hominem at 12:45 AM on April 4, 2013
I got to 'Google is forking' and thought "JESUS CHRIST, ITS THE RAPTURE OF THE NERDS ALREADY" only to have that balloon of hopedrogen popped by the cruel pin of WebKit.
posted by Slackermagee at 12:47 AM on April 4, 2013
posted by Slackermagee at 12:47 AM on April 4, 2013
I found this informative -> Leaked internal google dart email. Making web app development, maintenance, performance and security not suck, compared to present and future iterations of iOS, is critically important for Google. Maybe Google is also going to use this technology to try and relaunch a more semantic web.
posted by vicx at 1:32 AM on April 4, 2013
posted by vicx at 1:32 AM on April 4, 2013
I'm not too clear on what multiprocess code does, but if it's what's at the heart of Safari's idiotic new dialog box "Webpages are not responding. To go back, all tabs and windows must be force reloaded", I'm all for forking it. Whatever problem they were looking to solve, they did it wrong.
I'd use Chrome instead, but it sure seems to be married to the concept of tabs, and ugly ones at that.
posted by scrowdid at 2:02 AM on April 4, 2013 [1 favorite]
I'd use Chrome instead, but it sure seems to be married to the concept of tabs, and ugly ones at that.
posted by scrowdid at 2:02 AM on April 4, 2013 [1 favorite]
Opera's involvement in this is what gives me comfort. Opera won't let Google treat AngularJS and whatever as first class citizens, right? Right?!
posted by the cydonian at 2:10 AM on April 4, 2013 [1 favorite]
posted by the cydonian at 2:10 AM on April 4, 2013 [1 favorite]
It's worth noting that Chrome and Safari (and other WebKit ports) already had some very big differences, and only the absolute core HTML layout engine is shared between all the ports.
posted by grahamparks at 2:11 AM on April 4, 2013
posted by grahamparks at 2:11 AM on April 4, 2013
Opera's involvement in this is what gives me comfort. Opera won't let Google treat AngularJS and whatever as first class citizens, right? Right?!
At this juncture, Opera is "involved" with Google, in roughly the same way a remora is "involved" with a shark.
posted by Thorzdad at 4:57 AM on April 4, 2013 [3 favorites]
At this juncture, Opera is "involved" with Google, in roughly the same way a remora is "involved" with a shark.
posted by Thorzdad at 4:57 AM on April 4, 2013 [3 favorites]
> If there's anybody to blame for vendor-specific prefixes, Google is not who I'm pointing fingers at.
Vendor prefixes were a best-possible solution at the time. Pending HTML and CSS standards had become entrenched in perpetual proposal state, with no meaningful changes, for years (CSS 3 has been in draft mode since 1999). Browsers were more heavily forked than they are these days: IE 6 was the major market shareholder and blatantly obsolete already, Safari was new, fast, but with all kinds of quirks, Firefox was the technology leader but weirdly non-progressive (in hindsight) with regards to potential front-end technologies.
The only way to emulate progress without forking the web entirely was to either ignore standards or hack them. Vendor-specific prefixes were a useful means for doing that (a dashed prefix is permissible, per the standards), and was a hell of an improvement over Microsoft's Conditional Commenting, since your new CSS rules could be inlined into your usual document rather than having to be an exception that you had to test for handling.
In the mid-00s, almost every new CSS behavior that we take for granted were things I first saw announced as a -webkit- vendor rule. Most of them, background-gradient aside, exist intact in the HTML5 moving target of a "standard". Some of the rest (fonts, some pseudoclasses) derive directly from what Microsoft shipped as proprietary in the late 90s.
These days? There's no real point for vendor prefixes -- current versions of every major browser use the same syntax for every CSS rule that's not purely experimental. Except that it's a fool's game trying to remember which browser finally supports prettypattern:foo; with or without their proprietary prefix -- Firefox is going to support -moz-prettypattern:foo; as well as prettypattern:foo:, but maybe Webkit only supports -webkit-prettypattern:foo;? Shit, I can't remember. So I macro that fucker in SASS (which, honestly, is way more evil than vendor prefixes are) and stop treating it as a distraction.
Blink's ditching vendor prefixes is more of an admission of the current state of the web than any real progressive change. Other engine vendors could easily deal with the problem by maturing their support for the de facto standard names once they've got their own rendering of it reasonably mainlined. Why they don't do this is beyond my ability to guess.
posted by ardgedee at 5:06 AM on April 4, 2013 [2 favorites]
Vendor prefixes were a best-possible solution at the time. Pending HTML and CSS standards had become entrenched in perpetual proposal state, with no meaningful changes, for years (CSS 3 has been in draft mode since 1999). Browsers were more heavily forked than they are these days: IE 6 was the major market shareholder and blatantly obsolete already, Safari was new, fast, but with all kinds of quirks, Firefox was the technology leader but weirdly non-progressive (in hindsight) with regards to potential front-end technologies.
The only way to emulate progress without forking the web entirely was to either ignore standards or hack them. Vendor-specific prefixes were a useful means for doing that (a dashed prefix is permissible, per the standards), and was a hell of an improvement over Microsoft's Conditional Commenting, since your new CSS rules could be inlined into your usual document rather than having to be an exception that you had to test for handling.
In the mid-00s, almost every new CSS behavior that we take for granted were things I first saw announced as a -webkit- vendor rule. Most of them, background-gradient aside, exist intact in the HTML5 moving target of a "standard". Some of the rest (fonts, some pseudoclasses) derive directly from what Microsoft shipped as proprietary in the late 90s.
These days? There's no real point for vendor prefixes -- current versions of every major browser use the same syntax for every CSS rule that's not purely experimental. Except that it's a fool's game trying to remember which browser finally supports prettypattern:foo; with or without their proprietary prefix -- Firefox is going to support -moz-prettypattern:foo; as well as prettypattern:foo:, but maybe Webkit only supports -webkit-prettypattern:foo;? Shit, I can't remember. So I macro that fucker in SASS (which, honestly, is way more evil than vendor prefixes are) and stop treating it as a distraction.
Blink's ditching vendor prefixes is more of an admission of the current state of the web than any real progressive change. Other engine vendors could easily deal with the problem by maturing their support for the de facto standard names once they've got their own rendering of it reasonably mainlined. Why they don't do this is beyond my ability to guess.
posted by ardgedee at 5:06 AM on April 4, 2013 [2 favorites]
Everyone commenting on this story has talked about it as if it were some move in The Great Game between Google and Apple and Mozilla and blah blah blah. Politics are involved, surely, but Google also set forth very specific technical and engineering process things that led them to the fork. Maybe it really is just about making better code? Most pundits don't understand the technical issues, it's easier for them to spin a conspiracy of Google vs. Apple.
Has Google said what license they'll be publishing Blink under? All I've found is "open source". I don't fully understand the WebKit license but it seems LGPL is involved, which pretty much demands that any derived source code be LGPL as well. But is Blink actually using LGPLed WebKit sources?
posted by Nelson at 6:15 AM on April 4, 2013
Has Google said what license they'll be publishing Blink under? All I've found is "open source". I don't fully understand the WebKit license but it seems LGPL is involved, which pretty much demands that any derived source code be LGPL as well. But is Blink actually using LGPLed WebKit sources?
posted by Nelson at 6:15 AM on April 4, 2013
Things done to have better code, or, more specifically, offer better user experience is not mutually exclusive with "making a move in The Great Game." It's not a conspiracy theory to suggest that the motivations of a corporation taking on a big costly new project intimately related to their core business include an expectation of profiting by it.
posted by Zed at 6:57 AM on April 4, 2013
posted by Zed at 6:57 AM on April 4, 2013
As an aside, what's with all the AngularJS hate? It's the cleanest and least painful front-end solution I've touched. If I never have to manually bind data to presentation via js framework-of-the-month in yet another non-resuable way again, I'll be a happy dev.
posted by abulafa at 7:03 AM on April 4, 2013 [1 favorite]
posted by abulafa at 7:03 AM on April 4, 2013 [1 favorite]
But is Blink actually using LGPLed WebKit sources?
Unless they want to reimplement the whole core, yes. They won't want to do that, especially given that Chromium itself is open source in any case.
posted by jaduncan at 8:20 AM on April 4, 2013
Unless they want to reimplement the whole core, yes. They won't want to do that, especially given that Chromium itself is open source in any case.
posted by jaduncan at 8:20 AM on April 4, 2013
Thanks for the info, jaduncan. It's somewhat at odds from this quote from Mike West (a Google employee) who says "We can't, and don't want to, change the license of code that's already been released. That said, most (all?) of WebCore isn't LGPL."
Open source comes in different flavors. I could see Google wanting to free itself from the constraints of the LGPL if it's feasible, but so far no one's said that's a particular goal of Blink.
posted by Nelson at 8:40 AM on April 4, 2013
Open source comes in different flavors. I could see Google wanting to free itself from the constraints of the LGPL if it's feasible, but so far no one's said that's a particular goal of Blink.
posted by Nelson at 8:40 AM on April 4, 2013
ArkhanJG: "One of the things google say they want to play with longer term is tying the DOM tighter into their javascript engine, V8, specifically the JIT part and even reimplementing the DOM code itself in javascript - that's a pretty big conceptual change to the DOM handler stuff in webcore, and would probably necessitate a fork all by itself."
Ironically, this could also lead to V8 being forked.
The fact that V8 was so poorly integrated into WebKit means that it can easily be separated by the browser, and run as an independent process (which is exactly what Node.js is).
If V8 is really to be assimilated into the Blink core, we'll almost certainly see a fork of that project as well. Too many other projects (even beyond Node) use the engine outside of the browser. It'd just be a shame to see the best talent split between two fundamentally incompatible projects. The improvements that we've seen in JavaScript performance over the past few years have been nothing short of remarkable.
In any event, it'll also be interesting to see if this affects ES6 development. I suspect that Google and Mozilla will have a stronger voice in the "let's get things done and get standards on the books" debate. The amount of time that it takes the W3C to set standards is absolutely appalling.
posted by schmod at 9:10 AM on April 4, 2013
Ironically, this could also lead to V8 being forked.
The fact that V8 was so poorly integrated into WebKit means that it can easily be separated by the browser, and run as an independent process (which is exactly what Node.js is).
If V8 is really to be assimilated into the Blink core, we'll almost certainly see a fork of that project as well. Too many other projects (even beyond Node) use the engine outside of the browser. It'd just be a shame to see the best talent split between two fundamentally incompatible projects. The improvements that we've seen in JavaScript performance over the past few years have been nothing short of remarkable.
In any event, it'll also be interesting to see if this affects ES6 development. I suspect that Google and Mozilla will have a stronger voice in the "let's get things done and get standards on the books" debate. The amount of time that it takes the W3C to set standards is absolutely appalling.
posted by schmod at 9:10 AM on April 4, 2013
Has "plays nicely with others" ever been a phrase that could be used to accurately describe Apple?
Sure! All the way through to the Apple ][, which included the full schematics and source code for Woz's Integer Basic in the manuals!
posted by zippy at 10:34 AM on April 4, 2013 [3 favorites]
Sure! All the way through to the Apple ][, which included the full schematics and source code for Woz's Integer Basic in the manuals!
posted by zippy at 10:34 AM on April 4, 2013 [3 favorites]
Interesting discussion in this thread by the lead developer of the WebKit project:
As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes.
Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.
At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever. (At the time, there wasn't really an API-stable layer of the Chromium stack that packaged the process support.)
Writing our own seemed like the least bad approach.
If Google had upstreamed their multiprocess support, we almost surely would have built on it. And history might have turned out differently.
posted by Blazecock Pileon at 11:20 AM on April 4, 2013 [3 favorites]
As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes.
Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no.
At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever. (At the time, there wasn't really an API-stable layer of the Chromium stack that packaged the process support.)
Writing our own seemed like the least bad approach.
If Google had upstreamed their multiprocess support, we almost surely would have built on it. And history might have turned out differently.
posted by Blazecock Pileon at 11:20 AM on April 4, 2013 [3 favorites]
Google is forking WebKit.
On the off-chance that someone here has access to a time machine: could you take this sentence back to 1957 or 1969 and find out what they make of it? I'd be fascinated to know.
(I just enjoy things that make sense now that would have been literally meaningless within living memory)
posted by Grangousier at 12:07 PM on April 4, 2013
On the off-chance that someone here has access to a time machine: could you take this sentence back to 1957 or 1969 and find out what they make of it? I'd be fascinated to know.
(I just enjoy things that make sense now that would have been literally meaningless within living memory)
posted by Grangousier at 12:07 PM on April 4, 2013
I think it would sound like British slang:
Google 'is forking webkit!
posted by He Is Only The Imposter at 12:36 PM on April 4, 2013 [1 favorite]
Google 'is forking webkit!
posted by He Is Only The Imposter at 12:36 PM on April 4, 2013 [1 favorite]
Yes, but what?
"Watch out for 'im, 'e's forkin' webkit, know what I mean?" or "Check out the girl over there - is she forking webkit or what?"
posted by Grangousier at 1:17 PM on April 4, 2013
"Watch out for 'im, 'e's forkin' webkit, know what I mean?" or "Check out the girl over there - is she forking webkit or what?"
posted by Grangousier at 1:17 PM on April 4, 2013
Q&A video with some Google Chrome folks about the fork. It's not terribly deep, but there are some good tidbits within: https://plus.google.com/102860501900098846931/posts/faJ8BmaQL8j
They even mention the multiprocess disagreement mentioned above.
posted by introp at 1:38 PM on April 4, 2013
They even mention the multiprocess disagreement mentioned above.
posted by introp at 1:38 PM on April 4, 2013
"Watch out for 'im, 'e's forkin' webkit, know what I mean?"
You are so getting banned from pycon.
posted by signal at 3:14 PM on April 4, 2013 [2 favorites]
You are so getting banned from pycon.
posted by signal at 3:14 PM on April 4, 2013 [2 favorites]
Interesting discussion in this thread by the lead developer of the WebKit project:
It was linked to up thread.
If Google had upstreamed their multiprocess support, we almost surely would have built on it. And history might have turned out differently.
Most likely not as this is not the sole issue but perhaps the sexiest, but of course, the link continues with a response:
I don't understand this claim. WebKit2 was landed with effectively no notice and no attempts at collaboration. I saw repeated attempts to work on a shared architecture in WebKit2, but none were reciprocated. Eventually all non-Apple contributors were cut off entirely from WebKit2 as a matter of policy.
Looks like two ways of working clashing rather than meshing, which is hardly uncommon so history may well have turned out differently if both of them were on the same page but a bunch of developers on these projects are behaving just like a bunch of developers on other projects. Objectives and models often differ depending on an overall philosophy. For the end user, the only thing that matters is if all the engines render standards compliant HTML. I doubt there is any "animosity" on a corporate level.
posted by juiceCake at 3:51 PM on April 4, 2013 [2 favorites]
It was linked to up thread.
If Google had upstreamed their multiprocess support, we almost surely would have built on it. And history might have turned out differently.
Most likely not as this is not the sole issue but perhaps the sexiest, but of course, the link continues with a response:
I don't understand this claim. WebKit2 was landed with effectively no notice and no attempts at collaboration. I saw repeated attempts to work on a shared architecture in WebKit2, but none were reciprocated. Eventually all non-Apple contributors were cut off entirely from WebKit2 as a matter of policy.
Looks like two ways of working clashing rather than meshing, which is hardly uncommon so history may well have turned out differently if both of them were on the same page but a bunch of developers on these projects are behaving just like a bunch of developers on other projects. Objectives and models often differ depending on an overall philosophy. For the end user, the only thing that matters is if all the engines render standards compliant HTML. I doubt there is any "animosity" on a corporate level.
posted by juiceCake at 3:51 PM on April 4, 2013 [2 favorites]
I think there was also a fundamental disagreement about what belonged in Webkit versus what belonged in Chromium/Safari.
Google's decision to not upstream Chromium into Webkit seems to make sense, given that process management was delegated to the browser rather than the rendering engine. Chrome's task manager is effectively the application's crown jewel, and it would almost seem silly for the Chromium project to continue to exist at all if all that code was upstreamed into Webkit (and if they did that, it would have been a much "hostile" maneuver than the Blink fork is, as it would have fundamentally changed the scope and nature of what Webkit does).
The Apple folks thought differently, didn't want Safari to function as a task manager, and Webkit2 was born. This might not have been an irreconcilable difference, except that Apple dumped all of Webkit2 into Webkit's source tree at once, effectively making it impossible for the project's other contributors to collaborate or offer feedback. That's not how open-source development is supposed to work, and Google would have been well within reason to fork Webkit over that incident alone.
posted by schmod at 11:02 AM on April 5, 2013 [1 favorite]
Google's decision to not upstream Chromium into Webkit seems to make sense, given that process management was delegated to the browser rather than the rendering engine. Chrome's task manager is effectively the application's crown jewel, and it would almost seem silly for the Chromium project to continue to exist at all if all that code was upstreamed into Webkit (and if they did that, it would have been a much "hostile" maneuver than the Blink fork is, as it would have fundamentally changed the scope and nature of what Webkit does).
The Apple folks thought differently, didn't want Safari to function as a task manager, and Webkit2 was born. This might not have been an irreconcilable difference, except that Apple dumped all of Webkit2 into Webkit's source tree at once, effectively making it impossible for the project's other contributors to collaborate or offer feedback. That's not how open-source development is supposed to work, and Google would have been well within reason to fork Webkit over that incident alone.
posted by schmod at 11:02 AM on April 5, 2013 [1 favorite]
« Older Antimatter. It's out there. | Fooood In Spaaaaaace Newer »
This thread has been archived and is closed to new comments
posted by Artw at 6:27 PM on April 3, 2013