How will this impact Web Development?

This largely depends on what kind of web development you do. In most cases you and your enterprise won’t be affected in the slightest. Chrome has a very fast and robust rendering and JavaScript engine, and much like any newly released browser (remember Firefox 1.0?) loads up in no time flat. The rule of thumb is that if you’re already supporting Safari, you can safely assume you’re supporting Chrome.

Why is this? What you may not know is that the underlying  engine that Safari runs on is a package called WebKit, which is the same engine which powers Google Chrome. There are some revision based incompatibilities (Since Safari’s already a few versions ahead), but practically speaking they’re identical. The downside of this is that if your agency is one of the rare islands left that only support the “Two Major Browsers” (Firefox and Internet Explorer), you no longer have an excuse to not support them.

If you’re doing Rich Internet Application development, you’ve just been presented with a very interesting way of taking your application to the desktop. You might not have heard of Google Gears before now, or might not have considered it to be a viable option. Gears is a browser extension framework that allows desktop-application like interaction between your RIA and the client’s computer. Sounds neat, right? It is, and it’s directly integrated into Chrome and is available as a plugin for both IE and Firefox. Unfortunately, the major restriction of Gears up to this point was that you were still restricted to the browser’s UI, but as I point out later in this article this is no longer entirely the case.

What about Mobile?

If you’re doing Mobile Web Development, you may be able to target WebKit directly from this point forward. See, Safari is the exclusive browser on the iPhone, and with the upcoming release of the T-Mobile HTC Dream, you can bet that Chrome will be the default browser for Android. What this means is that WebKit will become the de-facto web development standard for mobile devices. While mobile UI patterns and application frameworks will shake themselves out over the next few years, the writing’s on the wall: If you want to take RIA’s to mobile devices without bothering with a native application, WebKit is the platform to build for.

So What’s The Big Deal™?

At this point you’re probably asking yourself: "What’s the big deal"? If Chrome behaves much like the other major browsers out there, why is there so much buzz about it? Is this just Google Hype?

Without going into a lot of gritty detail  about it (The Comic Book published by Google does that really well), the major big deal is that Chrome is not just a Browser: Chrome is an Application Platform.

Much like AIR, Chrome attempts to blur the lines between the desktop and the web by creating a wrapper for previously developed content. They even do it in very similar ways: AIR allows the execution of JavaScript RIA’s in an integrated WebKit Browser running within the ActionScript Virtual Machine, while Chrome allows the execution of Flash RIA’s running in the Flash Player. The difference is simply the technology stack used- Chrome is based around JavaScript and HTML, while AIR is based on ActionScript and MXML.

The Google Engineers are quite explicit about this. The Comic Book talks about it, and one of the primary features is "Create Application Shortcut". While functionally this really just creates a direct link to a specific website, the integration of Google Gears allows some websites to move almost entirely to your desktop. It even goes so far as to use the favicon for your application icon, giving you a Desktop Application experience for any website you choose (try it with Google Calendar or Gmail).

So what’s the Big Deal? It’s a concept change, a different way of looking at the Web. It’s not particularly new- Microsoft tried to do this with the close Windows/Internet Explorer integration in the late 90′s and .chm/.hta applications, but it is the first time that the browser’s been turned into a (soon to be) platform agnostic application wrapper.

A Future Vision

Not to be a crazy futurist or anything, but consider the following possibility: Both Google and Adobe have now firmly cast their lot in with an ECMAScript/DOM-like technology stack, and we already know that there is a close relationship between the two companies both from YouTube and from the indexable headless player. Personally, I think it’d be pretty interesting if the future held a technological convergence of all ECMAScript languages. Compiling HTML to a desktop application? Converging JavaScript and ActionScript into a single ECMAScript language? It’s all possible.

So lets talk about the consumer for a bit, in particular the consumer described in The Long Tail. Here is an individual who knows his/her own lifestyle and needs, who like particular applications over others, whose preferred experience with one service might be different from his/her neighbor’s experience for the same. This is an individual who, when presented with a Smart Phone, wants to have features and applications behaving a particular way, and will only put up with the provided options of the telco because there’s no other choice. In short, they have a craving for personalization, and will gladly move to any platform that has applications that meet their needs.

Deploying a mobile application to meet these needs is, in its simplest form, the following: First, you must have a developer able to access your SDK, platform and testbed with minimal fuss. Then, that developer must be able to deploy his application to a location where a potential user may download it onto their device. Lastly, the device must be able to run said application. These three tenets of Develop, Deploy, Consume can be easily seen on the regular web. Developers have their SDK’s, Deployment happens on a web server, and browsers allow consumption of the offered services.

In the mobile world this isn’t quite as simple. Yes, there are many websites now that have mobile components, yet lets face it: The form factor and memory constraints of mobile computing devices make it so that few applications can offer full functionality and experience while constrained by regular browser controls. Additionally, we are back to (for the time being) the computing world of the early 90′s, where applications are restricted by processing and memory constraints. Back then, however, we could load applications from Floppy disks, something that’s not so easy on a mobile device. The development platforms exist, but deployment (as noted above) is extremely difficult, and the broad diversity of devices makes your target installable base problematic at best.

So let us take a look at the various players in the mobile market right now. First of all, let us look at the telecommunication companies, those that have the aforementioned problem with getting something On Deck. From their perspective, they have control over their delivery platform, and getting something from their platform to a mobile device is simple enough, however their process is such that they have completely lost their developer base. There are too many devices, too many different platforms and form factors, and deploying an application is simply too difficult for any developer to bother building something. Imagine the computing world in the mid-80′s, and you’ll understand what I mean.

Next let’s take a look at Microsoft, which in our case will also double as any company that has a mobile application which they want to deploy. Microsoft has historically been brilliant in its developer support tools, so much so that it’s stupidly easy to develop an application for their operating system. Similarly, the fact that they are in the software and not the hardware business lets them sell a platform rather than a device, which allows mobile manufacturers to create devices that can run any application built for it. The place where they have failed, however, is in securing and simplifying the delivery platform, which remains under the control of the telco’s.

Third, let us look at Google and Android. Here, the development platform is easy to access and has some brilliant development tools. And… then what? Well, frankly, we don’t know a whole lot about how Android will be delivered, because while many manufacturers and providers have jumped on the bandwagon, we as of yet have no idea whether Android will use an open application deployment platform, or even whether phones built by their manufacturing partners will come with Android pre-installed. The suggested promise of Android is Build Once, Deploy To Any Phone, but if it means that a developer still has to get something On Deck with a Telco, you will once again be in the same boat as Microsoft- a common platform, but no control over application distribution.

I should note here that I doubt Google will not have some central application service, it simply hasn’t been announced yet.

Lastly, let us come to Apple. In this case I have to make a special note, in that while I recognize the SDK is publicly available, it is unfortunately not available for Windows (No, Aptana junkies, that’s just a web browser). Thus while they have alienated a good percentage of computer users overall, the additional cost of an OSX development platform is comparatively minor, and won’t detract a company interested in building an iPhone application. Taking that into consideration, they have everything buttoned up. Developers can access the SDK, they have an established and largely ubiquitous deployment platform not tied to the telco, and they have a device that will run any software built. This end-to-end solution is exactly the same thing that made the iPod so successful, because it got a user from Purchase to Play in one smooth experience.

And no, I don’t own an iPhone.