JavaScript at paulcarvill.com, the home of Paul Carvill on the web

link: paulcarvill at flickr

paulcarvill.com

Hi, I'm Paul Carvill and I'm a web developer. I am Head of Interface Development at LBi, Europe's largest digital agency.

I also like walking, cooking, Bollywood and rock 'n' roll.

Archive for the ‘JavaScript’ Category

JavaScript Client Library for Google APIs Alpha version released – The official Google Code blog

Sunday, December 4th, 2011

This compact and efficient client library provides access to all the Google APIs that are listed in the APIs Explorer. The client library is also flexible, supporting multiple browser environments including Chrome 8+, Firefox 3.5+, Internet Explorer 8+, Safari 4+, and Opera 11+. In addition, the JavaScript client library supports OAuth 2.0 authorization methods: JavaScript Client Library for Google APIs Alpha version released – The official Google Code blog.

Where is the interface development profession heading in the next few years?

Thursday, January 20th, 2011

I originally posted this as an answer to a question on Quora, but I thought I’d post it here too, with a few minor changes, as it’s an accurate reflection of my current thinking.

Web development is an industry which moves fairly quickly. Looking back, between 1990-2000 a huge amount was achieved, including, fairly obviously, the invention of the web and thus the creation of the industry. But in the same length of time between 2000-2010 the industry was far less volatile than you might have expected. Until the last 2 or 3 years I’d say it was definitely a demotivated industry in danger of being almost in a state of inertia. So, here’s what I think will happen to the profession over the next few years.

Right now
Interface development (or client-side/front-end development) is the hottest area of development right now. Platform, device and browser innovation and competition is currently the healthiest it’s ever been. This means interface developers, in some ways, have the richest set of tools and the quickest route to market of anyone in the web development world.

At the same time, they operate in what Douglas Crockford once described as “the most hostile software development environment imaginable” — the browser. The sheer variety of user agent rendering, standards compliancy and provision of APIs means that creating consistent cross-platform websites will remain a specialism. Combine this with the ever-increasing demand by the market for rich interfaces, web standards and accessibility, and you ensure the continued high-value placed on interface developers.

Technical maturity
I see the profession evolving in two ways. The web development industry is working to apply the lessons of computer science to interface development, to create robust, repeatable mechanisms for development, testing and deployment. At the same time as developers from other disciplines are generalising their skills in the direction of front-end tech, so front-end developers are embracing full-stack development. You will increasingly see programmers equally comfortable working on either side of the client/server divide, and particularly using dynamic languages — there’s natural bi-directional traffic between JavaScript and Python/Ruby, and there’s an ancestral line between JavaScript and Java/C#. This trend will continue in a logical fashion to embrace development on Infrastructure-as-a-Service systems such as Amazon EC2, Heroku and Google App Engine, and will peak in a mammoth movement towards Platform-as-a-Service systems, with tight integration between users and the host service, whether it is Salesforce, Facebook, Google or even the UK government.

This focus on the technical aspects of the profession will also see a blooming of the Web Performance Optimisation industry (WPO), and the deep analytical aspects of this will attract a certain proportion of the interface development community.

Beautiful creativity
The other path that will become more apparent as time goes on is the one focusing on true front-end technologies, the user experience and the creative process. Standards-support from the browser vendors, fast broadband speeds, GPU support and the ubiquity of development frameworks for every possible requirement mean that rich, seductive interfaces, immersive multimedia environments, games and a tighter integration with the desktop/OS/device will be more and more popular. Specialisms, and greater toolsets, will emerge for vector graphics (SVG) and bitmap graphics (Canvas), and tech-leaning creatives and formerly emasculated Flash/Flex developers will all be sharing the spoils.

$$$
I also see an initial rebalancing of pay structures to reflect both of these changes in the current weighting of development disciplines. This has already been happening for some time, with server-side jobs increasingly commoditized and their remuneration remaining largely static in comparison to front-end developer rates which have been steadily rising for the last 18 months. This may itself be counterbalances, however, by an influx of eager interface developers who are skipping college/university and going straight to work for a startup, agency or enterprise.

A collection of links about JavaScript and the MVC development pattern

Wednesday, August 19th, 2009

I’ve been doing most of my JavaScript development over the past 12 months in a Model-View-Controller pattern. This separation of function has a multitude of benefits for a programmer — it enables writing of clearer, more readable code, can result in more modular, reusable code and, perhaps most importantly, it enables a Test-driven approach to development.

Now A List Apart has published their own JavaScript MVC tutorial. It’s very useful, and very easy to follow. I recommend it as a starting point if you’re interested in this method of development.

Developing JavaScript in an MVC pattern is an especially good fit for web developers familiar with the now widespread, if not quite ubiquitous, separation of form and content in their programming methodology. Something like the paradigm which you apply to delivery of web content using HTML to provide data and CSS to provide the look and feel can be applied to JavaScript in an MVC pattern, where the Model provides the data, as might a server-side database, the Controller plays the part of the web server delivering that data and the View is the browser itself, rendering content to the page.

I’d also encourage developers to roll their own MVC framework rather than dive right in and using one of the existing ones, at least initially. It will give you a much better understanding of the pattern, it’s benefits and probably pitfalls, and will let you comfortably learn to extend your programming prowess at your own pace.

Note: you could also implement JavaScript on the server side using MVC, with the caveat that your View function is possibly less conceptually decoupled, but once you’re happy with the pattern this shouldn’t hamper you too much.

A List Apart: JavaScript MVC by Jonathan Snook
“At this stage of JavaScript and Ajax development and adoption, we need to consider separating our code’s components—MVC-style. Such separation may not be necessary in every situation—in some cases, it may even make things needlessly verbose. As our applications get more complex and require JavaScript interactions across multiple parts of our sites, however, separating JavaScript into Model, View, and Controller parts can produce more modular, reusable code.”

Ben Godfrey: Client-side MVC is maturing
“MVC is the dominant model for UI development in the desktop world. A modified form is very popular in web development. It makes a lot of sense to stick to MVC for RIA development. RIAs running in the browser (or Flash or AIR) bear close resemblance to desktop applications.”

A list of JavaScript MVC libraries and associated stuff:

I don’t use any of these, but they might be helpful for developers in a hurry. To be honest, the vast majority of my stuff is really VCS (View, Controller, Service), where the Service layer may be a remote API or HTML fragment which you needn’t model, but adding a Service layer isn’t a great leap once you’ve made the conceptual jump from more basic procedural JavaScript programming to MVC.