Hasta La Gadget!

Word that Google had decided to fork WebKit and build its own rendering engine is still echoing through the spidery halls of the internet. The true ramifications aren’t entirely clear yet, but Opera has pledged to embrace Blink and WebKit is already talking about removing Chrome-specific code from its repositories. This doesn’t necessarily indicate a seismic shift in the industry, but it certainly suggests that we won’t be looking at a world so thoroughly dominated by the direct descendant of KHTML. At least at first, the new entrant won’t actually deviate much from WebKit. Primarily the focus will be on stripping away unnecessary code and files to streamline the rendering engine specifically for Chrome. Obviously, this won’t prevent other developers from using Blink, since the project is open source. But Google has been pretty up front about the rationale behind the fork — the multi-process architecture favored by Chromium-based projects is quite different than that used in other WebKit browsers. This has, to put it in the plainest terms possible, kinda gummed up the works.

Blink is about 10 weeks away from landing in the stable version of Chrome (it’s expected to be turned on by default in version 28), but it’s already available as part of the Canary build. We downloaded the experimental browser and spent some time with it in an effort to identify what, if anything, was different. Keep reading after the break to find out just what Google has bought by shedding some of WebKit’s baggage.

Filed under: Internet, Software, Google

Comments

Chrome 27 Beta browser has been released by Google, bringing with it some goodies for developers, as well as faster page loading to the tune of about 5-percent. Users who don’t mind dippingo into beta territory can grab the latest download now from the Chrome beta page. We’ve got a run down of the new features and improvements after the jump.

The obvious feature most users will notice is the speed improvements, which are said to increase the rate of content loading by 5-percent. This is due to behind the scenes changes to the browser’s resource scheduler, decreasing pre-loaded resources and using an idle connection more often. In addition, webpagetest.org Speed Index values are now included in the metrics used to assess page load speed improvements.

Other changes and additions are specific to developers, and include HTML5 date and time forms, which are featured in the image above. There’s also now live audio input to Web Audio API for the Windows and Mac versions of Chrome, as well as Sync FileSystem API for Chrome Packaged Apps. Improvements have been rolled out for the network panel, bringing customizable columns and the ability to “Copy as cURL” a resource by right-clicking on it.

There are a variety of other features for devs, which those who are interested can check out in full here. In case you didn’t hear, Google announced yesterday that it will be forking a new rendering engine called Blink from WebKit, promising to bring with it speed and to eventually spur innovation. You can read more about those plans, as well as what one Chrome dev has to say, here.

[via Chromium]

Chrome 27 Beta now available, promises faster speeds is written by Brittany Hillen & originally posted on SlashGear.
© 2005 – 2012, SlashGear. All right reserved.

Google’s decision to branch off from WebKit and develop its own Blink browser rendering engine is a matter of speed not fragmentation and control, one Chrome team developer has argued, pointing out that what’s currently the de-facto standard has already become a weight around devs’ necks. “To make a better platform faster, you must be able to iterate faster” Google London’s Alex Russell argues, likening the sluggishness of adding and tweaking WebKit features to the inefficiency of using an old computer when newer, faster ones are available. As a bonus, he points out, developers will be less likely to inadvertently break something when modifying the Blink engine, a situation Russell says can often occur when dealing with WebKit.

“Blink gives developers much more assurance that when they change something, it’s only affecting the things they think it’s affecting” he explains, thanks to the engine’s Content API boundary. That’s the part of Blink which – though for the large part following the WebKit API design – differs in that it isolates Chrome developers “from inner workings of content.”

For Russell, though – and presumably Google as a whole, given its web/cloud-centric focus – the speed potential for jumping ship to Blink is what really makes the fragmentation worthwhile. The Chromium team has enjoyed such streamlining in Google’s own “Chromey” parts, he points out, and now will get the same in the underlying engine. That, the reasoning goes, means a browser that is improved faster and keeps better pace with the demands of users and developers.

“Directness of action matters, and when you’re swimming through build files for dozens of platforms you don’t work on, that’s a step away from directness. When you’re working to fix or prevent regressions you can’t test against, that’s a step away. When compiles and checkouts take too long, that’s a step away. When landing a patch in both WebKit and Chromium stretches into a multi-day dance of flags, stub implementations, and dep-rolls, that’s many steps away. And each step hurts by a more-than-constant factor” Alex Russell, Chrome team, Google

The losses from adopting Blink are the obvious ones, Russell says: divorcing development from “a community of hugely talented people” working on WebKit, for instance. Some old faces are likely to be present, however; Opera has confirmed, TNW reports, that it too will be using Blink having already committed to switching to Chromium back in February.

“When we announced the move away from Presto, we announced that we are going with the Chromium package, and the forking and name change have little practical influence on the Opera browsers” Opera spokesperson

Who will follow next remains to be seen, though given Google’s footprint in smartphones and tablets with Android, not to mention its push to move users onto the web in Chrome OS, developers certainly won’t be able to avoid Blink moving forward.

Speed matters argues Chrome dev as Google under fragmentation fire is written by Chris Davies & originally posted on SlashGear.
© 2005 – 2012, SlashGear. All right reserved.

WebKit makes the web go ’round, and yet it is soon to be joined by a new kid on the block: Blink, which was announced on Chromium’s blog earlier today. Says Chromium, the decision to create a new rendering engine “was not an easy” one, but ultimately good will come from it. Developers don’t need to worry, as the announcement reassures that little will change for them during the initial rounds of work.

As pointed out by Chromium software engineer Adam Barth, Chromium utilizes a multi-process architecture that differs from that of other WebKit browsers, with the multi-architecture support leading to a slurry of ever-increasing complexity that serves as a sort of ball-and-chain on the ankle of innovation. Blink, which will be open source, aims to solve this issue and provide, by proxy, a boost in innovation.

Aside from that, optimistic attitudes tout the upcoming rendering engine as a possible boost to the “open web ecosystem” as a whole, although it is acknowledged that introducing a new rendering system has the potential to significantly impact the Internet, and developers could eventually have more work on the coding end of things.

According to Barth, the initial work will concentrate on getting rid of digital clutter, including the removal of about 7,000 files and 7 build systems, which will total in excess of 4.5 million lines of code. This will result in vast internal architectural improvements, but won’t bring much change to web developers. Guidelines have already been posted regarding interoperability, standards, and other such related items.

[via Chromium]

Chromium announces new open source rendering engine project Blink is written by Brittany Hillen & originally posted on SlashGear.
© 2005 – 2012, SlashGear. All right reserved.

You could call WebKit the glue that binds the modern web: the rendering engine powers Apple’s Safari, Google’s Chrome, and many mobile browsers past and present. Things are about to unstick a little. Google believes that Chromium’s multi-process approach has added too much complexity for both the browser and WebKit itself, so it’s creating a separate, simpler fork named Blink. Although the new engine will be much the same as WebKit at the start, it’s expected to differ over time as Google strips out unnecessary code and tweaks the underlying platform. We’d also expect it to spread, as the company has confirmed to us that both Chrome and Chrome OS will be using Blink in the future. We’re safely distant from the Bad Old Days of wildly incompatible web engines, but the shift may prove a mixed blessing — it could lead to more advancements on the web, but it also gives developers that much more code to support.

Update: The Next Web has confirmed that Opera, which recently ditched its Presto engine for Webkit, will indeed be using Blink as it’s already hitching its proverbial wagon to Chromium.

Filed under: Internet, Software, Google

Comments

Source: Chromium Blog