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.

The similarities, though, end there. Implementation varies, technology varies, scope and location and functionality varies, and all in all it ends up being a pretty difficult convoluted mess to describe. At best you can group them via complexity, and after a brief exercise of that nature we realized that a new breed of networked application was emerging. Well, alright, perhaps not emerging, but instead gaining momentum and acceptance in the mainstream. Here’s the scale, see if you agree with our reasoning.

Level 1: The Widget

At this level of RIA you are attempting to display information in context of a particular page, however you don’t care about anything but the most basic user interaction. These could be things like drop-down menus, product detail pop ups, rotation views, buttons that reveal and/or expand text content (like reviews) and so forth. They are almost always implemented in JavaScript, because to use Flash or another plug in technology would be quite a bit of overkill.

Level 2: The Functional/Interactive Widget

This level of RIA’s describes widgets that allow a user to complete a particular functional task. No longer content with simply displaying information, we’ve now added functionality or a experience that responds to user input. This could be as simple as a DHTML login form or as complex as a Flash-based page takeover, but it necessarily remains restricted to a specific, easily definable task. "Log In", "Rate This Product", "Check Convention Schedule" and so forth are good examples, as they add a richer experience that remains in context with the page itself.

Level 3: The Rich Internet Application (RIA)

The next level of complexity takes the task mentioned above and strings them together into a flow, or objective, thus defining an actual application. While previously you would have perhaps a few simple form fields to fill out, an actual RIA causes the context of the page to change dramatically via user input. User interaction is no longer restricted to a single action, but instead is intended to enable an activity, such as "Tracking your time", "Editing a Photo", or "Managing a Color Palette". This is where the bread and butter of RIA’s exist, as well as the holy grail of Web 2.0: A fully interactive and functional application contained entirely within one browser page.

Level 4: The Rich Networked Application (RNA)

The Rich Networked Application (RNA, I’m trying to coin a term here, help me out) ceases to be bound by the browser, and instead has become an experience that bridges and is uniform across all digital touch points. The service is available not only from a browser, but may also be accessed from a desktop, a mobile device, a vehicle dashboard, a kiosk, a gaming console, or any other networked or partially networked device you can imagine. The RNA reaches out to many delivery channels, and while it may provide a different experience for each it nevertheless remains connected in context across them all. Excellent examples of this are Twitter (and all its clients), Google Maps (available on Mobile, Internet, etc), Kuler (Integrated to the desktop and the entire Adobe Suite), as well as upcoming games like Spore (Share creatures across platforms). Implementation… well, lets be honest, it’s a nightmare if you go into it unarmed. You have to support many different platforms, frameworks, systems and limitations, yet even so we’re starting to see toolsets emerge that address them all (Most notably Adobe’s Flex & AIR, Microsoft’s DLR via WMF & Silverlight, and Javascript libraries like SproutCore, MooTools and Prototype).

Did that make sense to you? It does to me, and I’m really excited to see how what we have today is going to start bridging the Device Divide.

HP Print Studio is an internet application that allows users to easily create professionally designed home printing projects customized with their own text and images, and it was the first project I completed at Resource Interactive, marking my transition from a lone-wolf to a team oriented developer. I won’t lie and say that the project was in any way easy- as the quote clearly demonstrates, I didn’t have the slightest clue on how the application would finally be assembled, though I really wanted to take a shot at it. It’s not that I was unfamiliar with the language; It was the fact that the application so tightly integrated visual design, interactivity and application functionality that it couldn’t be classified as either visual or functional: It was both. Without going into too much detail, it rewrote my own understanding of what a true Rich Internet Application is: An integration of experience and functionality so seamless that it becomes its own category.

The challenges within the project itself were many and varied, and on account of our client agreements I cannot go into detail on how it was assembled. Even so, I learned many valuable lessons about team environments, of which I wanted to highlight a few.

Arrogance will get you nowhere

It’s a team, leave the ego at the door. This is more difficult and profound than you might imagine, because independent contractors have to justify their existence and value to the project, and that breeds a certain type of arrogance, independence, and Not-Invented-Here I-Can-Do-It-Better attitude that is destructive to a team environment. Established habits like this are hard to break, and I’m glad that this was the first lesson I learned though I’m still not perfect in applying it.

Expertise plays an important part

From the technical leads Kris and Tommy to our Project Manager John to our fantastic CRMs Kim and Traci (and all the developers and QA people whose names I’m not sure I’m allowed to mention), everyone played a part that was absolutely critical to the project. As a cocky independent contractor it’s easy to downplay the worth of Quality Assurance, Business Analysts and similar positions because their duties sound easy and secondary to the main development effort, and I never took the time to understand exactly how valuable expertise in each of those domains is. Yes, I can do it, but not only can they do it better, they make my job much easier by doing it.

It’s safe to rely on others

When you work in an environment where human resources makes it a point to vet every candidate for job expertise first, and management is not only engaged, but invested in developing and encouraging personal growth initiatives, it is safe to assume your coworkers know what they’re doing. This is practically unheard of in the freelance space, and it caught me by surprise when I encountered it for the first time. Once I realized that I couldn’t get enough, which in retrospect probably annoyed the living daylights out of my coworkers and co-developers (until I got over the newness of it all).

Freelancers: Buyer Beware

Contractors and freelancers are incredibly expensive, and 9 times out of 10 don’t have the skills they claim to have. If there is no relationship between you other than an easily terminated contract, the value to the contractor isn’t the long-term viability of the project, but the ability to get a large project onto their resume so they can charge more next time around. This leads to fraudulent claims and resume padding, so if you are hiring someone who’s got quite a bit of freelance experience on their resume I highly recommend you verify their level of contribution first.