Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Blink! Google Is Forking WebKit

Soulskill posted about a year and a half ago | from the reworking-the-basics dept.

Chromium 252

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.'"

cancel ×

252 comments

Sorry! There are no comments related to the filter you selected.

I wonder if blink will still identify itself @ web (2)

Anonymous Coward | about a year and a half ago | (#43352327)

I wonder if blink will still identify itself @ webkit for sites written that way

Re:I wonder if blink will still identify itself @ (2, Informative)

yincrash (854885) | about a year and a half ago | (#43352457)

I imagine most browsers will start sending a UA with both blink & webkit and then slowly phase out the webkit token.

Re:I wonder if blink will still identify itself @ (0)

yincrash (854885) | about a year and a half ago | (#43352471)

by "slowly phase out," i mean each individual browser (for now just chrome & derivatives) will make the decision on their own time when to remove the webkit tag. probably when blink and webkit have diverged significantly.

Re:I wonder if blink will still identify itself @ (4, Interesting)

pspahn (1175617) | about a year and a half ago | (#43352697)

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.

Re:I wonder if blink will still identify itself @ (0)

Qzukk (229616) | about a year and a half ago | (#43352841)

By that measure, none of the browsers have diverged significantly from Mozilla.

Re:I wonder if blink will still identify itself @ (4, Funny)

yincrash (854885) | about a year and a half ago | (#43352895)

Blame [webaim.org] Microsoft and web developers.

Re:I wonder if blink will still identify itself @ (2)

alvarogmj (1679584) | about a year and a half ago | (#43353369)

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 [opera.com] .

Re:I wonder if blink will still identify itself @ (0)

Anonymous Coward | about a year and a half ago | (#43353447)

not even mozilla and internet explorer originally diverged from mosaic :) (I know, lots of work has been done since)

Re:I wonder if blink will still identify itself @ (4, Funny)

master5o1 (1068594) | about a year and a half ago | (#43353537)

If it is called the webkit tag, does this mean that we'll finally see the return of the blink tag?

Chrome user agent (4, Informative)

DragonWriter (970822) | about a year and a half ago | (#43352459)

I wonder if blink will still identify itself @ webkit for sites written that way

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".

Re:I wonder if blink will still identify itself @ (0)

Anonymous Coward | about a year and a half ago | (#43352477)

so, as Mozilla? ;)

Re:I wonder if blink will still identify itself @ (1)

petteyg359 (1847514) | about a year and a half ago | (#43352519)

Where is the location of this webkit at which it will identify itself?

Re:I wonder if blink will still identify itself @ (5, Funny)

gagol (583737) | about a year and a half ago | (#43352737)

I get the whole need to fork thing... but why name it after the most annoying non-standard tag from the 90's? <blink>Someone in marketing should be sacked.</blink>

Re:I wonder if blink will still identify itself @ (0)

Anonymous Coward | about a year and a half ago | (#43352947)

Advertising is being as annoying as possible.

Re:I wonder if blink will still identify itself @ (5, Funny)

Anonymous Coward | about a year and a half ago | (#43353037)

You forgot about the marquee tag. Protip: If you want to bring a browser to its knees, nest marquee tags.

Re:I wonder if blink will still identify itself @ (4, Interesting)

Em Adespoton (792954) | about a year and a half ago | (#43353167)

Maybe someone who missed blinks and marquees wanted to name it after the famous Dr. Who episode....

In other words... (3, Funny)

Anonymous Coward | about a year and a half ago | (#43352403)

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

Re:In other words... (4, Insightful)

beelsebob (529313) | about a year and a half ago | (#43352495)

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

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

Re:In other words... (0)

Anonymous Coward | about a year and a half ago | (#43352549)

How dare those bastards not contribute back to KHTML? I mean, why stop at one upstream?

Re:In other words... (1)

Anonymous Coward | about a year and a half ago | (#43352783)

KHTML is dead Jim.

Re:In other words... (1)

phantomfive (622387) | about a year and a half ago | (#43352555)

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

At least, that's what their post says.

Re:In other words... (2, Insightful)

Anonymous Coward | about a year and a half ago | (#43353467)

Or maybe "Working with Apple is hard."

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

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

Re:In other words... (2)

phantomfive (622387) | about a year and a half ago | (#43353667)

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

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

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

makomk (752139) | about a year and a half ago | (#43352567)

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.

Re:In other words... (3, Funny)

Nerdfest (867930) | about a year and a half ago | (#43353141)

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

Re:In other words... (2, Insightful)

theVarangian (1948970) | about a year and a half ago | (#43353491)

I'm not sure they can contribute their improvements terribly easily. Apple changed their development policies recently to be fairly hostile to non-Apple users of Webkit; basically, developers are allowed to check in changes that break the build on non-Apple platforms (which is enough to make development elsewhere a pain on its own because it breaks git bisect), and commits - including ones to non-Apple platform code, even ones that fix the build - now require the approval of an Apple employee with no knowlege of other platform and no incentive to approve changes important to them promptly.

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

It may be a balm to your soul to pretend that Apple is being especially evil here but they aren't the only ones doing this. I was recently given the task of compiling MySQL on AIX 7. It's doable but the code is riddled with stuff committed by people who don't care what else they are breaking as long as it works on Linux. Not that I'm complaining, AIX versions newer than 5.3 are not supported by the MySQL team due to "low demand" and I can easily sympathise with the MySQL team's reluctance to support it. It's impossible to maintain a complex software project and support Windows, the Unixes, a vast collection of fragmenting Linux distributions, Android, iOS, OS X.... (the list goes on). Sooner or later the communities surrounding these OS'es are going to have to step up and fix the broken code if they want the software to be supported on their OS. You can't expect Apple, Oracle, Google, et al... or non profit FOSS efforts for that matter, to support every single OS out there and all of their variants.

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

Anonymous Coward | about a year and a half ago | (#43353175)

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

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

Lussarn (105276) | about a year and a half ago | (#43352579)

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

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

beelsebob (529313) | about a year and a half ago | (#43352627)

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

I'm going to give them the benefit of a doubt... (5, Insightful)

Anonymous Coward | about a year and a half ago | (#43352705)

and see where this leads.

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

Re:In other words... (-1)

Anonymous Coward | about a year and a half ago | (#43352747)

First you were "more thinking" and now you state it as a fucking fact? Back up your fucking accusation or troll off somewhere else.

Re:In other words... (0)

Anonymous Coward | about a year and a half ago | (#43352957)

Ooh, two f-bombs in one sentence! You're so powerful and sexy... just gives me shivers. :*

Re:In other words... (-1)

Anonymous Coward | about a year and a half ago | (#43353471)

Stop being sexist. I'm a woman and find this offensive. I'm going to post this screenshot to twitter. I hope you get fired.

Re:In other words... (1)

viperidaenz (2515578) | about a year and a half ago | (#43352863)

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

Re:In other words... (2)

Grishnakh (216268) | about a year and a half ago | (#43353077)

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

Not very accurate. (5, Insightful)

tlambert (566799) | about a year and a half ago | (#43353543)

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

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

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

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

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

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

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

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

Re:In other words... (3, Informative)

UnknowingFool (672806) | about a year and a half ago | (#43353277)

Well the problem for Apple was the sheer amount of changes and lack of documentation they provided for their changes. The KHTML developers could not easily back port the changes; but these issues are not isolated to Apple's treatment of KHTML. Poor documentation affects some OSS projects.

Re:In other words... (3, Insightful)

DragonWriter (970822) | about a year and a half ago | (#43353301)

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

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

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

Re:In other words... (0)

Anonymous Coward | about a year and a half ago | (#43352603)

Blink is open source though, anyone could use it. How is this any different from Apple forkng WebKit from KHTML? Time to move on.

Hopefully Opera adopts this instead of WebKit.

Re:In other words... (0)

Anonymous Coward | about a year and a half ago | (#43352811)

And Apple's forking of KHTML effectively killed that project!

Re:In other words... (2, Informative)

Anonymous Coward | about a year and a half ago | (#43352939)

In favour of a better project. KHTML was pretty stagnant.

Re:In other words... (2)

DragonWriter (970822) | about a year and a half ago | (#43353329)

Hopefully Opera adopts this instead of WebKit.

They already have [thenextweb.com] .

Seriously? (0, Insightful)

Anonymous Coward | about a year and a half ago | (#43352723)

Who on Slashdot, besides the paid shills/editors, actually thinks of Google as a "model open source" citizen at this point?

Re:Seriously? (0)

Anonymous Coward | about a year and a half ago | (#43352927)

All those annoying radical and fanatical fAndroid tarts.

Re:Seriously? (5, Insightful)

Grishnakh (216268) | about a year and a half ago | (#43353097)

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.

Re:Seriously? (2)

dugancent (2616577) | about a year and a half ago | (#43353399)

Android needs to stand on it's own as a "model open source" project and not by being compared to the other options.

Re:In other words... (4, Insightful)

Art3x (973401) | about a year and a half ago | (#43353233)

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

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

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

Re:In other words... (0)

Anonymous Coward | about a year and a half ago | (#43352513)

"Let's create interpretations of people's words and try to attribute it to them!"

Hope they'll scrape off the remaining GPL parts. (-1)

Anonymous Coward | about a year and a half ago | (#43352405)

Hopefully this will lead to the last remaining snippets of GNU-shit being removed from WebKit...

--libman

Chromium Won't Be the Only Blinking Browser... (5, Informative)

PipianJ (574459) | about a year and a half ago | (#43352427)

Re:Chromium Won't Be the Only Blinking Browser... (0)

Anonymous Coward | about a year and a half ago | (#43352689)

New Opera will be a modified Chromium, so: duh.

Ugh...great (2, Insightful)

daveschroeder (516195) | about a year and a half ago | (#43352439)

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

Re:Ugh...great (-1, Troll)

Anonymous Coward | about a year and a half ago | (#43352539)

Oh shut up, this is nothing like MS and IE. Blink is open source.

Re:Ugh...great (0)

Anonymous Coward | about a year and a half ago | (#43352691)

How would that stop it being used as a differentiator to other browsers?

Re:Ugh...great (1)

DragonWriter (970822) | about a year and a half ago | (#43353347)

Blink is open source.

How would that stop it being used as a differentiator to other browsers?

Well, for one thing, because it is open source, other browsers (Opera, for instance) will be using its code base.

Re:Ugh...great (3, Insightful)

dhavleak (912889) | about a year and a half ago | (#43352751)

Being open source means that Blink and WebKit will behave 100% identically? Huh?

open source is not the answer to everything (0)

Anonymous Coward | about a year and a half ago | (#43352871)

Oh shut up, this is nothing like MS and IE. Blink is open source.

Yeah who cares if it has differences from webkit, it's all open source! If it doesn't work you just download the source code and a compiler, fix it to work like webkit, re-compile, root your device and deploy your new fixed version, sounds perfectly reasonable for everybody, hooray for open source!

Re:Ugh...great (0)

Anonymous Coward | about a year and a half ago | (#43352551)

Oh get wrecked, Apple do the same fucking thing on iOS.
They are just as bad as each other.

Re:Ugh...great (3, Insightful)

MetalliQaZ (539913) | about a year and a half ago | (#43352557)

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

Re:Ugh...great (3, Informative)

igrigorik (818839) | about a year and a half ago | (#43352575)

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

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

Re:Ugh...great (3, Insightful)

Frosty Piss (770223) | about a year and a half ago | (#43352673)

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

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

Re:Ugh...great (0)

Anonymous Coward | about a year and a half ago | (#43352687)

Wasn't it great when everyone was stuck with IE6, right guys?

Re:Ugh...great (1)

dhavleak (912889) | about a year and a half ago | (#43352769)

Excellent point. So much for people clamoring for MS to adopt WebKit.

Re:Ugh...great (1)

tlhIngan (30335) | about a year and a half ago | (#43352793)

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

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

Now, it depends on how hard Google wants to make Blink vs. WebKit. Like how Apple got scolded for releasing the source to WebKit for making it impossible to integrate with KHTML, then not releasing the logs of the changes, then for not releasing the history.

Of course, it would be interesting to see if Google does the same, or if they make changes that WebKit can easily re-integrate.

Re:Ugh...great (1)

Lussarn (105276) | about a year and a half ago | (#43353117)

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

Re:Ugh...great (1)

LordLucless (582312) | about a year and a half ago | (#43353127)

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

Re:Ugh...great (1)

Millennium (2451) | about a year and a half ago | (#43353403)

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

Re:Ugh...great (0)

Anonymous Coward | about a year and a half ago | (#43353521)

Yes, isn't that great? No longer will websites written for telephones break non-Webkit browsers on real computers, because even people like you will have to start coding to standards and checking for feature support, not user agent!

Don't Blink. (5, Funny)

Anonymous Coward | about a year and a half ago | (#43352443)

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

Re:Don't Blink. (1)

ArcadeMan (2766669) | about a year and a half ago | (#43352763)

Crap, I think they got me and I've gone back 2039 days.

To all web developers (5, Insightful)

Kingkaid (2751527) | about a year and a half ago | (#43352449)

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

Re:To all web developers (0)

Anonymous Coward | about a year and a half ago | (#43352681)

right because the shelf life on every application ever developed should be infinity.

Re:To all web developers (4, Insightful)

Kjella (173770) | about a year and a half ago | (#43352749)

Vendor Prefixes

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

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

The BLINK HTML Tag is everyone's favorite (0)

Anonymous Coward | about a year and a half ago | (#43352507)

Maybe that will be the browser's default unless NOBLINK is specified.

Dart (1)

Anonymous Coward | about a year and a half ago | (#43352515)

I'm sure Google will take this opportunity to add native bindings for Dart, which will make dart a whole lot more interesting now.

Re:Dart (0)

Anonymous Coward | about a year and a half ago | (#43353559)

And Firefox will add bindings for Rust, and IE will go back to VBScript, and there will be shims to crosscompile between them all. Exciting times ahead!

We bloated it... (0)

Anonymous Coward | about a year and a half ago | (#43352523)

We bloated WebKit to the extent it's not usable now, let's start from scratch!

Shoe's on the other foot now, Apple. (0)

Anonymous Coward | about a year and a half ago | (#43352527)

And its the one that will kick you to the curb vis-a-vis a fork that takes what you've built and moves it in a direction you can't build on without a massive effort.

Re:Shoe's on the other foot now, Apple. (2)

Anubis IV (1279820) | about a year and a half ago | (#43352859)

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.

Re:Shoe's on the other foot now, Apple. (1)

Nerdfest (867930) | about a year and a half ago | (#43353181)

Doesn't Apple control commits for WebKit? Having Apple in control of something is rarely good for anybody but Apple.

Re:Shoe's on the other foot now, Apple. (1)

Anubis IV (1279820) | about a year and a half ago | (#43353427)

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.

Will Blink let us blink text? (4, Funny)

joebok (457904) | about a year and a half ago | (#43352547)

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

Re:Will Blink let us blink text? (1)

Anonymous Coward | about a year and a half ago | (#43353033)

Don't Blink. Blink and you're dead.

Whatever you do... Don't blink. (1)

Anonymous Coward | about a year and a half ago | (#43352569)

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.

Huh.. (0)

Anonymous Coward | about a year and a half ago | (#43352591)

I knew I heard a collective gasp and crying off in the distance. Now I know what I was. Soon all those lazy jerks who design only for Webkit will have to do their jobs again.

about time to (0)

burne (686114) | about a year and a half ago | (#43352621)

EJECT EJECT EJECT

WebKit (TM) (5, Interesting)

Anonymous Coward | about a year and a half ago | (#43352649)

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

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

Well, as any Doctor Who fan can tell you... (0)

Anonymous Coward | about a year and a half ago | (#43352655)

Don't blink!

Surprised... (4, Insightful)

Anubis IV (1279820) | about a year and a half ago | (#43352665)

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

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

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

Re:Surprised... (4, Interesting)

Anubis IV (1279820) | about a year and a half ago | (#43352981)

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

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

Re:Surprised... (0)

Anonymous Coward | about a year and a half ago | (#43353465)

The real news in all this is that WebKit2 will make it much easier to develop a multi-process browser than Blink.
Unless Google is not telling us something, from a technological perspective, I think it would have made much more sense if Google dropped their own multiprocess code in favour of WebKit2.
But I think the fork (i.e. staying with WebKit and not moving to WebKit2) is commercially motivated. If somehow the two diverge in feature-set, then this will become harder and harder to fix, making it possible that e.g. some sites may work on Android but not on iOS.

IE did it first (4, Interesting)

rsierpe (2678773) | about a year and a half ago | (#43352791)

If I remember it right from ye olde days, it would be "embrace, extend, exterminate". They already embraced webkit, which is now some de facto standard, now they'll fork it, which implies some added functionality in the process, and you people know the rest. we are still trying to get off IE's dark era.

Smaller browsers(Rekonq,Epiphany,etc) (1)

duckgod (2664193) | about a year and a half ago | (#43352899)

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.

Re:Smaller browsers(Rekonq,Epiphany,etc) (2)

sl3xd (111641) | about a year and a half ago | (#43353505)

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.

And not a mention of Apple... (0)

pedantic bore (740196) | about a year and a half ago | (#43352987)

Couldn't they even say "thank you"?

Holy shit (2)

dingen (958134) | about a year and a half ago | (#43353005)

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

Re:Holy shit (1)

DragonWriter (970822) | about a year and a half ago | (#43353393)

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

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

Re:Holy shit (1, Informative)

swillden (191260) | about a year and a half ago | (#43353407)

Opera is moving to Blink also.

Am I the only one who initially read this as: (1)

aussersterne (212916) | about a year and a half ago | (#43353143)

"Bikini Google is Forking WebKit" and had to do a double-take?

V8 (2)

Azure Flash (2440904) | about a year and a half ago | (#43353453)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?