Forgot your password?
typodupeerror
Chromium Chrome Google

Blink! Google Is Forking WebKit 252

Posted by Soulskill
from the reworking-the-basics dept.
Carewolf writes "In a blog post titled Blink: A rendering engine for the Chromium project, Google has announced that Chromium (the open source backend for Chrome) will be switching to Blink, a new WebKit-based web rendering engine. Quoting: 'Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation... This was not an easy decision. We know that the introduction of a new rendering engine can have significant implications for the web. Nevertheless, we believe that having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open web ecosystem. ... In the short term, Blink will bring little change for web developers. The bulk of the initial work will focus on internal architectural improvements and a simplification of the codebase. For example, we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat. Over the long term a healthier codebase leads to more stability and fewer bugs.'"
This discussion has been archived. No new comments can be posted.

Blink! Google Is Forking WebKit

Comments Filter:
  • I wonder if blink will still identify itself @ webkit for sites written that way

  • by Anonymous Coward on Wednesday April 03, 2013 @05:57PM (#43352403)

    "We think WebKit has become too mainstream for people as cool as we are"

    • by beelsebob (529313) on Wednesday April 03, 2013 @06:05PM (#43352495)

      I was more thinking "We don't want to help contribute our improvements to all the other users of WebKit, so we're going to say 'we're forking it' rather than 'we're going to start ignoring the coding standards to make sure everyone gets supported'".

      Not exactly the model open source citizens Google are often billed as.

      • Or maybe, "Working with other people is hard, so we'll fork."

        At least, that's what their post says.
        • Re: (Score:2, Insightful)

          by Anonymous Coward

          Or maybe "Working with Apple is hard."

          In the world of web browsers, this kind of fragmentation is probably a good thing. It prevents a platform monopoly and thus strengthens web standards. I would love to see all these incompatible -webkit properties go where they belong: into testing only, and only until the unprefixed property is standardized or rejected.

          Anyway, it's open source and anyone is free to port Google's code back to Webkit.

          • In the world of web browsers, this kind of fragmentation is probably a good thing. It prevents a platform monopoly and thus strengthens web standards

            But in the real world, more browsers means more browsers to test against. Standards are a great theory, and you should follow them, but you still have to test against every browser if you want to make sure it works.

            • Re: (Score:3, Insightful)

              by Anonymous Coward

              But in the real world, more browsers means more browsers to test against. Standards are a great theory, and you should follow them, but you still have to test against every browser if you want to make sure it works.

              Different WebKit based browsers are already require separate testing. This fork doesn't add to the testing burden.

              The following "WebKit" browsers are already different enough that separate testing is required to support them:
              * Safari on Mac
              * Safari on iOS
              * Chrome
              * Android Browser

              WebKit has an amazing number of #defines, so that different browsers using it have different feature sets.

        • Re:In other words... (Score:4, Informative)

          by daboochmeister (914039) <daboochmeister@@@gmail...com> on Thursday April 04, 2013 @03:22AM (#43355453)
          You and the parent would likely be wrong as to their motives. They have very lucid reasons for forking, ones that pass the smell test. One of the developers enunciated them here [google.com], though he's careful to qualify it as his perspective, not an official position.
      • Re:In other words... (Score:5, Informative)

        by makomk (752139) on Wednesday April 03, 2013 @06:11PM (#43352567) Journal

        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.

        • by Nerdfest (867930) on Wednesday April 03, 2013 @07:09PM (#43353141)

          Relax, I'm sure someone will come along and explain that it's not anti-competitive and Apple have everyone's best interests in mind.

          • Re: (Score:3, Insightful)

            by theVarangian (1948970)

            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.

            Relax, I'm sure someone will come along and explain that it's not anti-competitive and Apple have everyone's best interests in mind.

            It may be a balm to your soul to pretend that Apple is being especially evil here but they aren't the only ones doing this. I was recently given the task of compiling MySQL on AIX 7. It's doable but the code is riddled with stuff committed by people who don't care what else they are breaking as long as it works on Linux. Not that I'm complaining, AIX versions newer than 5.3 are not supported by the MySQL team due to "low demand" and I can easily sympathise with the MySQL team's reluctance to support it. It'

            • Re: (Score:3, Insightful)

              by Anonymous Coward

              Apparently you don't realize it, but that's a false dichotomy. Officially dropping suppport for an obscure platform is not in the same league as ignoring breakage on all non-apple platforms.

        • Re:In other words... (Score:5, Informative)

          by Anonymous Coward on Wednesday April 03, 2013 @07:14PM (#43353175)

          This is not true. I have been contributing to WebKit for 2 years, and overall I feel Apple reviewers are the easiest to work with.
          The problem you're referring to is due to the lack of testing infrastructure on non-popular platforms. For every patch entering the commit queue, a whole set of unit tests and layout tests need to be run, and the patch will only land if none of the tests failed. Apple and Google do provide their own buildbots for each port they maintain, to minimize chance of breaking. It is not like we are hostile against other platforms. Just that without proper test coverage it is really difficult not to break them by accident, and in the unlikely event that a port break, we try to fix it or revert the patch.

      • Re:In other words... (Score:5, Informative)

        by Lussarn (105276) on Wednesday April 03, 2013 @06:12PM (#43352579)

        Forking has a long tradition in open source software, webkit itself was forked from KHTML. There is absolutely nothing anti open source about it. Find yourself a new argument why Google sucks.

        • Re:In other words... (Score:4, Interesting)

          by beelsebob (529313) on Wednesday April 03, 2013 @06:18PM (#43352627)

          Notably, the norm when forking is to do so because you think you can take the project in a new and interesting direction, and the generally accepted process is to make your changes as easy to integrate and work with for the original developers as possible. In fact, Apple got a very bad rap for forking (because they thought they could take the project in a new direction), and then making it difficult to integrate their code back into KHTML. Here, google are forking exactly to make it difficult for the original authors to integrate their code, not to take things in a new direction. Given the bad rap Apple (rightly) got about this, I'd suggest it would be the hight of hypocrisy to not give google a much harder time over a worse transgression.

          • by Anonymous Coward on Wednesday April 03, 2013 @06:26PM (#43352705)

            and see where this leads.

            If they keep it cross platform compatible, keep enough of the regularly used interfaces stable for webkit to blink transitions for third party browsers (see midori, whatever kde's browser is currently called, gnome's, etc), and don't do anything ridiculously hostile to the rest of the OS community it might actually turn out better than the WebKit handling under Apple.

          • If it's 'bad' to fork a project and not contribute all your changes back, what is the point of forking in the first place? Why not just contribute to the original project?
            The only reason to do so is the desire to make changes that are not compatible with the original project.

            • by Grishnakh (216268)

              It's not just that; the other reason is because you're too lazy to cooperate with the original project, such as by following their coding standards, by dividing your patches up into chunks the original project prefers so they can review them effectively, by making sure your changes don't break the build for other platforms which you don't use, etc.

              • Not very accurate. (Score:5, Insightful)

                by tlambert (566799) on Wednesday April 03, 2013 @08:05PM (#43353543)

                It's not just that; the other reason is because you're too lazy to cooperate with the original project, such as by ... dividing your patches up into chunks the original project prefers so they can review them effectively, ...

                This is frequently not a matter of "lazy". Often it's a matter of having a team paid programmers working 16 hours a day adding code to something, and if they are not already insiders, there's not a chance in hell a group of volunteers is going to be able to keep up with the review load unless they are independently wealthy or work for the company that already employs the team.

                That's why you frequently see the team for an Open Source project that's trying to make a go of it as a business by selling support or contracting themselves out to implement features for interested parties getting their company bought out. It's why MySQL was bought out, and it's why Oracle was bought out.

                I've personally been "on a roll" and generated > 20,000 lines of code in a two week period (I ended up in wrist braces for another two weeks after that). There's no way that an Open Source project is going to be able to review at that rate unless they have a huge volunteer base, and that's practically all they do. Which generally ends badly, since it's no damn fun to get involved in a project to code, and find out you're spending all your time reviewing instead.

                The truly sad part is that when you are working with volunteers, you can rarely find someone willing to do the scut-work. The volunteers are there to have fun, and scut work is generally not fun for anyone. But it's necessary for productization, and as a result, productization doesn't happen. It's rare that you see commercial quality Open Source products... it's even rarer that you see actual documentation apart from "read the source".

                Finally, there's the "you can't get there from here" factor. You can rarely do something truly revolutionary in small increments, and insisting that all code do a drunkards walk from where it's at to someplace truly cool is a fool's errand. You will face objections from all sorts of people; not just the people who don't want to get from "here" to "there" because they don't want to go to "there" with the rest of you. You also get objections from people who don't want things that aren't currently being used checked in. So you are caught between committing foundation work which isn't used yet, or upper level work that can't be enabled because the foundation isn't there yet.

                So you fork. It's not you being lazy, it's you being pragmatic about the inertia of projects which are incapable of accepting large chunks of change that get you where you want/need to go.

                It's why Apple (rightly) forked KHTML to create WebKit in the first place, and it's why Blink is forking now -- read their web site; they have a significantly different process and sandbox architecture that part of their per-DOM rendering engine model, and staying part of WebKit means carrying around 7,000 files which are totally useless to them.

            • by multi io (640409)

              If it's 'bad' to fork a project and not contribute all your changes back, what is the point of forking in the first place? Why not just contribute to the original project? The only reason to do so is the desire to make changes that are not compatible with the original project.

              Not really. The project may consist of several parts or subsystems, and you may want to fork in order to replace or refactor one or two of the subsystems. In that case, all changes you make to one of the other subsystems should still be easy to integrate back into the original project.

          • Re:In other words... (Score:4, Informative)

            by UnknowingFool (672806) on Wednesday April 03, 2013 @07:24PM (#43353277)
            Well the problem for Apple was the sheer amount of changes and lack of documentation they provided for their changes. The KHTML developers could not easily back port the changes; but these issues are not isolated to Apple's treatment of KHTML. Poor documentation affects some OSS projects.
            • The original problem was that Apple kept all of their WebKit changes private right up until they did a new release of Safari, then they published a massive diff against KHTML. This was impossible to review. They now develop in the open, so you can cherry-pick individual changes. Developing in a public repository makes a huge difference, even if it's a fork.
          • by DragonWriter (970822) on Wednesday April 03, 2013 @07:27PM (#43353301)

            Here, google are forking exactly to make it difficult for the original authors to integrate their code, not to take things in a new direction.

            Except that they've specifically identified both the new directions in which they want to take the code and the problems that they have been running into trying to take the code in those direction while meeting the commitments and constraints of the upstream project (to which they are both the largest source of commits and the largest source of reviewers.)

            Chromium and WebKit have divergent goals and it has become increasingly burdensome trying to reconcile them.

            • by beelsebob (529313)

              The only goal identified in their blog post announcing this was to be able to remove all the code supporting other people's work.

          • by mabinogi (74033)

            No, the norm when forking is to do so because you don't get along with the maintainers...

      • by Art3x (973401) on Wednesday April 03, 2013 @07:20PM (#43353233)

        While it would be bad to have many standards (like HTML, MS-ML, ORACLE-ML, etc.) it's good to have many implementations of that standard (WebKit, Gecko, Blink).

        The ability to "delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat" is justification alone to fork the project. Another good reason from the blog is the fragile workarounds for old APIs:

        Our current networking code in WebKit is limited by old Mac WebKit API obligations which cannot be changed. Chromium has worked around some of these limitations over the years, but these work-arounds have proven fragile and have long been a source of bugs.

        • That might be the theory. The historical reality is that multiple browser engine implementations have been a major pain in the ass for developers, who've had to code round all their quirks, and test against them all. And they've been a moderate pain in the ass for browser users, who've experiences web-sites that haven't worked well, or at all, with their browser. So just who has been served by this "good" of multiple implementations?

        • While it would be bad to have many standards (like HTML, MS-ML, ORACLE-ML, etc.) it's good to have many implementations of that standard (WebKit, Gecko, Blink).

          The ability to "delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat" is justification alone to fork the project.

          Who'll be the first one to call Apple a poopy head when people start removing Chromium cruft from Webkit?

  • Ugh...great (Score:2, Insightful)

    by daveschroeder (516195) *

    We could always count on WebKit being the universal web rendering engine across iOS and Android -- now, that will no longer be the case, and I guarantee you there will be instances where Google uses the inevitable differences between "Blink" and WebKit (which is also the core rendering engine for Mac OS X and Safari) for competitive advantage with Chrome, Chrome OS, and Android, al la Microsoft and IE... :-/

    • Re:Ugh...great (Score:4, Insightful)

      by MetalliQaZ (539913) on Wednesday April 03, 2013 @06:10PM (#43352557)

      There's no reason to think that. Even though Chrome and Safari both use webkit components, they are not the same browser and they don't necessarily even act the same... even now. Google could have already done what you describe, but they didn't. Web standards were far less important when IE came about than they are now. For Google to go non standard would be an incredible shock and is unlikely IMHO.

    • Re:Ugh...great (Score:4, Informative)

      by igrigorik (818839) on Wednesday April 03, 2013 @06:12PM (#43352575) Homepage

      We could always count on WebKit being the universal web rendering engine across iOS and Android -- now, that will no longer be the case, and I guarantee you there will be instances where Google uses the inevitable differences between "Blink" and WebKit (which is also the core rendering engine for Mac OS X and Safari) for competitive advantage with Chrome, Chrome OS, and Android, al la Microsoft and IE... :-/

      This is true already: there are visual and performance differences between different webkit browsers. WebKit is just a layout engine, whereas a full browser requires dozens of other components. WebKit for Developers provides a nice overview on this: http://paulirish.com/2013/webkit-for-developers/ [paulirish.com]

    • Re:Ugh...great (Score:4, Insightful)

      by Frosty Piss (770223) * on Wednesday April 03, 2013 @06:23PM (#43352673)

      So, you are all for the idea of being able to fork Open Source projects depending on your needs - except when it is a disadvantage to you?

      I know, people will say that's snarky, but seriously, we can't have it both ways.

    • by dhavleak (912889)
      Excellent point. So much for people clamoring for MS to adopt WebKit.
    • by tlhIngan (30335)

      We could always count on WebKit being the universal web rendering engine across iOS and Android -- now, that will no longer be the case, and I guarantee you there will be instances where Google uses the inevitable differences between "Blink" and WebKit (which is also the core rendering engine for Mac OS X and Safari) for competitive advantage with Chrome, Chrome OS, and Android, al la Microsoft and IE... :-/

      Well, Blink's license is still LGPL as WebKit is LGPL, so source has to be available.

      Now, it depends

      • by Lussarn (105276)

        It's possible, maybe even likely Blink will be the new universal rendering engine and WebKit an Apple only thing, timeframe a year or two. I don't know if Blink or WebKit developers even want to merge between the projects. It will be interesting to see how this saga continues, the browser war have been a bit stale as of late. Not that I like browser inconsistences but I do like competition.

        • It's possible, maybe even likely Blink will be the new universal rendering engine and WebKit an Apple only thing, timeframe a year or two.

          Given that the whole point of Blink is for Google to remove support for platforms other than their own, this is is either unlikely or impossible.

    • Oh no! You mean we'll have to start supporting multiple browsers? What a shock. We should go back to the utopian days of web monoculture and IE6.

    • by Millennium (2451)

      So code to the standards and test across browsers. You should be doing that anyway.

  • by Anonymous Coward on Wednesday April 03, 2013 @06:00PM (#43352443)

    Blink and you’re dead.
    Don’t turn your back.
    Don’t look away.
    And don’t blink.
    Good Luck.

  • by Kingkaid (2751527) on Wednesday April 03, 2013 @06:01PM (#43352449)
    I've seen web developers tout for years how great webkit was and so they built specific features with the webkit functionality in mind. This is the same group that hates and laments (and very rightly so) IE6 for not using web standards. It is nice to see the entire process go full circle :) So remember, if you're developing, stick to standards, don't use custom code for each browser and please remember that not everyone has a locally cached version of the page on their machine - load times do matter.
    • by Kjella (173770) on Wednesday April 03, 2013 @06:31PM (#43352749) Homepage

      Vendor Prefixes

      Historically, browsers have relied on vendor prefixes (e.g., -webkit-feature) to ship experimental features to web developers. This approach can be harmful to compatibility because web content comes to rely upon these vendor-prefixed names. Going forward, instead of enabling a feature by default with a vendor prefix, we will instead keep the (unprefixed) feature behind the âoeenable experimental web platform featuresâ flag in about:flags until the feature is ready to be enabled by default. Mozilla has already embarked on a similar policy.

      If they put their money where their mouth is, that will be less of a problem than today. Google can still pull a "don't be evil" when they want...

    • So remember, if you're developing, stick to standards, don't use custom code for each browser

      We Web developers would love to be able to just "stick to standards," if only that were possible!

      Consider playing audio. Simple enough concept, right? The problem is, there is no single way to play audio today, that works across all browsers! There are many issues with applying styles and positioning that simply do not work the same on all browsers, even if you do stick to standards.

      Microsoft can't even manage to stay compatible with their own previous browser versions, and now there are two different fl

    • by dave420 (699308)
      Google's main problem with WebKit was not rendering, but the legacy code included by Apple for support of old Macs, most importantly the networking code, which was thousands of lines of bug-inducing insanity. Don't confuse the two. Most developers already know how to develop.
      • Google's main problem with WebKit was not rendering, but the legacy code included by Apple for support of old Macs, most importantly the networking code, which was thousands of lines of bug-inducing insanity.

        By which you mean code that hasn't been used by any Apple browser for years. And that was hard for Google to ignore, while it wasn't for Apple?

  • by joebok (457904) on Wednesday April 03, 2013 @06:10PM (#43352547) Homepage Journal

    <blink>I want to blink my text again!!</blink>

  • WebKit (TM) (Score:5, Interesting)

    by Anonymous Coward on Wednesday April 03, 2013 @06:19PM (#43352649)

    I bet it has nothing to do with the fact that "WebKit" became a registered trademark of Apple less than a month ago.

    http://www.patentlyapple.com/patently-apple/2013/03/apples-webkit-is-now-a-registered-trademark-in-the-us.html

  • Surprised... (Score:5, Insightful)

    by Anubis IV (1279820) on Wednesday April 03, 2013 @06:22PM (#43352665)

    ...it took this long. Granted, I haven't been following the happenings with rapt attention (or pretty much any attention at all), but I had always figured that Chrome's multiprocess sandboxing approach, which appeared to be made redundant with the addition of a similar multiprocess architecture in WebKit2 that attempted to take that same idea and build it into the rendering engine itself, would push Google towards forking WebKit. After all, new software coming in or switching to WebKit would be likely to switch to WebKit2 specifically, meaning that it's likely that the pace of WebKit development might slow down unless broken out as a fork.

    Whether that had any meaningful impact on their decision, I couldn't say, but it struck me as odd that something like this didn't happen earlier.

    Disclaimer: IANAREEOPKOTT (I am not a rendering engine expert or particularly knowledgeable on the topic)

    • Re:Surprised... (Score:5, Interesting)

      by Anubis IV (1279820) on Wednesday April 03, 2013 @06:51PM (#43352981)

      For reference, the WebKit team's main page for WebKit2 [webkit.org] describes some of the differences between its approach and the approach that Google took when developing their own process architecture. It more or less struck me as an indication that WebKit2 would be a point of divergence for Apple and the people switching to WebKit2, and for Google, which would likely stick with WebKit and their investment in the architecture that they had already developed. Apple switched from using WebKit to WebKit2 in Safari quite some time ago, though by all indications it has not yet done so with iOS.

      The fact that forking WebKit will likely allow Google to drop support for iOS (among other platforms) as they add more features and establish a competitive advantage for themselves is more than likely a larger motivating factor than this, but it's still something worth considering.

  • IE did it first (Score:4, Interesting)

    by rsierpe (2678773) on Wednesday April 03, 2013 @06:35PM (#43352791)
    If I remember it right from ye olde days, it would be "embrace, extend, exterminate". They already embraced webkit, which is now some de facto standard, now they'll fork it, which implies some added functionality in the process, and you people know the rest. we are still trying to get off IE's dark era.
    • by bug_hunter (32923)

      Well, the added functionality appears to be remove the redundancy of sandboxing and multi-processing features between chrome and web-kit i.e. non rendering related - so I wouldn't be too worried yet.
      Really the main issue wont be how Chrome will play, it's if the remaining WebKit developing companies keep WebKit standard compliance up to date.

  • by dingen (958134) on Wednesday April 03, 2013 @06:55PM (#43353005)

    If I somehow could go back a year and tell my past self that in 2013 Opera would be using WebKit, but Chrome would be using something else I would not have believed it. Yet, here we are. It's bizarro world.

    • If I somehow could go back a year and tell my past self that in 2013 Opera would be using WebKit, but Chrome would be using something else I would not have believed it.

      There's not really a point where Opera is using WebKit and Chrome isn't (at least for new development); Opera's switch to "WebKit" was a switch to base off of Chromium; with Chromium forking WebKit as Blink, new Opera will now also be based on Blink.

    • Re: (Score:2, Informative)

      by swillden (191260)
      Opera is moving to Blink also.
  • "Bikini Google is Forking WebKit" and had to do a double-take?

  • If Google do as good as job with Blink as they did with V8, I think this could put Chrome way ahead of the others and make it an incredibly advanced and fast browser, even more than it already is. I'm excited to see what Chrome will be with Blink in a few more versions.
  • Ah, I see. "Out-of-Process frames" means better management of advertising.

At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.

Working...