Google launched Gears last May, and for the first year of its release it was considered a minor, niche product that a few developers and users may take advantage of to allow offline access to web applications. You can probably recall the arguments at the time: who needs offline access, connectivity is everywhere anyway, not enough apps will support this etc. It wasn’t until a year later and only a few weeks ago, that Google revealed its ace card: Gears-powered messaging for MySpace that is super-accelerated. Google had entered the race to provide the new web API, and for a year almost nobody had noticed.
The browser of the future is likely to become the virtual machine that hosts almost all applications. In this scenario the operating system becomes transparent, so Microsoft has something to protect (the source of its profits), as does Adobe, who currently provides the most common and consistent web virtual machine with Flash. Google has made no secret of its plans to target and harm Microsoft, and they know that the best way to go about that is to make the operating system irrelevant by moving up a layer and turning the browser into a standard, but powerful, virtual machine for applications.
It is hard to convey in a review how Gears can change and accelerate the functions of a web application. With browser-based Javascript, functions in MySpace such as listing and sorting emails or filtering through a list of friends felt very slow; the loading bar would freeze as the hourglass spins while your browser makes multiple requests back to the server. With a quick install of gears, a click on a confirmation box and a couple of seconds of loading time, the same functions that would previously almost drive a user insane now feel like they are part of the browser itself. What Google showed us Gears could do with the MySpace integration woke almost everybody up to the true intention of the product: this was no longer about offline browsing, but a shot aimed directly at Adobe and Microsoft.
At last count, Google had a suite of 28 different web-based applications, all being used by millions of people all over the world. The technology they use to implement their web applications has always been standards-based HTML, CSS and Javascript. The choice of Ajax may be because it is simply the best solution, but it may have more to do with the fact that almost every alternate web development technology stack is produced and controlled by a direct competitor. Google strongly backed the development of the open source Firefox web browser and supported open web standards as their technology stack of choice. They did this because their web applications depended on it, and a weak Firefox could possibly result in a revived Internet Explorer that would hand over control of the web back to Microsoft.
Previously, using only browser-based Javascript to power web applications wasn’t a problem for Google. That was, until their competitors took a step forward and released their respective second generation web platforms in the form of Flex/AIR and Silverlight. Microsoft and Adobe had taken a big step forward in terms of what could be done with web based applications, with desktop-like interfaces and functionality. It wasn’t going to be too long before competitors big and small would be using competing technology platforms to build competing applications that would make the Google app suite look like it was stuck in the 90’s.
The choice for Google was clear: either give up on browser-based Javascript and standards development and take up one of the new technologies, or stick with it and progress the core web technologies forward to the point where they are a viable alternative. The problem for Google was that while there were new standards and planned browser features that would soon introduce rich web technologies, the progress in developing these standards was so slow that it would be years before they would see wide-spread adoption. The new HTML standard, HTML5, was specifically aimed at extending the capabilities of web applications within native browsers, without the need for an added proprietary runtime. Those same functions and other additions would form the basis for the new Google web API.
With slow standards development blocking the path to better and faster, yet still free and open web application development, Google decided to take on that market itself through Google Gears. The idea was simple: bring forward the features of tomorrow’s web technologies into today’s browsers. The specific features mostly came from the new HTML5 specifications that standards bodies had been spending years working on. Instead of waiting for them to hit production, Google simply implemented them as best they could by extending the browser through a plugin. They would sacrifice standards in the short-term (and essentially ‘figure it out later’) in order to bring their web applications up to a rich next-generation standard from where they could stand up to Flash and Silverlight.
Gears would be developed by a group of 30 or so developers as part of the open source group in Google. In an ironic twist, the group is led by Vic Gundotra, who prior to Google led developer evangelism at Microsoft. The small group of developers set out to mark out and preserve Google’s interests in Javascript and an open browser virtual machine. On paper they would seem out-gunned by the larger groups and budgets that Microsoft and Adobe were pouring into their respective platforms. To help boost their case, they have detached Gears from Google (literally also – the project is now called just ‘Gears’) and released the code under an open source license.
The first release would focus on a few features proposed in HTML5 that were considered most important: client-based structured and object storage. Because of the choice to implement client-storage first, Gears would be framed as an offline application solution for the next year, which if not intentional, certainly served them well as competitors likely didn’t notice the broader goal. Google could have developed and released their own browser, there was speculation and rumors in blogs stating exactly that, but the browser market was competitive, tedious and generally a pain. Besides, even after having developed a new browser they would have to wait for critical market mass while they drove users to adopting it, and there would still be the other 70, 80 or 90 percent of the market not using their browser who might still want to use Google apps.
The shortcut was to skip past the browsers and add a new layer above them – the Google web layer. All the popular browsers provide mechanisms by which developers can extend their functionality, so all Google had to do was to developer a plugin for each browser. It could have its new web API on potentially 100% of desktops without asking users to switch and most importantly, in a manner much faster and less painful than entering the browser market. Browsers would now do all the boring bits: rendering HTML, presenting an interface, user options etc. while Google leveraged what was there and dashed ahead.
Today Gears supports a whole host of new features, some that it has in common with the other next generation web API efforts from Microsoft and Adobe while others are a result of their own innovation. Function calls available to developers include background processes (no more hourglass), client-side image manipulation, location-awareness, better file uploading and a local database inside the browser.
There are two sides to the adoption of a new API and development platform: one side is user support, and in this case it requires a plug-in to be installed; the other side is developer support, and with Gears it couldn’t be easier as the applications are the same as any other in using browser-based Javascript, it just provides developers with a whole lot more they can do in the browser. Javascript and web developers have nothing new to learn and users are only a plug-in away (with the inevitable upcoming bundling deals, not even that). It took Flash 5 or 6 years to become common enough for developers to target it with confidence, with Google backing it, Gears could take less than half that time.
In this race Google has nothing to lose but a lot to gain, and in a single shot has kick-started the standards-based and open-source alternate new web API. Unlike their competitors they don’t have an interest in controlling the platform nor directly profiting from it. They are instead seeking to maintain the current status quo: Javascript in the browser for most applications and Flash or another alternate when you need just a little bit more.
It has been a long time since the last platform war, but each time that technology experiences one you can see the biggest companies fall and the smallest companies prosper. Add open source to the equation and the result may still be that no single company dominates. With so much at stake and such large companies involved, we are surely about to witness a long and protracted battle. Only time will tell if the Google approach to taking the web forward will work.
This post is part of a series written by Nik Cubrilovic on the Next-Gen Web, read other posts here.
Comment