Free: Pack Of MySpace Branded Playing Cards »
A Fresh Look At Google Gears
by Mark Hendrickson on October 4, 2008

There’s a common misconception that Google’s “next-gen” web platform called Gears only (or even primarily) enables offline capabilities for web applications. The truth of the matter is that Google’s ambitions are far greater, and the browser extension’s capabilities are more multifarious, than this reputation suggests. MySpace’s implementation of Gears, which has little to do with offline functionality, is a perfect example.

Gears has been available for over a year now, with the first version released not too far back in May 2007. You can see the whole version history here, but essentially Gears has undergone four releases, each adding incrementally to its capabilities. The last was released this past August, with another released a couple months earlier in June.

The overall goal of Gears is to bestow upon web applications much of the same functionality enjoyed by desktop apps. And it’s doing so through a browser extension that can be installed for a range of browsers (Firefox, Safari, and Internet Explorer) on a range of operating systems (Windows, Windows Mobile, Mac OS, and Linux). With the release of Google’s own Chrome browser, some users don’t even have to install Gears; it just comes pre-loaded, making Chrome a super browser of sorts from the get-go.

The long-term consequence of this technology is clear: as browsers become more and more powerful with the assistance of initiatives like Gears, there become fewer and fewer reasons to install and run desktop applications (and therefore splurge on Windows and Office, to name two Microsoft cash cows oft identified as dying breeds).

But before that can happen, Gears and similar technologies need to truly enable desktop-like functionality within the browser (or more accurately, they need to enable desktop-like functionality for web applications that traditionally operate only within the browser).

So where do we stand today? Currently Gears can be used by developers to improve web applications in the following ways (on both desktop and mobile devices):

  • Client-side database storage – Most interactive websites depend heavily on databases that collect, organize and deliver the information contributed by users and in-house publishers. Traditionally, these databases have been deployed almost exclusively on the server-side, requiring users’ computers to send requests and wait for responses whenever they wanted to do something non-trivial with a site’s data. With the Gears Database API, websites can now establish databases on the client-side (i.e. your computer), allowing for quicker program speeds and certain offline capabilities (for when you can’t get online to query remote databases).
  • Client-side webpage serving – Gears can essentially turn your computer into a server of webpages and other flat data files for when regular web servers can’t be reached. The LocalServer API lets websites cache their pages when you are online and serve them up later when you’re not. It can also be used to speed up certain actions through caching for when you are still online.
  • Desktop shortcuts – For web apps to act like desktop apps, they need to open like them, too. So Gears makes it easier for developers to place shortcut icons on the desktop that users can use to open web apps with the standard double click. While basic site shortcuts for the desktop were possible before, the Gears functionality makes the user experience of adding and using these icons more intuitive. The graphic quality is higher, multiple sizes are supported, and in the future shortcut icons will support communicative overlay icons (for apps, such as webmail, that want to tell you how many unread messages you have, for example).
  • Multiple file uploads – Normally, when you want to upload a collection of files to a website, you have to select them one by one (unless the website you’re using has decided to implement a Flash or Java-based loader). With Gears, it’s possible for users to select multiple files at a time and batch upload them, saving you time and tediousness.
  • Geolocation – For mobile devices that can determine the user’s current location, Gears makes this geolocation information available to applications running within the browser. The geolocation API can be used to identify the user’s position once or to watch it over time as the user moves around. Permission to access a user’s position must be granted through a special dialog, preventing unwanted snooping.
  • Background processes – A lot of times when using JavaScript-heavy web apps, you have to wait while certain processes finish chugging along. With the so-called “WorkerPool” API, time-intensive processes can run in the background where they won’t slow down your general experience. The result: web apps feel more snappy because they don’t get bogged down as often.

The Gears team at Google rolls out capabilities based on the perceived demand for them. The following features have been alluded and may show up in upcoming releases:

  • Progress bars – Whether you’re uploading one large file or several small ones, you probably want to know how things are going. Traditionally there’s no way to tell where you stand as you look impatiently at the spin of your cursor’s hour glass. But with Gears, you’ll be able to see a real progress bar telling you how much of the data has reached the server already.
  • File resumption – When large file uploads fail these days due to connection interruptions, you have to start from square one and reupload everything again. Gears promises the ability to resume uploads so you can start where you left off.
  • On-screen notifications – Users of Growl and microblogging desktop clients like Twhirl are accustomed to on-screen notifications that appear in the corner of their screens when anything new happens. Future versions of Gears will allow any website to trigger such notifications, whether or not they are currently running in the browser (perhaps allowing us to kill off the email notifications that many web apps abuse to spur return visits).

In the long run, we might see support for complex 3D graphics that take full advantage of your computer’s graphics card. Upload functionality could get integrated into the menus that pop up when you right click on files. And web apps could get loaded at startup or triggered in any number of other ways throughout your computer’s operating system (and its native desktop applications).

If you have extra time this weekend, the following presentation by Google’s Chris Prince, given at this past May’s Google I/O developer conference, is an informative visual and oral walk through of Gears:

Nik Cubrilovic’s next generation web posts are also helpful for understanding the platform war that has emerged (Google is not the only major tech company making strides to enhance the capabilities of web apps).

Advertisement

Responses

Comments rss icon

  • “3D graphics” – this is the area I’m finding hard to see how it will pan out in the future. Which “standard” will Google have to pick to provide a more advanced rich/fluid UI for web based apps. Obviously, Silverlight and Flash have these features (well, less 3D stuff with Silverlight, but certainly graphics features). Could Google’s choices for a plugin API show the direction they are going with UI technologies?

  • Your list of important features misses the macro functions that every real OS has (VBscript on Windows, Bash shell on *NIX system, Automator(?) on the MAC,…). The only thing that comes close to this feature in the browser is currently the iMacros Firefox add-on:
    https://addons....efox/addon/3863
    Macro features (in general) are important for every power user, whether it is on the desktop or in the browser.

  • multifarious… good one.

  • See http://www.wibokr.com/ , an web2.0 wiki and blog which support offline by google gears.

  • Great post Mark, happy to see it on TechCrunch and not TechCrunchIT (whatever happened to that btw? seems just SG’s incomprehensible posts these days) .

    Gotta disagree on the Gears motive though, seems primarily aimed at offline web apps to me. The biggies are Client-side database storage and Client-side webpage serving, the other features are nice but we could live without them.

  • “…(perhaps allowing us to kill off the email notifications that many web apps abuse to spur return visits)”

    Why on earth would you want to replace unobtrusive email which one can get to whenever one wants, with annoying notifications that interrupt what you are doing with no control over it – do I really need to know right this instant that Friendster wants me to come back? Gears notifications are good but definitely not for this reason.

  • Why isnt there a comparison with Adobe Air and Mozilla Prism?

    • For that matter there is no comparison to any of the other technologies around, specifically Site-Specific-Browsers (http://en.wikip...pecific_Browser) such as Prism, Bubbles (http://bubbleshq.com/ Windows), Fluid (Mac http://fluidapp.com/).

      Bubbles and Fluid are marching towards moving web-apps into the Desktop.

      For all the ‘Browser vs. OS’ pundits, this is just playing with words. Its clear a very likely endgame for this generation is a very light Linux OS, with a very powerful browser. The only open question is how do we implement CPU/GPU intensive applications such as video-editing and games. Luckily enough that’s not what most of the market does, so something like a light OS + superchargde browser can win eventually. And by supercharged I don’t mean the browser we have today only with faster Javascript VMs, I’m talking about solving the security issues with offline/online, better data interchange, better formats, knocking off the boundaries of the rectangular browser window, and so forth.

      • Which, if any, have access to drivers for usb, bluetooth, wifi etc?

        Peripheral connections are key and I can’t find a browser extension or AIR capable of hardware connections

  • I remember seeing the suggestion in the Google group long back. finally, the the project has been undertaken.

  • Is this the app that’s gonna take cloud computing to the next level

  • Hey…Whats so special about gears, all of the points mentioned can already be covered in some way or the other with existing technologies, from the likes of Microsoft, Java & Adobe. btw the .Net framework on the desktop + IE already makes it a super browser. Don’t need gears to do that…atleast on Windows!

  • One of these days Gears (or Air for that matter) will be allowed into the iPhoneOSphere. That will be a great day for my little outfit.

  • This article has MS hater written all over it.

    Do yourself and all of us a favor and get your facts straight and post something non biased thats actually technically and financially correct. A browser replacing the OS? What about when your net connection dies or you happen to go somewhere where there’s no Internet? Thats just 2 basic cases (and theres thousands and thousands more).

    • Absolutely.
      You need an OS before you can use the browser, no matter how good the browser is and what it come loaded with.
      The all important internet connection is controlled by the OS and without that the browser is nothing.

      • Guys, I don’t think that the author is implying *no* OS and hence nothing to perform network control or other OS-level services. I think that the point is if apps can be delivered through a rich browser that is OS_independent, then OSs become more of a commodity product and you no longer pay big $ for M$FT. As for the situation where there is no internet – true, but coverage through broadband and wireless providers is making that less of an issue for many users.

      • I second Mr. Mike Claiborne. Great comment! You could replace some of those Techcrunch “bloggers”.

  • Well, the way I see it here would be that though Google Gears actually rolls out quite abit of accessibility for offline users – how about the most difficult part: Keeping information in sync both online and offline?

    Coming from a programmer background, I understand that databases are already *VERY* complicated when there are multiple copies – does Gears address this data portability/syncing issue yet?

    I belief the only reason why anyone would want to take an app (say, one of Google’s – Google Docs – offline would be to have *their* documents offline/offsite for a period of time) – what happens when there’s TOO much info to go around?

    - Kevan / Free-iPhone-3G-Apps.com

  • I am having a hard time to understand that trend to build applications running on top of a browser, running on top of an OS. The OS itself tend to be sluggish and clunky (well if you use one of the most popular), the browser is just some kind of huge pile of crap with tons of feature for which it has not been constructed at the basis (Chrome could help a lot but it is still an ugly patch on a wooden leg).

    Some 30+ years ago, a small little thing named Unix has been designed to enable distributed applications over a network (LAN network at that time, but only because the internet was just a distant dream) . An a standard (Xwindows – poorly implemented but incredibly powerful concept) existed to export graphical applications on distant machines.

    Why in hell is the IT industry inventing the wheel again, 30 years later….

    Why is portability now the responsibility of a browser, instead of a clean OS with defined standard APIs (ever heard of Posix?)

    Pierre

    • Well said, and very entertaining.

    • I agree this should be the OS (and not the browser), but that’s the way the cookie has crumbled. XWindows was cool! But regardless, I still think this type of stuff is a step forward, albeit awkward.

    • I dont think unix was designed to “enable distributed applications over a network”. Networking, Xwindows were added after unix was designed and they didnt follow the unix philosophy. Check out for plan9, it was designed from scratch keeping distributed applications in mind and it’s apis are lot more simpler than posix.

    • You pretend like there’s a difference between a browser and an OS. Both are a software API that allow applications to be written on top of them, combined with a navigation interface to locate and manage these applications. The argument is mostly on what the level of abstraction of that API should be, and how its network integration should work. It’s quite feasible to layer a browser directly on top of a kernel, bypassing the need for an OS entirely.

      The strength of the browser model, which is definitely unlike its predecessors, is that applications run simultaneously on client and server, and are launched from the server (bypassing the need for a local installation). This means that you can place any part of the system where it belongs most, on the client or the server, and this also means that ubiquitous availability of the application is guaranteed, because there’s no installation required, at all.

      What gears is doing is allowing you to push functionality deeper into the client, making a comparable catch-up move as what happened on the server over the last decade. The end goal, as stated on the gears site, is to remove all reasons why developers might choose to build desktop apps instead of web apps. Since google lives on the web, having all new software run on the web would be a huge benefit to them, so it’s easy to see the motivation there.

    • Actually, browsers accessing remote apps (read SaaS) is more like the mainframe model, where brower = dumb terminal (albeit not really that dumb) and SaaS = mainframe app. Mainframes had a ton of advantages, most obvious of which is that you just manage one machine rather than a rash of individual workstations. But the mainframe/terminal setup was over a local network where latency wasn’t an issue.

      We couldn’t replicate that model over the Internet because network latency sucked so far. Now that broadband is pretty common place, the old mainframe a model becomes viable again – with SaaS enjoying similar business benefits of centralized maintenance as that of mainframe apps.

      A browser is the equivalent of a dumb terminal in the new scenario, with added intelligence of course. Clouds/BitTorrent kind of setups ease the network latencies, but still we don’t have local network speeds over the Internet – so, we need stuff like caching and local storage. Hence, technologies like Google Gears come into the picture. Enough said. :)

  • Pierre: I don’t think any of the people at TechCrunch have heard of Posix. Most of the people pushing this browser as OS crap wouldn’t know how to use the MS-DOS command line.

  • i’m still not understand how google gear works just that.

  • Seems like a good place to shamelessly promote http://jnext.org . Open source, cross browser, cross platform, small footprint.

  • gears is really just closing the gap between desktop and browser, it will never fully replace the desktop OS and indeed many applications such as audio/video editing and best suited to run natively due to amount of data being processed and stored…gears makes sense for some apps, particularly information intensive apps, Google Docs and remember the milk are both great implementations of what gears can do

  • I tend not to rely on plugins for browsers when standards like localStorage (and globalStorage, though not standard) and WhatWG’s storage interface for them. These are built into beta browser builds and globalStorage has been in Firefox since 2.0.

  • Mike, Where’s that TechCrunch tablet so I can use gears?

  • Great thing that google making this year one 10^100, now google gear and i’m still think how this will work offline :(

  • I like Google Gears. I’ve tested a few things with it’s functionality, especially a plugin for Wikipedia that caches articles, makes things easier.

    Google certainly has brought out alot of innovative products!

  • Do they support iphone(mobile safari) ? given apple recently added a feature in mobile safari to run web apps in full screen, now if gears is supported on mobile safari, it might be good alternative to create certain kind of apps than using objective-c and going through apple review process to get into app store.

  • I am now using it, I like it.

  • All what Google did with Google Gears is to implement some of HTML5 specifications before the browser vendors did. At the moment, browsers such as Mozilla Firefox (3+) have implemented the same specifications, but due to the way Google did the implementations, there is no consistence between Google and the others, and this require us to install Google Gears even while we have the same functionality already built inside our browsers.

    Please use the browser functionality instead of Google plugins, so we won’t stuck with more must-have proprietary browser plugins such as Adobe Flash, and media players plugins.

  • I think the multiple file upload is a very nice feature for all social networking and blogs. Basically, everyone can create their versions of youtube/flickr uploader. It’s very convenient for the users.

  • Yes, I did notice this earlier and Gears helped me a lot. T

  • BrowserSpy has been updated so that I now also are able to detect Gears.
    It’s online at http://browserspy.dk/gears.php

  • Rummble launched with Gears as a Google partner. The first release only works on Windows Mobile http://blog.rummble.com/?p=113 but future releases will soon come forth to support other mobile platforms, which we’ll also be supporting.

    The Rummble platform also supports the new GeoLocation API for web browsers- which is very cool – one click and it can tell where you are often far more accurately than some of the open source IP sniffing tools.

  • it surprises me that Google hasn’t developed a Gears extension for Firefox.

  • I hadn’t hear about Gears until I found this blog today. I am going to watch some videos on Youtube, so I get a better idea about it.

Leave Comment

Commenting Options

Enter your personal information to the left, or sign in with your Facebook account by clicking the button below.

Alternatively, you can create an avatar that will appear whenever you leave a comment on a Gravatar-enabled blog.

Trackback URL
bugbugbug