18 ms·

Blink: A rendering engine for the Chromium project

• ebbv 14y ago
  I can't help but think that forking WebKit is a business based decision since Apple controls WebKit. This blog post doesn't make an engineering based argument* so I'm left with the business ones. Which sucks. * - Just vague "we need to innovate faster" boilerplate. Which is what business people say when there's not a solid engineering based reason. EDIT: At the bottom of the project page are some engineering reasons: http://www.chromium.org/blink http://www.chromium.org/blink Each person can judge whether it's worth forking or not.
  • mankyd 14y ago
    a) Why does that suck? b) Although it is a little hand wavey, they do make an engineering argument: "However, 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."
    • dragonwriter 14y ago
      > Although it is a little hand wavey, they do make an engineering argument: Immediately being able to eliminate and not worry about maintaining 7,000 files comprising 4.5 million LOC seems to be a pretty concrete benefit, rather than a hand-wavey one.
  • mikewest 14y ago
    http://www.chromium.org/blink/developer-faq http://www.chromium.org/blink/developer-faq has a bit more information, as does http://www.chromium.org/blink#architectural-changes http://www.chromium.org/blink#architectural-changes. There really are good architectural reasons to go in this direction.
  • simonster 14y ago
    Apple doesn't actually control WebKit. A decent proportion of reviewers at http://trac.webkit.org/wiki/WebKit%20Team http://trac.webkit.org/wiki/WebKit%20Team are Google employees. The engineering argument is that the differences between Chromium's multi-process model and WebKit2 are big enough that, in order for both projects to move forward, Google needs to fork WebKit. I'm not competent to judge whether this is actually true.
    • mikewest 14y ago
      http://trac.webkit.org/wiki/WebKit2 http://trac.webkit.org/wiki/WebKit2 outlines the technical differences between the architectures pretty well. Suffice it to say, the model runs deep, and has real impact on the way things like WebCore are put together.
    • fpgeek 14y ago
      Speaking of reviewers, it looked like there were (maybe) a handful of WebKit reviewers that meet the following criteria: 1. Not affiliated with Apple or Google. 2. Not specifically associated with a port in terms of their review areas. To me, that says a lot about how WebKit governance works in practice.
  • deleted 14y ago
    [deleted]
  • yanw 14y ago
    Chromium uses a different multi-process architecture ... and supporting multiple architectures over the years has led to increasing complexity ... 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 How is that not engineering based?
    • nnethercote 14y ago
      Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. So I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. Perhaps an extra zero got inserted somewhere.
      • signed0 14y ago
        4.5 million lines spread over 7,000 files is only ~642 lines per file, so I doubt there is an extra zero. Perhaps they included whitespace and comments in their count.
      • simonster 14y ago
        Not sure why this is got downvoted given that it appears to be correct (https://github.com/mozilla/mozilla-central/graphs/code-frequency https://github.com/mozilla/mozilla-central/graphs/code-frequ...)
      • dragonwriter 14y ago
        > Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. Mozilla isn't WebKit. > I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. I suppose you could compare WebKit repos against Blink repos once the latter is live to see exactly what is cut, but I'm going to say the people working on the code that are the source of the count know how many LOC are involved, and that there direct count is more reliable than a third-party estimate based on a different browser's repo.
        • nnethercote 14y ago
  • drivebyacct2 14y ago
    Of course the blog post doesn't go into technical detail. But if you would explore just a single link deeper you would see a pretty good explanation of the changes they're making. It's pretty obvious why they're doing it. It improves and greatly eases the amount of effort required to port/utilize Chromium/Blink not to mention the other benefits from the architecture that they indicate will enable better multithreading.
  • deleted 14y ago
    [deleted]
  • mtgx 14y ago
    How does Apple control webkit? Doesn't Google have like 50% of the commits to webkit?
  • alxndr 14y ago
    Ars has slightly more... >Longer term, we can expect to see Blink evolve in a different direction from WebKit. Upson and Komoroske told us that there were all manner of ideas that may or may not pan out that Google would like to try. The company says that forking WebKit will give it the flexibility to do so. http://arstechnica.com/information-technology/2013/04/google-going-its-own-way-forking-webkit-rendering-engine/ http://arstechnica.com/information-technology/2013/04/google...
  • tolmasky 14y ago
    If you look at the commits, there's a fair argument that Google "controls" WebKit. You could almost say Apple got KHTML'ed ;) I believe this is an honest move. This is what happens with software. Goals change, old code and design no longer makes sense, you refactor or rewrite. The architecture of WebKit was created to address goals that are a decade old now. The multi-process nature of Chrome alone, an amazing achievement and really quite elegant if you've looked at the way they bolted it on, was bolted on all the same. V8 without a doubt re-invigorated JavaScript. When V8 was announced there was a lot of "do we really need another JS engine" arguments. You could argue that other engines were getting fast as well, but v8 got people really thinking about JavaScript outside the browser. I am excited to see what new insights this new rendering engine brings -- and what unexpected positive consequences it generates.
    • MatthewPhillips 14y ago
      If you want to really put a tinfoil cap on, you could say that by Google contributing to WebKit they are giving Apple a lot of free code, allowing them to devote fewer resources to their browser. Once Blink diverges father from WebKit it won't be practical for WebKit to merge in changes from there. One has to wonder if Google will be recruiting other WebKit contributors (RIM, Intel, Nokia, etc) to move over to Blink. This would put Apple in a tough spot.
      • mikewest 14y ago
        Blink remains very much open source: the repository should be visible in a minute or three. We're going to be even more transparent than we currently are, actually, about how things get added to the platform http://www.chromium.org/blink#new-features http://www.chromium.org/blink#new-features. I'm pretty excited about how that's going to play out with regard to sharing ideas and implementations.
        • MatthewPhillips 14y ago
          Of course, I wasn't claiming otherwise, but over time porting code to WebKit from Blink will become more trouble than it's worth. They can still learn from it, but you can hardly deny that this move is going to cause WebKit some pain to fill in the tremendous amount of work you guys were doing (the part about this being the reason for the move was, of course, completely a joke.
  • lukifer 14y ago
    If there is an engineering argument, I'm guessing it's to do with multi-threaded DOM+JS, given the mention of multi-process architecture. Also, how much does Apple really control WebKit? At a glance, it looks to me like FOSS. (Apple might be the maintainer, but it seems trivial to fork it in a different direction.) Perhaps this is a more nebulous "thought leadership" kind of thing?
  • alexchamberlain 14y ago
    It looks like a lot of C++ projects atm; we need to throw out the chronies and fix their spaghetti code.
• Lightning 14y ago
  Just a few weeks after Opera decided to switch to Webkit. Interesting.
  • tantalor 14y ago
    IIRC they switched to Chromium, not WebKit.
  • deleted 14y ago
    [deleted]
  • gsnedders 14y ago
    Opera is building on top of the Chromium Content API; we're following them to Blink.
  • Me1000 14y ago
    Opera will be using Blink: http://www.brucelawson.co.uk/2013/hello-blink/ http://www.brucelawson.co.uk/2013/hello-blink/
• drivebyacct2 14y ago
  Interesting timing, given the Samsung+Mozilla+Servo news today.
  • nornagon 14y ago
    Servo's been around for a while: https://github.com/mozilla/servo/graphs/commit-activity https://github.com/mozilla/servo/graphs/commit-activity
    • drivebyacct2 14y ago
      I know (been playing with it and rust for some time now), but it's not received half the attention it received today. I mean, the Verge covered it...
  • coldtea 14y ago
    Yes. Announcing this especially today seems like a "fuck you" at Samsung. Downvotes? Anybody thinks that two companies that are in some heat over Android/Tizen et all, just coincided to release information about new rendering engines on the same day? As if rendering engines are announced every other day, right?
    • fpgeek 14y ago
      How is announcing Blink a "fuck you" to Samsung? Exactly which side, if any, of the Blink/WebKit divide do you think Samsung is on? And in terms of Servo, Blink makes Servo more likely to succeed, not less, by breaking open the (mobile) WebKit monoculture.
    • cromwellian 14y ago
      Did you ever consider that the launch date had been scheduled a long time ago?
      • coldtea 14y ago
        How does that invalidate what I said? The only requirement for "stealing thunder" is for one party to know in advance the scheduled date for the other party.
• cpeterso 14y ago
  I thought the WebKit monoculture was supposed to be a good thing? ;)
• beshrkayali 14y ago
  Does this mean that Chrome for iOS will be revoked out of the AppStore?
  • gsnedders 14y ago
    No, it just means that instead of Chrome for Android and Chrome for iOS having different versions of WebKit, Chrome for Android will use Blink and Chrome for iOS will use the system WebKit, as it does now.
    • mtgx 14y ago
      So Google will be using 2 increasingly different rendering engines for Chrome in the future? Well that sucks. Apple really needs to allow other rendering engines on iOS, or at least be forced into it. People complain about the "webkit mono-culture", but a huge platform like iOS actually mandating you use webkit, and their single version of webkit, is a lot worse.
      • beshrkayali 14y ago
        I agree, that would suck. Specially if -for some reason- we start seeing differences in terms of rendering speed/js engine/or other techs between the android version and the iOS version.
        • vladikoff 14y ago
          This is already true today.
          • beshrkayali 14y ago
            Well, then it's already sucky :) I never tried/used the android version.
        • aniket_ray 14y ago
          The Android and iOS versions have always been different. Apple does not approve any browser apps that do not use the default UIWebView. It was this reason that Adobe could never launch a flash enabled browser on iOS.
• mtgx 14y ago
  So when can we expect Chrome to use Blink?
  • igrigorik 14y ago
    Starting today new dev work will go into Blink repo. So, effectively, today.
    • cpeterso 14y ago
      Is there a way to determine in the Chrome UI whether I have a Blink build? Will Chrome's User-Agent String change to include "Blink"?
  • mikewest 14y ago
    Chrome 28 will be the first blinking release.
    • necubi 14y ago
      The real question: when is support for <blink> coming back?
      • igrigorik 14y ago
        cough web components cough
        • ahoge 14y ago
          Haha... yea, you can actually make a x-sinewavemarquee tag if you want.
  • TazeTSchnitzel 14y ago
    Immediately, presumably. They just forked it, so it already works, yes?
• bmuon 14y ago
  Standing ovation. This is most welcomed news since Opera's move to WebKit to keep the current browser innovation pace. Coupled with Mozilla's announcement of its partnership with Samsung to move Servo forward this is great news for the future of the web. Hopefully multi-process/multi-threaded rendering engines will address some of our current performance gripes with the DOM and open the gate for even more complex UIs and interactions.
  • gsnedders 14y ago
    …And Opera is following Chrome to Blink, as new-Opera is built on the Chromium Content API (mentioned below, but seems significant enough to bear repeating).
  • MatthewPhillips 14y ago
    Parallelism is listed as something they are considering, whereas with Servo it's one of the biggest (if not the main) reasons for it existing. From this announcement I can't quite tell what it is with this project that they hope to achieve but I'm sure that will become more clear over time.
    • mtgx 14y ago
      I sure hope Google is considering heterogeneous computing, too, and better sooner than later.
  • zanny 14y ago
    I know this sounds bitter, but I read this comment and my interpretation (of the ideology, not how you said it) is: "Our shitty slow and poorly architected mess of document and script languages is too slow for good application performance, everyone, start floundering around looking for some technology to squeeze another inch of performance out of everything so we can maybe hopefully make our awful mess work finally" It is probably my bitterness towards XML, but I feel like the whole "use-a-document-markup-language-as-an-application-builder" is making people do crazy things, and not in a good way - it is happening because html is entrenched, and it is the only truly device-agnostic framework right now. So everyone tries to make it work for everything. I just see it as a sad circumstance is all.
• account_taken 14y ago
  Competition is good. Nobody wants to be left behind by Google, so time for Apple and MS to step it up again.
  • jfoster 14y ago
    That's an interesting way of looking at it. Apple no longer get a free ride. On the other hand, now that Firefox is using WebKit perhaps Mozilla just replaces Google there.
    • frewsxcv 14y ago
      Since when is Firefox using WebKit
    • dragonwriter 14y ago
      > On the other hand, now that Firefox is using WebKit Firefox is still using Gecko, and is working with Samsung on a long term effort to develop a new engine (Servo) in Rust. You may be thinking of the recent news that Opera is using WebKit, but even when that was first report it was identified that they were really basing on Chromium rather than WebKit proper, and they've announced (in this thread, even) that with Chromium moving to Blink, Opera is following.
    • dubcanada 14y ago
      You do know that most of the WebKit code as it is is Apple's right? If anything it was Google who got a free ride.
      • frewsxcv 14y ago
        I thought most of it is KDE's?
        • dubcanada 14y ago
          KDE originally built KHTML. WebKit however is mostly a product of Apple. They made it into the product it is today. Along with help from Google/RIM/etc. But it was mostly them since they needed it to work in Safari and iOS.
• leeoniya 14y ago
  is this a fork of webkit2 with the split process model built in?
  • pohl 14y ago
    I think it's the other way around: they want to eject the newer Webkit 2 from their fork rather than do the work to adopt it.
    • mikewest 14y ago
      WebKit2 is a similar, but different, multi-process model. Chromium never compiled it in, but the integration imposed various constraints both on Chromium and on WebCore. That's certainly one of the reasons we've introduced Blink.
• mythz 14y ago
  Alex Russell has a good analysis about the move: http://infrequently.org/2013/04/probably-wrong/ http://infrequently.org/2013/04/probably-wrong/
  • marshray 14y ago
    That (and the linked article) was the nicest "fork you" I've ever read. These developers have class.
  • macrael 14y ago
    The argument is essentially: "It took up lots of engineering time and effort to maintain compatibility with other platforms, so this allows us not to worry about other platforms and only focus on our own and that will allow us to move faster." Hopefully this is easier for everyone. If the chrome multithreading architecture really was the pain point then does that mean that webkit will also be deleting thousands of files and become easier to build, just as the chrome team is removing compatibility for other webkit targets? Or will WebKit remain the mess it is now because it strives to work on all the other platforms? What if Apple decided to do the same thing? WebKit is this wonderful open source success story in part because it runs in so many places on so many things, but isn't a large part of that only enabled because the main contributors took the time to make sure that their work continued to run on the various different architectures? Will Google turn away patches that enable Blink to be compatible with platforms not their own? This is an interesting move.
    • cromwellian 14y ago
      Does Apple already maintain a private WebKit fork for iOS?
      • gsnedders 14y ago
        Yes. It's (finally) slowly being upstreamed, however. iBooks uses a separate fork of WebKit, too.
        • 14y ago
• Joeri 14y ago
  Google seems on a "replace open with less open" streak, with google reader and caldav shuttering, and now this. The caldav situation especially i cannot conceive as anything but a business decision given that they're keeping it around for those people they like.
  • mikewest 14y ago
    With regard to open, Chromium is a nicely open source project, and we're really quite committed to transparency in the project. See http://www.chromium.org/blink#new-features http://www.chromium.org/blink#new-features for some of our policies in this direction.
  • nickporter 14y ago
    This has absolutely nothing to do w/ Google Reader. Also: https://code.google.com/p/chromium/ https://code.google.com/p/chromium/
  • cromwellian 14y ago
    Godwin's Rule Corollary violation: o Mentioning Google Reader in a discussion unrelated to RSS or Blogging causes automatic loss of debate/argument/credibility.
• nickporter 14y ago
  Super excited about this! There was a long discussion on the webkit mailing list after google tried to add support for multiple language VMs in webkit. The goal was to have a native Dart VM. https://lists.webkit.org/pipermail/webkit-dev/2011-December/018775.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... If I remember correctly, the patch was not merged in. I guess now google can do whatever it wants!
  • mikewest 14y ago
    "Whatever it wants" within reason. We're actually quite concerned about how new features are added to the web platform, and recognize the need to be careful about what we commit to support forever. See http://www.chromium.org/blink#new-features http://www.chromium.org/blink#new-features for some detail about the process we're planning on using going forward.
  • jmesserly 14y ago
    This is addressed in the FAQ: http://www.chromium.org/blink/developer-faq#TOC-Is-this-just-a-ruse-to-land-the-Dart-VM-or-Native-Client- http://www.chromium.org/blink/developer-faq#TOC-Is-this-just... http://www.chromium.org/blink#new-features http://www.chromium.org/blink#new-features Additionally: we have had experimental Dart+Chromium builds for a long time, they use a different approach (V8 bindings layer) that doesn't require WebKit changes. However we only use these builds for fast development edit+refresh, for deploying Dart code you should use dart2js (it's just like deploying CoffeeScript, C code via emscripten, etc).
    • nickporter 14y ago
      Right, I wasn't saying this in a negative way :). That is quite interesting!
      • jmesserly 14y ago
        Yeah, tone can be hard to guess from text. Figured the link would be helpful either way :) disclaimer: I'm on the Dart team (libraries, not core language/VM/dart2js). As exciting as it would be to have Dart VM in Chrome, personally I hope the order is more like: * dart2js and VM work the same way (basically true already, modulo a few quirks unlikely to affect program behavior. It's not any worse than your typical web standard polyfill, probably a lot better.) * The language spec is standardized. * People like Dart, and it becomes really popular for building web apps. * We have great Dart<->JS interop and it's possible to make the two native VMs work nicely together in the same browser. * The toolchain makes it practically impossible for a web developer to publish an app that only has .dart files, without the .js version that works on all browsers. * At that point, it might make sense to add the Dart VM to a browser purely a performance optimization. Of course a lot could change between now and then. For example, if JS engines keep getting faster and introduce enough fast stuff (like typed arrays, asm.js, etc), maybe we can achieve the speed we need with dart2js. Fortunately, there are plenty of folks that work on Blink/Chromium that share both the enthusiasm and skepticism that the web community has about Dart. As someone that works on it, I deeply want our team to succeed, but I would like to see it happen in the right way--open web and open source friendly.
• deleted 14y ago
  [deleted]
  • hiker 14y ago
    Quite the opposite, see http://www.chromium.org/blink#vendor-prefixes http://www.chromium.org/blink#vendor-prefixes
    • deleted 14y ago
      [deleted]
    • deadc0de 14y ago
      I mean use the monopoly to take the tech, clone, tweak, and then don't contribute back. Thankfully google will keep it open source since they're making money from it quite indirectly. But still.. A "fork you" to apple that would make the web suffer. Douchy.
      • basch 14y ago
        Isnt "take the tech, clone, tweak, and then don't contribute back" exactly the model Apple used to create webkit from khtml. If memory serves, the khtml team was incredibly unhappy with apple trying to submit giant monolithic and undocumented commits.
        • deadc0de 14y ago
          It was not ok then, and it's even more not ok now, considering Chrome's market share.
          • fpgeek 14y ago
            What Google's doing now is far kinder than what Apple did then. As noted above, Apple "contributed back" big monolithic patches. By contrast, Google is providing access to a version-controlled repository. The latter is far easier to work with, of course.
      • 14y ago
• cpeterso 14y ago
  The good news is no -blink prefixes! Blink, like Mozilla, will avoid shipping vendor-prefixed features: 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 ... we will instead keep the (unprefixed) feature behind the “enable experimental web platform features” flag in about:flags until the feature is ready to be enabled by default.
  • mikewest 14y ago
    Yes! Prefixes are damaging. We're hiding things behind flags instead, which gives savvy developers the chance to experiment without the risk that sites will begin to depend on those experiments.
  • kmfrk 14y ago
    I, for one, can't wait to cut 20% of the code in my stylesheets.
    • kaolinite 14y ago
      In the meantime, you can use LESS mixins to reduce duplication. This library is pretty handy: http://lesselements.com/ http://lesselements.com/
      • robryan 14y ago
        The parent was likely referring to them being in the stylesheet at all, rather than the way they are managed. Any stylesheet compiler is still going to have the vendor prefixes in the compiled stylesheet.
        • plorkyeran 14y ago
          In practice you won't actually be able to drop them from the compiled stylesheet for a very long time, of course.
• jacob019 14y ago
  removing old code feels so good
• deleted 14y ago
  [deleted]
• oellegaard 14y ago
  I know it might be an unpopular comment, but I really don't like this. I had hoped every browser would eventually use the webkit rendering engine. I have a hard time feeling sorry for those engineers that have to maintain compatibility, when I think of the many frontend engineers that now have to test a different rendering engine :(
  • TazeTSchnitzel 14y ago
    Rendering engine monoculture isn't a good thing though. If a single rendering engine dominates, then there is less reason to write standards-compliant code - after all, everyone uses WebKit, right?
    • natem345 14y ago
      Just like everyone used IE6 back in the day!
      • TazeTSchnitzel 14y ago
        Yeah, it was wonderful! The alternate browsers just accepted the standards dictated by the dominant browser, and that didn't cause any problems at all! /s
    • jmesserly 14y ago
      Yeah. It would be the same problem that WebSQL had: http://www.w3.org/TR/webdatabase/ http://www.w3.org/TR/webdatabase/ As much as I was sad to see it go, I sympathize with their problem. If you just have a single C/C++ implementation with no spec, it's a lot harder to know, as a user/web developer, what the correct behavior is and what you can rely on.
      • TazeTSchnitzel 14y ago
        Indeed. It's a shame WebSQL died, though, since I would have loved to have had SQLite in the browser. Maybe the solution would have been to specify a similar, new, SQL database for the web? I would have liked that more than IndexedDB.
• AaronMT 14y ago
  So which Chromium will Opera be based on now?
  • Me1000 14y ago
    Opera will be using Blink: http://www.brucelawson.co.uk/2013/hello-blink/ http://www.brucelawson.co.uk/2013/hello-blink/
  • progers7 14y ago
    Opera will be using Chromium+Blink under the hood.
  • TazeTSchnitzel 14y ago
    They're following them to Blink. So we'll have Trident in IE, Gecko in Firefox (OS), WebKit in (Mobile) Safari and Blink in Chrome/ium and Opera.
    • hbbio 14y ago
      Firefox will be using Servo.
      • dragonwriter 14y ago
        > Firefox will be using Servo. Maybe, someday. Servo is a long-term, high-risk effort.
• tantalor 14y ago
  Does anybody have a link to their source tree?
  • deleted 14y ago
    [deleted]
  • igrigorik 14y ago
    https://chromium.googlesource.com/chromium/blink https://chromium.googlesource.com/chromium/blink
• deleted 14y ago
  [deleted]
• saddino 14y ago
  A little out of left field here, but if anyone is interested in working on the other multi-process browser (for OS X at least) I've just released Stainless as open source. Stainless was a hack that actually became quite popular while we Mac users waited for Google to release Chrome for our platform. http://stainlessapp.com http://stainlessapp.com
• deleted 14y ago
  [deleted]
• deleted 14y ago
  [deleted]
• dave1010uk 14y ago
  This paragraph makes me happy: From a short-term perspective, monocultures seem good for developer productivity. From the long term perspective, however, monocultures inevitably lead to stagnation. It is our firm belief that more options in rendering engines will lead to more innovation and a healthier web ecosystem. From http://www.chromium.org/blink/developer-faq http://www.chromium.org/blink/developer-faq
  • jammmuel 14y ago
    I find this a doubled-edged sword. Monocultures are said to foster a culture of laziness, apathy. This hasn't been the case with WebKit. Don't get me wrong - competition is healthy. I'm simply thinking of how Jovinder experiences the web.
    • fpgeek 14y ago
      If you think WebKit hasn't fostered a culture of laziness and apathy among mobile web developers, try browsing the web using Firefox for Android or IE (on Windows Phone) sometime. I've lost track of the number of times I've had to pretend to be something different (desktop Firefox, default Android, Mobile Safari ...) to make a website usable. Every time I have a fresh Firefox install on Android, the first extension I install is Phony.
• oscargrouch 14y ago
  Chromium have a very agressive innovative agenda, compared to other players.. im sure they will benefit from this move.. They were probably carrying webkit in their own shoulders anyway, cause nobody does so much experiments as chromium team does.. If they have the energy to do it.. thats good news for us :)
  • guywithabike 14y ago
    > compared to other players Do you have a source for this?
    • randomfool 14y ago
      http://blog.bitergia.com/2013/03/01/reviewers-and-companies-in-webkit-project/ http://blog.bitergia.com/2013/03/01/reviewers-and-companies-...
• mikewest 14y ago
  The Chromium team will be running a Hangout tomorrow to answer any questions that pop up. Hit this Moderator page to ask whatever's on your mind: engineering leads Darin Fisher and Eric Seidel, product manager Alex Komoroske, and developer advocate Paul Irish will be more than happy to answer: http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&v=5 http://google.com/moderator/#15/e=20ac1d&t=20ac1d.40&#38...
• ttrreeww 14y ago
  Wow, finally an attempt to speed up the DOM
• macrael 14y ago
  So, I'm pretty sure this is a correct history: 1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing) 2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1] 3. Google says that the pain in maintaining their separate, non standard, process architecture is too much of a burden to continue to contribute into WebKit proper, so they must fork. Why can't Chrome implement WebKit 2? Are there major advantages to Chrome's process model that are not present in WebKit 2? Is there a reason why WebKit 2 cannot be patched to provide those advantages? This seems like a failure of open source. [1]: see the first paragraph on http://trac.webkit.org/wiki/WebKit2 http://trac.webkit.org/wiki/WebKit2
  • jimray 14y ago
    Reading the utterly passive tone of the OP, with Webkit somehow "emerging" out of KHTML all on its own, nary a mention of Apple, makes it pretty obvious this move is mostly about politics.
  • makomk 14y ago
    Apple's current commit approval policies appear to be fairly hostile to non-Apple developers and users of WebKit, and especially to non-Apple users of WebKit2. They now reserve the right to break builds on non-Apple platforms randomly and delay patches to fix them, amongst other things.
    • randomfool 14y ago
      Correct- Apple's announcement of the WebKit2 changes- https://lists.webkit.org/pipermail/webkit-dev/2013-January/thread.html#23255 https://lists.webkit.org/pipermail/webkit-dev/2013-January/t...
      • voltagex_ 14y ago
        This post put me completely on Google's side: https://lists.webkit.org/pipermail/webkit-dev/2013-January/023263.html https://lists.webkit.org/pipermail/webkit-dev/2013-January/0...
• math0ne 14y ago
  I don't get why people think this is a good thing. The web was just starting to become standardized around webkit. This is a pure business decision, google want to splinter the web making their version of it the best bringing all the advertising under it's roof. Pure and simple greed.
• glasshead969 14y ago
  https://lists.webkit.org/pipermail/webkit-dev/2013-April/024384.html https://lists.webkit.org/pipermail/webkit-dev/2013-April/024...
• deleted 14y ago
  [deleted]
• gioele 14y ago
  Can someone explain this benefit: > Establish a simpler, stricter tree-gardening system that does not require 2 full time engineers per day "tree-gardening"?
  • mikewest 14y ago
    WebKit and Chromium are different repositories, and point to each other via a "DEPS" (dependencies) file. We roll new revisions of WebKit into Chromium regularly, and call the process of diagnosing and fixing problems with the rolls "Gardening": http://www.chromium.org/developers/how-tos/webkit-gardening http://www.chromium.org/developers/how-tos/webkit-gardening is a good reference.
    • tripzilch 14y ago
      Hey, clicking around that Wiki it has some pretty interesting information. Do other large open-source projects have a very similar workflow?
      • bradleyjg 14y ago
        The most significant long term upstream-downstream relationships are probably the linux distros to the kernel.
      • zanny 14y ago
        You mean having full-time engineers handling merge conflicts / upstream breakage / regressions / running test suites? In anything sufficiently large, that becomes a major issue inevitably. Almost any project worth its salt has someone doing testing. But it is really time consuming.
• deleted 14y ago
  [deleted]
• AshleysBrain 14y ago
  Named after their favourite HTML tag?
  • malandrew 14y ago
    At the risk of being downvoted as a comment that belongs on reddit, it'd be interesting to see a new rendering engine one day named Marquee.
• xxgreg 14y ago
  These bits from the docs are really interesting. Can anyone here explain them in more detail? (I've also posted them as questions in moderator) "we’d like to explore even larger ideas like moving the entire Document Object Model (DOM) into JavaScript. This has the potential to make JavaScript DOM access dramatically faster" "Removing obscure parts of the DOM and make backwards incompatible changes to obscure parts of the DOM that benefit performance or remove complexity."
  • mikewest 14y ago
    My expectation is that we'll be posting more design docs to chromium.org more frequently. The best way to stay on top of that will be to join the blink-dev group (https://groups.google.com/a/chromium.org/forum/?fromgroups#!forum/blink-dev https://groups.google.com/a/chromium.org/forum/?fromgroups#!...) which will be ramping up shortly.
• meomix 14y ago
  And so begins phase 2 of embrace, extend and extinguish. It's just what large tech companies do now days.
  • jxi 14y ago
    If you're going to badmouth this decision, then please at least read the articles and address the reasons they mentioned. It's pretty stupid and pointless to make irrelevant generalist statements.
    • lawl 14y ago
      Well I just came across this: http://prng.net/blink-faq.html http://prng.net/blink-faq.html I think it shows (some of) the concerns really well. Not saying EEE is the strategy Google is trying to do here. But it's certainly a possibility and we should pay close attention IMO.
      • jxi 14y ago
        Wow, that is the most ridiculous thing I've ever read. Pretty sure it's a troll post trying to make frontpage with sensationalist bullshit. For example, he claims it's a political move, yet the official FAQ lists many practical reasons for the move. Also, he says it will fragment the web: half the comments in this very thread explains why it won't. Then he says it's not open source because it's hard to understand how an HTML parser works? wtf?
        • coldtea 14y ago
          >For example, he claims it's a political move, yet the official FAQ lists many practical reasons for the move. So what? They couldn't make up excuses? >Also, he says it will fragment the web: half the comments in this very thread explains why it won't. And others argue why it will. >Then he says it's not open source because it's hard to understand how an HTML parser works? wtf? A complex multi-million line project representing 1000s of manyears of work, essentially needs dedicated full-time highly skilled engineers to be forked. It might be technically "open source", but it's not bazaar-style open source, the way something like a simpler program or web framework is. Even a highly skilled C++ programmer has to spend months to understand the WebKit codebase, much less do any pervasive changes or take over the code. This kind of devotion cannot be sustained by unpaid volunteers. That makes it essentially un-forkable unless some other company can devote resources to it. Highly complex codebases seldom progress much as community projects after the original company has abandoned the paid contributors (see the lackluster Gnome development the last 10 years, after all the late 199x early 200x backers backed down, Open/Libre Offices --haven't progressed much from 2000's SUN's offering--, etc). And those are the cool cases, others die completely or languish (e.g Hazel's Nautilus, or Evolution).
• deadc0de 14y ago
  A Microsoft-worthy move..
• checker659 14y ago
  Can anyone from the chromium team answer few questions? 1. How does this affect the build system? 2. Will Blink always remain a fork of Webcore, or do you plan on replacing all the bits and pieces from Webcore with your own code? 3. Are we still stuck with the LGPL license? 4. Does this change anything in the spectacularly lacking source documentation / porting guidelines front. 5. You mentioned stripping out a lot. Will this have a significant impact on the size of the codebase? 6. Will the rendering architecture be changed completely? Or, is the render layer hierarchy still intact in blink? Thanks!
  • mikewest 14y ago
    1. Chromium will continue to build via gyp. 2. I'm not sure what you mean. 3. 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. See my favourite file, http://trac.webkit.org/browser/trunk/Source/WebCore/page/ContentSecurityPolicy.h http://trac.webkit.org/browser/trunk/Source/WebCore/page/Con... for example. 4. WebKit and Chromium have historically had differing opinions regarding what makes a "good" comment. I think you can expect Blink's code to tend more and more towards Chromium-style as time goes on, but it's not going to happen overnight. 5. ~5 million lines of code that we don't currently compile or run in Chromium. That's a bit, but it won't have much effect on the binary size. 6. Short term, not much will change. Longer term, a few things will probably happen: for instance, the widget tree will likely be removed, and we'll likely be able to step back and reevaluate some changes in light of that.
    • nnethercote 14y ago
      I mentioned above that the last time I measured (late 2012) the entire mozilla-central repository it was 4.488 million lines of code. How many lines is Chromium? How on earth can you be removing 5 million LOC?
• supervillain 14y ago
  Well I just killall chrome processes anyway for my desktop to be usable, these multiple and dozens of chrome processes is an absolute nuisance, and it crashes my machine, my desktop, chrome is not even reliable coz it crashes on me everytime. if you want to get pissed bigtime, use chrome.
• tambourine_man 14y ago
  Very sad news. This seems more of a political/economical move than a technical one. Two of the biggest players (and now arch rivals) sharing what's arguably the most strategic piece of code there is, couldn't last very long. It's a shame though. It was probably the biggest open source success story. An open source monoculture is not the same as a proprietary monopoly.
  • zanny 14y ago
    Open source monocultures can be pretty bad. Look at how Mir has jumpstarted Wayland interest and adoption after it has stagnated for a few years. Likewise, look at how GCC is now dramatically improving since Clang became competitive. Or look at how Firefox back in the good old days picked up the pace after Chrome(ium) happened.
    • tambourine_man 14y ago
      Multiple efforts can increase competition or spread resources thin. We already have 3 major engines. Do we need a fourth? The Linux Kernel combines all efforts in a single thriving project, while we have multiple desktop distributions struggling to get a single digit percentage of the market.
      • zanny 14y ago
        One is closed source, so you can't even consider it for adoption. Google is now proclaiming its dissatisfaction with webkit, and Gecko is a 20 year old codebase now, and Google likes control. Though considering how they fund Mozilla in the first place, if they wanted Gecko, they would just buy Mozilla. They keep the lights on anyway.
• speg 14y ago
  , mall,
• Siecje 14y ago
  Why doesn't Google just make its WebCore open source and then merge with Webkit2 and make everything better? Google doesn't make money off Chrome...
• slacka 14y ago
  > "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" On my 2GB netbook, chrome has gone from my preferred browser to unusable due to the high memory footprint of recent builds. I wonder if this cleanup will help get the memory down to something reasonable like where it was up until Chrome 10 or so.
  • smrtinsert 14y ago
    Recently it's been crashing for me left and right. This seems to happen with chrome over the years, ebb and flow of functional non-functional. I just switch back to Firefox during that time.
  • smackfu 14y ago
    Doubt it. I think these were part of the project that weren't even distributed.
• programminggeek 14y ago
  Finally, a rendering engine that optimizes performance for the <blink> tag!!!
• Uchikoma 14y ago
  Ah, another web rendering engine, some more years with a buggy Selenium alpha driver which doesn't work so people need to do manual tests. Progress!
• charris66 14y ago
  Linus Upson, vice president of engineering for Chrome, did forgot to take the tampon out of his arse before the final shots became decided.
• obilgic 14y ago
  Off topic, How do you clone a project like that big? Git is still trying to receive the objects %1 of 2,200,337
• dave1010uk 14y ago
  Will Blink have any direction from non-Google employees, in the same way WebKit has non-Apple reviewers?
  • igrigorik 14y ago
    Yep, tips for where and how to engage with the project: http://www.chromium.org/blink#participating http://www.chromium.org/blink#participating
• midko 14y ago
  You can read more about the intended architectural changes at Blink's project page: http://www.chromium.org/blink#architectural-changes http://www.chromium.org/blink#architectural-changes
• jacobr 14y ago
  So what will the new User Agent string be? "Mozilla/5.0 (X11; Linux x86_64) Blink/537.33 (KHTML; like WebKit; like Safari; like Gecko) Chrome/27.0.1438.7"? Hopefully people will finally start using feature detection rather than user agent detection...
  • mikewest 14y ago
    The user agent string is, for the moment, remaining exactly the same format. For better or worse, all those crufty bits are currently necessary for compatibility with sites doing a poor job of sniffing out functionality.
• alan_cx 14y ago
  Er, guys..... https://www.youtube.com/watch?v=oLvx7lVwpzY https://www.youtube.com/watch?v=oLvx7lVwpzY This is bad.
• rhapsodyv 14y ago
  Wow! Chrome will support <Blink> tag! Great! :-P
• Toshio 14y ago
  A Short Translation from BS to English of Selected Portions of the Google Chrome Blink Developer FAQ: http://prng.net/blink-faq.html http://prng.net/blink-faq.html
• danpeddle 14y ago
  About enabling experimental features via flags - I hope there will be an option buried in there somewhere for curious people to "go nuts" and enable a large slew of functionality in one step, appropriately warned. I can see that being a pain, but much easier than having to go one by one on obscure features with a non-technical audience. I love seeing what creative devs are doing out on the fringes, and having to dig around in flags every time something new gets added could potentially get pretty annoying. The benefit of vendor prefixes was this - if you were on a latest version, not just dev/canary channel, there was a lot which was turned on by default, even if theoretically it wasn't stable. That was actually quite a good driver of fresh technique and innovation, seeing this straight away, despite the major hassle of bloated CSS. It's inspirational seeing people who maybe aren't totally technical being able to get their hands on very fresh stuff without having to completely hand hold them on every step required to get it going. Really, a lot to be said on this topic, but just wanted to mention this as didn't see it discussed yet.