Skip navigation
Help

Browsers

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.

Google has released Chrome 14 to the Chrome beta testing channel, which includes, among other new features, the initial beta release of Google’s "Native Client" technology, first announced in 2010.

If you’d like to try out Chrome 14 beta, head on over to the beta downloads page.

Chrome 14 has several improvements including the much better OS X Lion integration we mentioned previously, along with print preview support for Mac OS X users. But possibly the biggest news is that Google’s Native Client technology is getting closer to prime time.

Native Client is a set of open source tools that allow Chrome to run compiled C and C++ code the same way the browser currently runs JavaScript or other common web programming languages. Native Code offers both a security sandbox and a set of interfaces that provide C and C++ bindings to the capabilities of HTML5. That means web application developers will be able to tap into desktop libraries to create faster, more powerful web apps.

For example, imagine you wanted to create a video editing web app along the lines of Final Cut Pro. You could building the user interface with HTML, CSS and JavaScript, but the actual processing of video would likely be very slow if you handed off the job to the server. You could try to use JavaScript in the browser, but again speed would be an issue. Native Client would allow you to do the video processing in the browser, but running native code. Then all you need to do is push the final changes up to the server, which makes for a much snappier web app.

How much faster Native Client will be is open to debate. Certainly JavaScript performance has improved since Google first announced Native Client in June 2010. The past year has seen huge JavaScript speed improvements in nearly all the major web browsers, which means Native Client feels less necessary than it might have when Google first began working on it. Of course there are still plenty of web apps, especially computationally intensive apps like non linear video editors, that could benefit from Native Client.

The problem for web app developers is that thus far Native Client is only available in Chrome. Google has created an API, dubbed Pepper (Native Client is abbreviated NaCl, which is also shorthand for table salt, get it?) which allows the browser to talk to Native Client and means that any web browser could, in theory, implement it. Thus far, however, none have.

For now, if you want to test out some Google’s sample code, grab the latest Chrome beta and head on over to the Native Client demo page. In my testing Native Client was indeed quite speedy, but running it for any length of time sent my laptop’s fan into overdrive.

Conway's Game of Life Running in Native Client

While Native Client is still a beta release, if it catches on with developers and other browsers embraced it, Native Client could open the doors for a whole new generation of faster, more powerful web apps.

See Also:

0
Your rating: None

Google has announced a new set of APIs for its Chrome web browser, which are designed to connect applications and sites across the web. Web Intents, as Google is calling its new meta-website API, allows websites to pass data between each other — for example, to edit a photograph or share a URL with friends.

Developers at Mozilla have been working on a similar framework for Firefox, and now Google says it will work with Mozilla to develop a single API that works in both web browsers.

The Web Intents API was originally conceived by Paul Kinlan last year. Kinlan, who is a Chrome Developer Advocate at Google, borrowed the idea from the Android platform, which uses Android Intents to pass data between Android Apps.

So just what are Web Intents? Well, the easiest way to understand them is by example. Take the sometimes overwhelming proliferation of buttons on web pages that allow you to do something with the current page, whether it’s Like, Tweet, +1, Read Later, Add to Instapaper and so on. Rather than adding a dozen little badges to your site, Web Intents creates a bridge that connects your site to any website your visitor wants to use. Web Intents define an API for your site to use and another API for the receiving site to use. Plug them together and transferring data becomes a quick and easy process, both for users and developers.

That’s a huge step up from the situation today. Perhaps the biggest win is that Web Intents put your visitors in control — they can select which actions they’d like to perform and which external sites they’d like to handle those actions. Some might share your page on Facebook, others on Twitter, still others might save it to their Instapaper account and so on, all from the same three lines of code you added to your site.

That’s not, however, all that Web Intents can do. The broader goal of Web Intents is to provide a generic means of communication between websites for tasks as varied as editing photos, listening to music or shortening URLs.

The second half of the video below demonstrates Mozilla’s take on how Web Intents ("Web Activities" in Mozilla’s parlance) might work.

For some sample code and working examples, head over to the new WebIntents.org site and check out the examples (the image example is particularly good at showing off the potential power of Web Intents).

For some more background on Web Intents, check out Paul Kinlan’s blog, particularly his overview post on the brief history of Web Intents. Tantek Çelik, the creator of microformats, also has a nice post on what he calls Web Actions (same thing, better name). Çelik breaks down the idea behind Web Intents and how they benefit not just developers, but users as well.

As Çelik writes, "web actions have the potential to change our very notions of what a web application is from a single site to loosely coupled interactions across multiple, distributed sites…. In that regard, web actions have the potential to become a building block for distributed web applications."

Image: Aidan Jones/CC/Flickr

See Also:

0
Your rating: None

Bass Schouten is a cool name, and the Mozillan has presented Direct2D hardware acceleration.

You have to grab Firefox nightly, do the about:config / gfx.font_rendering.directwrite.enabled game, but then you get to see it in action.

IE9 showed off how they will support hardware rendering, and I am sure we will see more at MIX, but it is very cool to see this across the board.

CSS Transforms/Transitions/Animations are going to feel like butter in 2010!

0
Your rating: None