During the past couple of years we have seen major improvements in "modern" browsers
(or client).

When Google released Chrome back in 2008 they started an arms race between vendors to claim the title of the fastest browser in town. Under the hood Chrome uses the same rendering engine as Safari but what makes it special is Google combined it with a ultra fast JavaScript runtime called V8. Since then Apple, Mozilla, Opera, and even Microsoft have picked up their game and released faster versions of their browsers.

Alas this has left older browsers looking decidedly long in the tooth. To put the speed difference into perspective imagine for a moment browsers were vehicles. Chrome would be a Ferarri speeding down the autobahn, IE8 an electric milk float creeping down your street, and poor old IE6/7 about as fast as a broken down Lada being pushed uphill by a geriatric. The difference is really that profound.

So why is JavaScript so important anyway?

These days many of the sites you spend your time on are in fact large JavaScript applications. Think of Gmail, Google Docs, Facebook, Mobile Me, or the new Twitter. Even the average Joe's otherwise static blog includes a bunch of facebook "Like" buttons and social widgets. JavaScript really is everywhere.

If anything the trend is accelerating, users have come to expect responsive applications and the web apps we build have to compete with native mobile experiences. Studies have shown that that if UI is blocked for more than a tenth of a second users start to perceive the slow down. Having users wait seconds while your render the whole page just isn't cool anymore. In order to meet these requirements its necessary to change how we build websites. Rather than doing all the work on the server then serving up the resulting page in one go, the code runs in the client (the web browser) and updates the page dynamically in real time.

For web developers the shift in logic from the server to the browser brings with it challenges. Unlike on the server where we have many mature frameworks in the browser the frameworks are more nascent. Many developers are familiar with jQuery and use it to add small bits of animation and interaction to pages. While it's perfectly suited to this task it's not sufficient for building well structured applications, it quickly becomes rather messy. To me a piece of the puzzle is missing.

Necessity is the mother of invention and I'm happy to see many great developers working to fill the void. One of the core developers of the popular server side framework Rails has left to work on Sproutcore (an Apple backed framework) and only last week news broke that 37signals had been experimenting with building a Rails-like framework in CoffeeScript. Personally I'm putting my money on what Jeremy Ashkenas and crew are cooking up over at Document Cloud. I'm willing to bet during the next year we will see one of these new frameworks gain significant traction and kick off a new breed of web apps.

What does this mean for clients?

Clients may not care which technology developers use to build their apps. However it's important to understand the impact it will have. If you choose to go with modern technology you must accept that there are tradeoffs to be made. Not everyone driving a Lada can come along for the ride. If you hold back users may vote with their feet when a competitor releases an app that's much more responsive.

As Technical Director it's my job step back and see where things are heading and ensure we are ready as an agency to meet future challenges. Through our internal work on apps we are investing resource in learning new ways of structuring applications, what works and what doesn't. This is valuable knowledge we are then applying directly to client projects. When you consider your next project ask yourself if you are building a classic web site, a modern web app, or some hybrid of the two. Are you planning on having an API? Do you need a mobile version? Be prepared to challenge your assumptions and most important of all make sure you are working with the right team.

--------------------

A geeky aside

One interesting bonus you get by shifting your logic to the the client side is that your choice of server side technology becomes far less of an issue. In effect your server side code becomes your API that handles your backend business logic and the client handles the UI and view. It's a nice separation and makes it easy to support other clients in future. Also the app doesn't have to be confined to a web browser, it could be wrapped in something like Phone Gap and distributed through the app stores to mobiles or even downloaded to the desktop.

Codegent's Technical Director, Luke Hubbard, is speaking at the Spark Conference in Amsterdam on November 16th.

The Spark Conference is Europe's Premier Flash Event and attracts experts from around the world.

Luke will be giving a presentation about Red5 the Open Source project he is collaborating on; a Java server designed to provide various services to Flash clients. The project has already attracted a lot of attention and we hope to be able to produce a white paper shortly that explains how Red5 will be able to help thousands of website owners when it is released in 2006.

Later on in the conference, Luke will also be part of a panel discussion on the subject of Open Source Flash.

Spark Conference »
Red 5 Project »