News

Patrick Van Kann: A better Internet

Most developers celebrate the rise of HTML5 and JavaScript as the dominant rich Internet application technology, but few could have dared hope that Flash would disappear so quickly.

PatrickF

BIO: Patrick is responsible for driving and shaping R/GA’s technological vision, while also working closely with clients to help develop their strategic technical requirements. Prior to this, Patrick was director of engineering at the Walt Disney Company

In our enthusiasm to build a new Internet on open standards, we must be careful not to make the same mistakes with HTML5.

Flash was the standard for rich content on the Internet, mainly because there was no other option. Browsers did not support animations or web video natively, forcing developers to use plug-ins. Flash defeated competing plug-ins like Real Player and Microsoft Silverlight. According to Adobe, it’s available on 98 per cent of desktop browsers.

The only non-plug-in option for rich content, JavaScript, suffered from the inconsistent way that it was implemented in different browsers, making cross-platform code difficult – but worse, many web developers (myself included) considered it a toy language in comparison with Java. JavaScript was confined to basic tasks such as form validation, dynamic navigations and basic content manipulation.

Although Flash achieved dominance, few regarded it as a good technology. Flash content was rich, but it was hidden from search engines, slow to download and confusing to users who tried to use browser controls like the back button. There just had to be a better way.

Even before Apple’s refusal to include a Flash player in iOS, there was a growing realization that JavaScript and HTML were undergoing a renaissance, making it a viable alternative to Flash for RIA development – even without the new media features offered by HTML5 and CSS3.

How did this miracle transformation occur? First, JavaScript’s critics had underestimated its capabilities for functional programming, which gives it flexibility, elegance and power. jQuery and other libraries showed JavaScript could be used for serious engineering; even high-concurrency server-side platforms can be made through Node.js.

jQuery also made cross-browser JavaScript applications possible by providing universal abstractions over different browsers. And on top of jQuery, open-source developers built an array of new libraries around GitHub, including code analysis tools, test-driven development tools, and optimising frameworks – to modern application stacks in pure JavaScript.

jQuery’s fluent API and ability to mitigate browser fragmentation made JavaScript’s popularity hugely possible, but it is not the only alternative. Frameworks like MooTools or Prototype have their adherents – although no other library has been as widely adopted as jQuery.
The success of other non-compiled languages like Ruby and Python has shown that a compiler is not essential for building large-scale applications – unit tests and code analysis can replace or even extend the protection they offer.

Test frameworks like JsTestDriver and PhantomJS enable browserless testing from command line or build script. For actually writing unit tests, Jasmine and QUnit are leading the pack. For those ready to take testing to the next level, Sinon provides mocks, spies and matchers that enable you to write fine-grained tests where collaborating components are faked to isolate individual code units for testing.

JSLint is a widely used code analysis tool, which promises to hurt your feelings and make you a better programmer. And for those who find JSLint’s flinty critiques too harsh there is the gentler JSHint tool.

To reduce the browser footprint of your JavaScript – both in terms of HTTP requests and in download size – there are numerous options for minifying or uglifying multiple script files into a single download. The YUI Compressor is most well known but also check out Google’s Closure compiler and UglifyJS.

There are now many full application stacks, including model-view-controller platforms like Backbone, Spine and AngularJS. A completely browser-based JavaScript application can be built without the need for server-side scripting (other than a REST API to handle data requests).
All of this has created new possibilities for JavaScript engineers – but also new risks. As the capabilities of modern browsers enable more sophisticated and exciting interactions, many of us fall in to the trap of exploiting these opportunities without casting an eye back to our recent experience with Flash. The temptation to add imaginative interactions in the frontend is leading to practices that give poor browser performance, and cope poorly with the increasing number of mobile devices used to view our sites. Careful technical design is as critical as ever.

A colleague of mine at R/GA London often uses a quote in a talk on this very subject, where he references Jeff Goldblum’s character in Jurassic Park, saying “…your scientists where so preoccupied with whether they could, they didn’t stop to think if they should”.

So next time you are building a ‘totes amazeballs’ parallax extravaganza in HTML5 and JavaScript, take a step back. Try to think about how it will work on a mobile device on 3G. Users won’t congratulate you for using web standards if they have to wait three minutes for the page to load.

×