Here the evolution of a JavaScript coder, taken from the Best Practices in JavaScript Library Design presentation by John Resig at Google HQ.
Technorati Tags: javascript, coder, best practices, googleplex
John Resig, lead developer of jQuery, went down to the Googleplex and presented on JavaScript best practices, which he learned from developing the popular jQuery JavaScript library. The video of the presentation and the slides from the talk are available from John’s post on the experience.
For my own benefit I’ll recap some of John’s key points made in the presentation. In writing a general purpose JavaScript library you need to deal with browser specific bugs, have enough documentation in place, provide test cases, keep maintenance in mind, and have a solid API design.
In talking about API design, John said to fear adding methods. The more methods your library supports, the more code there is to maintain, support, test, and document. Instead of adding methods to your API you should embrace removing them where it makes sense. If you add/remove methods between releases be sure to provide an upgrade path, preferably through a plugin. For example, when moving from version 1.0 to 1.1 of a library you can provide a 1.1 plugin that eases the migration for 1.0 users.
John reminded the audience that a consistent API is paramount to designing a general purpose JavaScript library. A consistent API means following a naming convention for method names. The naming convention includes method signatures, for example follow a consistent position or order for parameter types. In addition to following a naming convention, you should be clear about behavior.
When developing a enterprise-grade JavaScript library you need to have a good grasp of JavaScript language tricks and features such as closures, encapsulation, local variables, and namespaces. John also recommended not to extend browser native objects because it is hard to get DOM extensions working across browsers. Also a new version of a given browser might introduce functionality or new methods that conflict with those your library adds to native objects.
A key point made by John, which I alluded to before, is to allow for extensibility by introducing a plugin architecture. If you allow end users to create their own extensions you will have less functionality to maintain yourself, you can always defer feature requests to the community. Since much of the functionality can be added as plugins, the core library will have a smaller footprint.
If you are counting on the support of a community of users, John stated the importance of having clear and concise documentation. Documentation is key in fostering a sense of a lively community. Provide documentation in a clear format (something like XML) and allow users to build their own API viewer. Encourage users to build and disseminate cheat sheets, API widgets and viewers, and translations of the documentation. Right from the start, provide enough documentation for the community to get started, such as tutorials on plugins.
Technorati Tags: jquery, javascript, library, best practices, api, googleplex, google, video, presentation
The iPhone Dev Camp started on Saturday by a nice presentation by Chritopher Allen, a MacHack veteran, regarding what is known about the iPhone from a web developer’s perspective. What is known is that the iPhone uses web standards (HTML, XHTML, CSS, JavaScript, PDF and Quicktime). Web 2.0 best practices apply for the iPhone, such as the proper use and sepration of HTML, CSS, and JavaScript. Christopher recommends avoiding the use of Flash, SVG, Java applets, embedded video, custom x.509 certificates, and framesets. Christopher also states the the finger is not a mouse and you need to design accordingly with large enough buttons and links with plenty of space between each other.
Fingers can do more than the traditional point and drag cursor such as double tap, touch and hold, one or two finger drag, flick, and pinch.
It might come as a surprise but many of JavaScript events don’t work, such as onscroll, onkeydown, onkeypress, onmousemove, etc. Some web development recommendations for the iPhone are to use columns and small blocks in the layout, such as floating divs. You should also use the tel: and mailto: protocols in links. You can also integrate with Google Maps simply by adding your location search to maps.google.com/maps? URL.
The current activity on the the iPhoneWebDev Google Groups seems to be focused around iPhone specific development libraries, implementing the infamous back button, debugging JS, optimizing application for low bandwidth, and hacking the viewport. There is also a series of open questions such as, what level of support is there for the canvas tag? What level of persistent storage is available, cookies? The right questions will lead to the right answers. I have also published a great list of available iPhone development resources.
Most of time at the iPhone Dev Camp was spent developing a collaborating for the hack-a-thon. This was a working camp focused on developing some really cool applications on the iPhone.
Continue reading
Here is a list of links to the best available iPhone development resources such as simulators, development plugins, wikis, and other JavaScript/HTML/Safari documentation.
Bonus Resource
Technorati Tags: iphone, development, webdev, apple, safari, javascript, iphonewebdev, iphonedev, iphonedevcamp
I have a really good friend that runs a small travel related blog and she wanted to add Google Maps to her site to go along with her articles, such as this post on LA restaurants. But she is a not a developer and would never ever want to tinker with the necessary JavaScript code used by the Google Maps API. To help in her task of generating custom maps I quickly whipped up Map Builder. Map Builder allows you to zoom in, center, and add any number of markers to a Google Maps canvas. Once you are happy with how a map looks, you can generate the necessary JavaScript code which can be embedded in you website. You do need to sign up for a Google Maps API key before you can display the map on your domain.
On the technical side, I use the Google Geocoder to resolve the longitude and latitude of a given address. Creating a marker for that location is pretty straight forward and there are plenty of examples in the Google Maps documentation. To generate the custom JavaScript source code I used the JavaScript Templates library from the Trimpath project.
Technorati Tags: javascript, js, trimpath, javascript templates, google maps, map builder
In JavaScript there can be only one JavaScript onload event handler. This is a somewhat an issue if you have all sort of third party libraries that want to run some piece of JavaScript code when the page finishes loading. You can use the YUI! Event library add and chain event listeners to a DOM element, but adding another resource dependency to you application might not always be the right answer. I recently had to chain some onload event handlers for a simple script I was writing and I didn’t want to require any additional files. Here is my poor man’s version of a JavaScript event chain gang.
// The loaders array will contain a
// list of event handlers
if(!window.loaders) {
window.loaders = new Array(0);
}
// Save the current event handler
if(window.onload) {
window.loaders.push(window.onload);
}
// Attach new onload event handler
window.onload = function() {
// Execute previous cached event handlers.
for(var i=0; i < window.loaders.length; i++) {
var func = window.loaders[i];
func();
}
// New event handler code goes here...
}
With code like this you can guarantee that the old even handler code will run before your new code.