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.

In praise of Hardboiled Web Design

For years, there has been a consensus that great web developers are those who can make pixel-perfect replicas of Photoshop-made designs inside Web browsers, from Internet Explorer 6 to more modern browsers. The markup didn't need to be good (hell, clients don't even see it!), and it didn't matter what dirty tricks you used to make the design come to life, or even if it actually was usable, as long as it was working in IE6.

Today, techniques like "progressive enhancement" or "progressive enrichment" prevail. We have got used to building for the least capable browsers first, and improving the experience where possible for more modern browsers. Dumbing-down the experience, we felt lucky when we could squeeze in a few CSS3 rounded corners.

But that needs to change. There is more to CSS3 than rounded corners and drop shadows. Rewarding viewers using modern browsers isn't enough anymore. This is why I got so excited when a few weeks ago, Hardboiled Web Design, a new book from Andy Clarke, was released.

Hardboiled web design is about never compromising on creating the best work we can for the web. The postulate is simple: it is possible to give clients what they want and at the same time use new technologies such as CSS3 and HTML5 to expand creative options. This is the new Bible of Web development. Quoting from the book:

"The reality is that the web has changed, and our work and our clients' expectations must move beyond the one-size-fits-all approach we have laboured over for so long if we're to make the most of what it has to offer. No two browsers are the same, so to make the most from emerging technologies such as HTML5 and CSS3, we need to banish the notion that websites should look and be experienced exactly the same in every browser."

It is no longer about progressive enhancement or even graceful degradation, it's about acknowledging the browsers' differences, and offering the right experience, appropriately crafted and responsive to the capabilities of the browser. Do websites need to look exactly the same on every browser? No. Do websites need to be experienced exactly the same in every browser? Nope.

Potentially this is a radically different work process, where the Photoshop design phase is skipped, and the site is directly designed inside the browser, using the latest technologies available, and with a strong focus on quality, meaningful markup. Development time is reduced, quality improves, clients get to see the design in action very early on (instead of flat images, which fail to represent the browsers' rendering differences), and users benefit from tailored experiences.

This is obviously not a "one size fits all" approach, but it is definitely worth experimenting with.

Paraphrasing Hardboiled Web Design one last time, the question to be asked for your next Web project is and should be: would you rather have developers spending your budget hacking around issues for older browsers like Internet Explorer 6, or spend this time future proofing the website to look the best it can on better, modern desktop browsers, as well as on a whole host of mobile devices?

So what does this mean in practice?

For Desktops:

• The modern browsers (Safari, Chrome, Firefox, Opera and IE9) get the best experience - the one we design for, right from the start. Webkit browsers (Chrome and Safari) get the best experience of all, as they provide the most advanced CSS3 features.
• IE7 and 8 get a simpler version (this generally means no rounded corners, no drop shadows, and little to no eye-candy effects)
• IE6 gets a custom version of the site, different from the other (possibly very different), to accommodate with its rendering capabilities. Simply put: same content, but different form

For Mobiles:

• Depending on the type of site, modern mobile browsers (iOS and Android browsers) can be served the same version as modern desktop browsers, but with a tailored experience adapted for mobile use (using CSS media queries for instance)
• Older and less capable mobile browsers should be served a different website (to save bandwidth and cut down the load time for the user), requiring separate development

Click here or here if you would like up-to-date statistics on browsers market share.

It is with interest which we have been watching Google’s Android Application competition. This is the $10m competition to develop applications for Google’s Android mobile platform. The 50 semi-finalists were announced today, and although a lot of the applications are shrouded in secrecy, a strong theme seems to be developing. The majority of applications seem to be based around Social Location tools, or Security applications.

For more about the semi finalists information have a look at this site.