• Comment as much as needed, but no more: comment what you consider needed, but don’t tell others your life story. Too many comments may make some other developer get distracted from the actual code.
• Javascript is used to define the behaviour, not the look & feel: even though there’s the possibility to set the appearance of your application through JavaScript, you should leave that for CSS. Always follow the “separation of concerns” mantra. A change in the icons or the color of borders shouldn’t require dealing with JavaScript code.
• Modularize: keep your code modularized and specialized. Make sure to write smaller, generic helper functions that fulfill one specific task, rather than catch-all methods.
• Allow for configuration and translation: everything that is likely to change in your code should not be scattered throughout the code, for example, labels, CSS classes and IDs. By putting these into a configuration object and making it public, we make maintenance very easy and allow for customization.
• Access the DOM as little as possible: accessing the DOM in browsers is an expensive thing to do. The DOM is a very complex API and rendering in browsers can take up a lot of time. To make sure that your code is fast and doesn’t slow down the browser to a halt try to keep DOM access to a bare minimum.
• Build on the shoulders of giants: JavaScript libraries are specifically built to make browsers behave as you would expect by plugging browser holes. Therefore, if you want to write code that works without keeping the maintenance overhead of supporting current browsers and those to come, start with a good library.
• Development code is not live code: live code is done for machines, development code is done for humans. Make your code as readable and understandable as possible. Then, before deploying your web application, collate, minify and optimize your code in a build process.

If you follow all these recommendations, you can be sure you’ll have produced a high quality code that will be easy to maintain.

Related posts:

1. JavaScript best practices I
2. Javascript frameworks overview
3. Object Oriented JavaScript I: the basics

• Always use ‘var’: although it is not compulsory, the use of the ‘var’ keyword is always recommended. By using it, your code will execute faster, and you will avoid some potential problems.
• Feature-detect rather than browser-detect: before using any advanced feature that an older browser may not support, check to see if the function or property exists first, instead of writing code to detect browser versions.
• Avoid ‘eval’: the eval() function in JavaScript allows a programmer to run arbitrary code at run-time, by interpreting a string as if it was code. If it exists in your page, there is almost always a more correct way to accomplish what you are doing. “Eval is evil.” Don’t use it unless you are an experienced developer and know that your case is an exception.
• Use unobstrusive JavaScript: now, this is an important one: HTML and JavaScript code should not be mixed together. You should always follow the “separation of concerns” mantra: HTML defines the structure and content of a web page, and JavaScript defines the behavior. Therefore, do not use inline event handlers. Attach your event-handling code by JavaScript. This way, you’ll improve readability and maintainability.
• Avoid cluttering the global namespace: global variables and functions are rarely required. Using globals may cause naming conflicts between JavaScript source files and cause code to break. You should always use object oriented programming and write all your code in classes when writing JavaScript code.
• Use JSON: when storing data structures as plain text or sending/retrieving data structures via Ajax, use JSON instead of XML when possible. JSON (JavaScript Object Notation) is a more compact and efficient data format, and is language-neutral.
• Make you code understandable: choose easy to understand and short names for variables and functions. Think of your code as a story – a story that should be easy to read and understand, the names you choose shouldn’t make it more complicated.

In my next post I’ll discuss some more recommendations. Stay tuned!

Related posts:

1. JavaScript best practices II
2. Object Oriented JavaScript III: some tips
3. Object Oriented JavaScript I: the basics
4. Javascript frameworks overview
5. Object Oriented JavaScript II: the pattern

GUI testing can cover applications areas that don’t have unit tests. It might be easier and require less time to write GUI tests rather than unit tests. But this approach is not recommended. If you’re serious about the quality of your products, then you should plan to write both unit tests and GUI tests. The reason is that GUI testing has a different domain and tries to find different kinds of errors than unit testing. GUI testing will find the parts of your applications that work in some web browsers but won’t behave correctly in some other web browsers (as IE, for example). Some other features that are normally tested include the loading and performance of the site along with the links, website security and log analysis.

In GUI functional testing, you can make use of a tool that will allow you to create tests that can mimic the activities or actions and the assessments of the actual human testers. This will help you get better results and be able to improve your website’s interface. You will also have this tool performing the tests whenever you tell it to. I like to configure my tests to be run nightly, so when I come in the morning I have a list of which tests passed and which ones I have to take a look at.

GUI testing tools assist test engineers with regard to recording test scripts, inserting verification points, and testing data:

• When capture/playback is turned on, it can record/reproduce the actions performed by a real person. It saves testers from writing test scripts by hand.
• Testing tools also have tests harnesses to manage the automated test scripts. Testers can use the available harnesses to schedule testing executions and manage effective regression testing by reusing the script library.
• Testers can use these tools as learning assistants. Testers can use the tool to learn the properties of different GUI components and learn how to operate different GUI components programmatically.

So, if you haven’t tried GUI testing yet in your web app, get to it ASAP. If you don’t know which GUI testing tool to use, give Selenium a try. Selenium provides a record/playback tool for authoring tests without learning a test scripting language. Selenium provides a test domain specific language (DSL) to write tests in a number of popular programming languages, including C#, Java, Ruby, Groovy, Python, PHP, and Perl. Test playback is possible in most modern web browsers. Selenium deploys on Windows, Linux, and Macintosh platforms.

Selenium is quite known and is the one I use, so I totally recommend it. However, if you want to check out some other tools of this kind, you have a list at Wikipedia.

Related posts:

1. Improving software quality: automatic testing
2. Load testing
3. Unit testing
4. Test-driven development
5. Browser comparisons

• SunSpider JavaScript Benchmark
• SlickSpeed (jQuery values reported)
• Numion stopwatch
• CSS Rendering Benchmark
• Resource Monitor

And this is the result they came up with:

Performance comparison of web browsers

Nothing really surprising here… Google Chrome seems to reign in most categories, specially in Javascript execution speed. This makes it the most suitable browser to use in our web apps, with increasingly heavy usage of Javascript.
Nice post to have handy to help you make your point why IE should be considered as a toy browser, not a professional tool.

Related posts:

1. Tired of IE’s issues? Turn it into Google Chrome

Well, Google seems to be worried about this as well, and now gives us one more possibility to solve the problem: turn Internet Explorer into Google Chrome.

Google just released its new plugin for IE: Google Chrome Frame. This plugin substitutes the HTML and Javascript engines from IE with the ones from Google Chrome. This way we’ll be able to enjoy Chrome’s speed and compatibility.

I was surprised when I tried: it is exactly as having the Google Chrome browser inside IE. You can tell no difference between the real Google Chrome browser and the plugin installed in Microsoft’s browser.

Now, this plugin doesn’t fully replace IE’s HTML and Javascript engines: it just sits there waiting to be called, which can be done in two ways.

The user can decide which pages he/she wants displayed by Chrome Frame by inserting cf: right before of the URL address. This is, if you type  http://www.undisciplinedbytes.com in IE’s address bar, it will be displayed normall, as always. But if you write cf:http://www.undisciplinedbytes.com, then Chrome Frame will be in charge of rendering the page to you.

Besides, a web developer might want to force a web page to be displayed using this plugin, as long as it is installed on the client’s computer. If you add this tag to the HEAD section of a web page, Chrome Frame will be activated:

<meta http-equiv="X-UA-Compatible" content="chrome=1" />

If Chrome Frame is installed, it will recognize this tag and realize it’s being requested to start working. If it is not installed, other browsers will just ignore the tag and behave as if it wasn’t there.

Furthermore, the plugin extends the User Agent string with the keyword chromeframe. This means that we as web developers will be able to figure out whether Chrome Frame is installed or not, and take different actions in different situations.

This is the official web page of the project.

Noble intentions Google has, no doubt about it. Great way of solving the limitations of legacy browsers and improving the usability of the web.

However, as good as all this sounds, we do have to be careful when using this plugin. We need to realize that there are many web applications that have been developed with IE in mind, or even straight targetting Microsoft’s browser. This means that we need to activate Chrome Frame only on those pages that we have previously tested that work fine in Google Chrome. We cannot just put the meta tag in all of our web pages and forget about everything else!