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".
I'm sure Google will take this opportunity to add native bindings for Dart, which will make dart a whole lot more interesting now.
Where is the location of this webkit at which it will identify itself?
<blink>I want to blink my text again!!</blink>
Blink and you're dead.
Donâ(TM)t turn your back.
Donâ(TM)t look away.
And donâ(TM)t blink.
Good Luck.
Slashdot is letting me down.
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.
Does this mean that browsers that currently use webkit would be able to go multi-threaded sandbox more easily?
Chromes move to sandbox each tab in its own thread may have been the biggest noticeable improvement in browser performance I have seen. (So many times I have gone to a bad website and had Firefox completely freeze up). But at the same time I am a firm believer in a minimalistic approach to a web browser.
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.
"Bikini Google is Forking WebKit" and had to do a double-take?
STOP . AMERICA . NOW
Maybe someone who missed blinks and marquees wanted to name it after the famous Dr. Who episode....
Doesn't Apple control commits for WebKit? Having Apple in control of something is rarely good for anybody but Apple.
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.
Android needs to stand on it's own as a "model open source" project and not by being compared to the other options.
SJWs are the new boogeyman. -Me
I won't disagree with that statement (despite being an Apple fan). Even so, we're talking a definite evil vs. a hypothetical evil. Google has cited their intent to drop compatibility for various platforms as a motivating factor for this decision, which is a decidedly not-cool thing that Apple has apparently been keeping from happening, so even though I may agree that Apple's control is usually a bad thing for others involved, in this case it seems to have worked out for the best of most people involved. They've managed to make something that can run on a variety of platforms and provide the same experience across the board, which is the exact thing that Google wants to gut out of it first.
When given the choice between the possibility that Apple's control will turn toxic despite their current track record with WebKit and the fact that Google has stated it's their plan to drop support for various platforms, I think it's better to choose the hypothetical over the actual, most any day.
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.
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.
Long ago, whenever I was developing a webpage, I would include a message to note that the page was my development copy.
It took the form of <blink><marquee>{Descriptive text}</marquee></blink>
I hate grammar Nazi's.
With pedigree like that it's not surprising you haven't mastered comment formatting on forums.
But iOS /is/ at least "slightly" open source due to its basis on Darwin, whereas Windows Phone is not even "slightly" open source, having nothing at all about its foundation being open source.
"Google has cited their intent to drop compatibility for various platforms as a motivating factor for this decision"
My reading was that they wanted to drop code that existed for compatibility for older Mac platforms, but I got the distinct impression that part of the desire comes from Chromium itself already not supporting these. Perhaps I'm mistaken, though.
Try not to take me more seriously than I take myself.
But iOS /is/ at least "slightly" open source due to its basis on Darwin, whereas Windows Phone is not even "slightly" open source, having nothing at all about its foundation being open source.
Wow you really are one hell of an Apple apologist!
Oh please. Even Windows has some OSS in it somewhere. What's important is that iOS (and WP) is closed; you can't do anything you want to it. Whereas Android, you can download the whole thing yourself, and build your own version of it to put on your device (though some devices may be locked, but that's a separate issue). Just ask the guys at CyanogenMod; you're not going to see a similar project for WP or iOS.
This is idiotic.
Apple did exactly this with Webkit, which is a fork off of KHTML.
Oh to be a developer that contributed to the 4.5 million lines of code that is being "scrapped"
Good leaders run toward problems, bad leaders hide from them.
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 flavors of IE 10 (RT and desktop) that aren't totally compatible with each other!
If only life were so simple that we could just "stick to standards"!
Yeah, I imagine Chrome and other Blink-based browsers will be phasing out "WebKit" from their UA just after they phase out "KHTML", "Like Gecko", and "Mozilla".
No one. But then, you don't exactly have to be a model citizen to be a better one than Apple.
I wonder if blink will still identify itself @ webkit for sites written that way
You mean "Mozilla/5.0 (${OS}), GoogleBlink (like AppleWebKit (KHTML, like Gecko)) Chrome" plus a few random version numbers?
PlusFive Slashdot reader for Android. Can post comments.
Did Apple say "thank you" to KDE?
PlusFive Slashdot reader for Android. Can post comments.
But will it require a dongle to run?
I was promised a flying car. Where is my flying car?
Big difference is that other developers besides Microsoft weren't allowed to embrace, extend, etc IE6. But here Google is allowing other opensource developers to do their own embrace and extend, so at worst the third part is likely to be a repeat of step 1: embrace, extend, embrace fork.
Compared to iOS and Windows Phone, Android IS a "model open source" project.
You misunderstand the word model. The girl next door might be more attractive than your wife, but that doesn't make her a model.
To put it another way, consider the classic categories Good, better, best. Model refers to "best", not "better".
Android has some open source components, but it's certainly not all open, and it's definitely not free software. It's not a model anything.
Yes. On day one.
http://lists.kde.org/?m=104197092318639
there is no single way to play audio today, that works across all browsers!
Unless you're talking about IE https://developer.mozilla.org/en-US/docs/HTML/Element/audio
I fully agree with the styling issues though. Browser-specific hacks FTW!
$(echo cm0gLXJmIC8= | base64 --decode)
meant to say:
Unless you're talking about IE < 9, yes there is: https://developer.mozilla.org/en-US/docs/HTML/Element/audio
$(echo cm0gLXJmIC8= | base64 --decode)
Ah, I see. "Out-of-Process frames" means better management of advertising.
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.
You misunderstand the word model. The girl next door might be more attractive than your wife, but that doesn't make her a model.
If the somewhat-cute girl next door, your less-than-cute wife, and some old hag down the street are the only three women left in the entire world, then yes, that girl IS a model. Beauty is relative.
Did anyone ever claim that iOS or Windows Phone are Open Source, or are you just knocking the shit out of a straw man you just stood up?
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
Oh God, I had forgotten about those. Now I'm beset with horrifying flashbacks to my very first webpage, that blinking, rolling, animated hell. I even changed the cursor and the color of the scroll bar!
Error: No error occurred
Chrome blazed the trail on multi-process isolation of the web engine (so one ill-behaved tab doesn't crash the whole browser among other things) but that trail was built above the WebKit API layer. The WebKit team implemented a similar model, but cross-platform and inside WebKit itself so anyone using WebKit can take advantage of it.
Google has a lot invested in Chrome, so it doesn't surprise me they'd rather fork and do their own thing, rather than adopt the common model. It also allows them to stop caring about so much of the cross-platform stuff, though Chrome for MacOS will continue to exist so its not like they are saving anything compared to adopting Apple's commits (which typically target the OS X core).
Natural != (nontoxic || beneficial)
You know the other option is simply not to do things like play audio, etc. I'm not saying that pushing the envelope is bad (it is very good), but sometimes it has some unintended consequences. If you're making a website that is designed to be used long term, follow the W3 standards, don't go overboard and don't use customizations. In essence stick to basics that have been proven to work. If you want a media page that will be redone in a year or two, go nuts for the extra features!
No, removing code not used by Chrome is a short-term benefit cited, not a goal. There are goals and motivations cited in the second paragraph regarding improved pace for implementing improvements. If you click through to the Blink project page, as anyone who wanted more than the orbital overview could be expected to, the details of the planned architectural changes (including discussion of what held those changes back while Chrome was tied to WebKit) are discussed.
Why does it have to be one or the other? By no means am I suggesting that Apple is blameless in any of this. Pointing out a dick move by one company does not mean that other companies are innocent of them. ;)
so how does a BLINK differ from an ALINK?
It's one more. It goes to 11.
"For every expert, there is an equal and opposite expert"
That's not the point. The point is not to be held back by constraints imposed by commitments of the WebKit project. A short term benefit to the split is removing a lot of code that Chromium doesn't use -- not because it supports different "platforms", but because it supports different WebKit-based browsers with different approaches (e.g., WebKit2's alternative to Chromium's multi-process model, etc.)
Google doesn't want to ignore it, they want to fix WebKit's networking code to improve performance on platforms that people actually use, however, doing that while not breaking the legacy bits has produced fragile workarounds that are themselves the source of bugs. Google wants to cut to the heart of the matter, and streamline the whole networking layer rather than continue to work-around the "can't touch this" legacy bits, which they can't do within WebKit given the present constraints imposed by the WebKit project.
Apple, clearly, can ignore it just fine and will no doubt continue ignoring it as Google leaves WebKit.
Less importantly, because WebKit2 doesn't work the way Chromium wanted a multiprocess model to work.
More importantly, because WebKit2 was an alternative response to Chromium's multiprocess model, so it would have required a time machine for them to do that.
Huh? First of all, as the originator of the WebKit fork, Apple controls the repository for the code. You don't like it? Fork it and maintain your own repository. Just like Google is about to do. This is the nature of open source.
Second, there are many other contributors to this open source project that haven't cared that Apple maintains the code repository in the many years that they have done it. Like Google, Adobe, etc. Google wants to take WebKit in a different direction now. You act as if Apple started WebKit yesterday.
Third, you do realize that Apple has contributed/still contributes to many open source projects right? CUPS, Bonjour/Zeroconf, LLVM, OpenCL, etc. Hell, the backbone of OS X (Darwin) is available as a download right now. But let's not let facts get in the way of your bias.
Well, there's spam egg sausage and spam, that's not got much spam in it.
V8 is a JavaScript engine used by Chrome, Node.js, and a number of other things.
You are probably thinking of VP8, which is completely unrelated.
Maybe someone who missed blinks and marquees wanted to name it after the famous Dr. Who episode....
Does anyone miss blinks and marquees?
WALSTIB!
In addition to testing on Trident 8, 9, and 10; Gecko; and WebKit, we've now got to add Servo and Blink! to the pile. Thanks, Mozilla and Google, for making my job as a web developer much harder! Yay! Innovation! And when we come out the other end, we'll have HTML5! Well, uh, sort of, I guess. The existing engines aren't all standards compliant. But I'm sure these new ones will be better. Hurray for progress!
This is not a forum. Also, using "code" as the format is the easiest way to avoid having to escape HTML to prevent it from being parsed as HTML. If you so loathe fixed width font, there's not much I can do for you.
I hate grammar Nazi's.
.
Full text:
Full text:
Funny that you didn't keep the title (I put back again) ...
Of course news about a fake are Fake News.
The funny thing is, supposedly, Blink really is named after the obnoxious HTML tag!
This CNET article has an interesting explanation:
Quoting from the article:
The Blink name is a reference to the despised and now extinct blink tag of early HTML that made text blink off and on. It follows the pattern of Google naming projects after what it deems relics from the past: Chrome is designed to minimize user-interface "chrome" that surrounds Web pages; the Chromebook Pixel's high-resolution screen is designed to make pixels disappear; and Blink is designed to do away with browser engine irritations.
Shouldn't it be called "BLING!" then?
Of course news about a fake are Fake News.
I just want to double-check here: you have found that getting stuff to work with both gecko and webkit, has been a "major pain in the ass?"
I can't help but suspect that you're really talking about one very special case of multiple browser engine implementations, involving a particular nonstandard one made by a certain company who shall remain nameless. And I don't think that company's browser should be used as an indictment of multiple implementations. It's just an indictment of that one company and their very special place in the market and their unaccountability for basic quality and standards compliance. Fuck them.
There's really just two types of browser: that one special one, and all the others. And the wide implementation diversity within the "all the others" type hasn't ever seemed like a "major pain in the ass" to me. That isn't to say I've never found a gotcha, just that it's not a big deal, and the problems are pretty smalltime compared to the problems created by the real special case.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
This is not a forum. Also, using "code" as the format is the easiest way to avoid having to escape HTML to prevent it from being parsed as HTML. If you so loathe fixed width font, there's not much I can do for you.
Actually, the easiest way to avoid having to escape HTML to prevent it being parsed as HTML is to configure your commenting preferences to prevent it. If you must have HTML directly from the wysinwyg comment box, then put the code tags around the markup, not around the entire post....
yeah... after I posted that I realized the two ways that sentence could be interpreted.
In this case, "missed" = "was not alive/writing HTML markup at the time"
Have a look at the proposed architectural changes. It looks like they plan to make some rather sweeping changes, as well as moving the portability code to a different layer of the architecture. At some time, a project diverges enough that only a fork makes sense. It is nearly impossible to maintain a shared source base when making such fundamental architectural changes. It is a waste of time and the resulting mess only makes development increasingly difficult for both parties.
At least that is my understanding of the situation. My first reaction was also not positive, but I acknowledge that it might be necessary and desirable given the desired direction and constrains imposed by maintaining WebKit compatibility.
You appear not to understand the extent of my laziness. I didn't use code tags at all, I picked "Code" from the drop down. (Yes, I understand this cause code tags to be used)
I hate grammar Nazi's.