Slashdot Mirror
Blink! Google Is Forking WebKit
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.'"
Opera has said that they will also be moving to Blink as they transition away from the Presto engine.
Blink and you’re dead.
Don’t turn your back.
Don’t look away.
And don’t blink.
Good Luck.
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.
If by "@" you mean "as", then, probably. I mean, Chrome's user agent string now also identifies itself as "Mozilla", "KHTML", "like Gecko", and "Safari" as well as "Chrome" and "AppleWebKit".
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.
<blink>I want to blink my text again!!</blink>
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.
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.
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.
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
...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)
Which is exactly why CSS preprocessors were invented (ok, at least part of the reason).
Anyone that is using prefixes all over their style sheets is doing it wrong. It's so much simpler to simply use `border-radius: 5px` than to have to deal with `-webkit-border-radius: 5px; -moz-border-radius: 5px;` .... etc.
Just stick whatever prefixes you think you're going to need this month inside the mixin for `border-radius` and let the preprocessor handle all that prefix garbage.
Of course, you could always just be an asshole like me and completely ignore the fact that prefixes even exist.
Someone flopped a steamer in the gene pool.
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.
I get the whole need to fork thing... but why name it after the most annoying non-standard tag from the 90's? Someone in marketing should be sacked.
Tomorrow is another day...
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.
Blame Microsoft and web developers.
You forgot about the marquee tag. Protip: If you want to bring a browser to its knees, nest marquee tags.
Compared to iOS and Windows Phone, Android IS a "model open source" project. Of course, compared to other open source projects it has some serious problems, but iOS and WP aren't open source in the slightest, so compared to those two Android looks pretty good.
Maybe someone who missed blinks and marquees wanted to name it after the famous Dr. Who episode....
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.
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:
If it is called the webkit tag, does this mean that we'll finally see the return of the blink tag?
signature is pants
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.
With pedigree like that it's not surprising you haven't mastered comment formatting on forums.
It is probably hard to type correctly after having his fingers broken multiple times.
Learning HOW to think is more important than learning WHAT to think.