Thinking beyond Web 2.0
Wednesday, June 18th, 2008
Over the past few years we have seen people do some remarkable things with Javascript. This is almost like the age of enlightenment for Front-End developers. In a short amount of time we have gone from a majority of hobbyists and hackers to a group with a fair amount of true engineers. In some cases we are even gaining respect from back-end coders. We have done well for ourselves.
Now we are experiencing some growing pains as Libraries are created and each competes to make their code faster and better. We are left wondering what direction to head next. It seems that there are so manny possibilities going in so many directions that if we follow the wrong one we could end up loosing our way and get left behind by the time Web 2.0 gives way to Web 3.0.1 Gold Vista-Leopard. Honestly though, I don’t think that things work that way. None of the changes that brought us to “Web 2.0″ should have been a surprise. We had been tinkering with ways to make things more interactive for years. Also, coding styles may have changed. This was no surprise either, we knew that we were hacking Javascript all along. I think in some way we all knew the time would come where we had to start respecting it as a real language and start following some standards. So, here we are still waiting for the next train. I think it should be obvious if you use common sense. Everything that you are doing now that you have always done, but just seems wrong will be replaced by a way that actually works.
Here are a few areas that I think would be smart areas to focus:
- Unit Testing: We will find ourselves building complex applications which can have many points of failure. Unit testing each interface can help us to make sure that each component of our code meets guidelines before moveing to build the next component. When QA comes knocking on your door they will find fewer bugs and you will have an easier time fixing bugs that are found because you will be more familiar with your code. It is no wonder why your buddies that code languages like Ruby and Java are crazy about Test Driven Development. Here are some resources that are available to unit test Javascript:
- Name Spacing: For any of us that have subscribed to Dustan Diaz’s blog or that use the YUI libaray, this is old news. Still a lot of us are not keeping our code in a namespace. This ensures that any future home that your code finds itself. May it be a browser running Javascript 8.0 or a new JS library, your code will not collide with anybody elses code. When all browsers decide to start to support a String.toJSON() method, it will not conflict with your ME.string.toJSON() method. for more info on this check out the daddy of all JS namespacing posts: http://www.dustindiaz.com/namespace-your-javascript/
- Code Composition: We need to start thinking of our code as something that is going to be seen by other people. Code should be reusable and the more organized, commented, and spaced it is, the better. Cleanly composed code also is easier to troubleshoot. Sold yet? Good. Here are a few tips:
- Use a minifier that strips our comments and spacing before moving code to production. This gives developers the freedom to comment and space as much as they need without effecting the weight of the page over the wire.
- Use symantic names for your methods. We all know that the only documentation that we want to write is our code. When somebody encounters an object that you have created to deal with a customer they will be way more likely to understand a method named “saveCustomerData()” then one named “ajaxCall()”.
- If you don’t need to re-use it, nest it. For example, if you are calling a method that asks for a function as a parameter to use a call back, nest the function inside of the method call. A lot of people think that it is cleaner to declare the function first and then put its reference into the method call, but this moves the code for the function out of context while reading the code. It also requires more work for the browser to first declare the function and then envoke it later. Here is a code example:
yourObject.yourMethod(function(
/* string */ argument 1,
/* Object */ argument 2
){
//Code here
});
This all comes down to common sense. I am sure that there are a lot more things that could be added to this list and I would love to revise this later. This is the direction that I am heading for now.