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.'"
I wonder if blink will still identify itself @ webkit for sites written that way
"We think WebKit has become too mainstream for people as cool as we are"
Opera has said that they will also be moving to Blink as they transition away from the Presto engine.
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... :-/
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.
I imagine most browsers will start sending a UA with both blink & webkit and then slowly phase out the webkit token.
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".
<blink>I want to blink my text again!!</blink>
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.
How do you figure? If Blink becomes better than WebKit, what's to stop Apple from dumping WebKit and switching to Blink? Or just forking it back? After all, it's not like Google is going to suddenly stop supporting OS X with Blink, given that they'll be using Blink in Chrome, which is available for OS X. They may drop iOS support, but iOS is based on OS X so I wouldn't think that updating it would be too difficult in the grand scheme of things. And if they do drop iOS (which would be a rather huge dick move, but one that would make business sense), wouldn't that be rather evil of them? After all, WebKit, while under Apple's auspices, has been maintaining compatibilities for a number of systems that Apple doesn't own or control (e.g. Android), which is exactly the sort of thing Google wants to stop doing so badly that they're willing to fork the project.
And since it's forking from WebKit, which Apple already uses, it shouldn't be too hard for a company of Apple's size to make the changes necessary to swap out the rendering engine or provide the missing compatibility for their extremely small number of devices and OSes if they should choose to switch to Blink. Safari itself came together fairly quickly in the first place, after all, and that involved a lot more effort.
In the end, this is a thing that remains to be seen whether it will be good or bad for everyone. Google clearly thinks that it's in their best interests, but we have no way of knowing what effect splitting the efforts will have on the market in general. Smaller browsers that make use of WebKit and can't afford to switch to another engine easily may be the most affected by this, since the rate of progress for WebKit will likely decrease in the coming years. Similarly, Blink may not enjoy the rate of progress that WebKit currently sees. After all, two tech titans working together can usually get a lot more done than each one working separately.
Blame Microsoft and web developers.
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.
Pretty good is actually pretty bad.
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....
Web developers mainly. The whole "compatibility" and "don't break any page" bullshit has always been developers' fault.
But one needs to be aware that probably, when all this started, there was no good way of doing "capability testing" instead of browser sniffing, as Javascript was there but was a "stupider" language. Also, browsers did do things in a very different way, not like nowaways when most differences are small layout issues.
There was also no automatic updates, so probably the first version of IE was there along with the improved version, so if you just sent frames to everyone, old IE versions would break.
Still, there is no excuse in doing this nowadays, period. Browsers should break the goddamn sites that still do this, and for developers: if you haven't updated your site from the time when this kind of browser sniffing was required, please get out of the internet, you are making it a worse place.
Opera was the only browser that really tried to not spoof any other browser's identity (unless required). When it got to version 10, it broke many pages.
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.
Smaller browsers are sorta screwed... but I think WebKit2 is likely to be the better option with what we currently know...
- WebKit2 is essentially WebKit with multithreaded sandboxing baked-in; the whole point was so anybody who uses WebKit2 will get the multithreaded sandboxy-goodness free. At least on Windows and OS X. On Linux, WebKit2 is still in development, as most apps use a widget toolkit like Qt or GTK+; Linux developers have to wait for the toolkits to add in support. Qt is targeting version 5, and GTK+ has it somewhere in the pipeline as well.
- Chrome has its own sandboxing model, separate from WebKit. With Blink forking, it's all but certain the "baked in" sandboxing Apple and the WebKit community put into WebKit2 will be pulled out entirely - Google doesn't need it, doesn't want it, and it complicates development & maintenance.
-- Sometimes you have to turn the lights off in order to see.
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.
And if they do drop iOS (which would be a rather huge dick move, but one that would make business sense), wouldn't that be rather evil of them?
Apple doesn't allow any browser engine besides their own WebKit implementation on iOS.
So removing iOS support from Blink seems to be a given, because it can't be used anyway.
So if there's a dick in this equation, it's most certainly not Google.