Have you been promoting JavaScript? Did you even know that you could/should be? It just got easier to help if you are using ExpressionEngine.
At JSConf 2010, Chris Williams started a project called PromoteJS to help get bad JavaScript references off the web. You will know how important a cause this is if you have ever done a Google search for JavaScript documentation or help. The top results are deplorable. (NEVER use w3schools.)
In many other interpreted programming languages like: Python, PHP, ActionScript 3.0, etc., you can have defaults to arguments that do not get passed to functions. In the three a fore mentioned languages, it's as easy as saying arg = 'default' inline in the function definition. This however is not available in the JavaScript interpreter. (It might be in ECMAScript 5, though.) But that can easily be remedied with a simple helper function.
I have met other programmers that find it ridiculous that you have to create features in JavaScript that are built into other languages. They use that to put down JavaScript and call it a terrible language. However, I think that's part of what makes JavaScript so great. JavaScript, though not as powerful in features as some other languages, offers enough flexibility and expressiveness that you can create what you feel that you are missing. Lets take a look at the problem and see how easy we can remedy it.
Many newcomers to web development may not be used to how web implementations of JavaScript execute. Namely, in what order it executes. This can be the source of many errors that are difficult to pinpoint if you aren't experienced with it. I think this also affects people who are very experienced with other programming languages and fosters a lot of undeserved hate towards ActionScript and JavaScript. (It's important to note that not all implementations of JavaScript are the same, and that some may in fact defer from what is said below. This article concerns browser and Flash based ECMAScript.)
The thing to understand about JavaScript is that it isn't compiled for the most part. (This is not exactly true for ActionScript because of the introduction of classes in ActionScript 2.0, however, the runtime script remains the same. You might argue that it compiles into a *.swf file, but in reality, that is the combination of everything that has to do with the Flash file. The ActionScript still remains live.) It's good that it isn't compiled though, because this allows for much more dynamic, expressive coding.
In JavaScript the typeof operator reports an array as 'object'. While this is technically correct (an array in JavaScript is really just a specialized object), it's a pain in the neck when you are type checking a variable.
There are a number of ways to identify an array in JavaScript. Checking for properties of an array isn't totally accurate because you can add any named member to an object to imitate an array. Checking for 'instanceof Array' works most of the time but could be tricky in some implementations of JavaScript.
When using multiple JavaScript libraries, it is inevitable that one JavaScript file will need to call functions named in other libraries. This is necessary but can cause issues if all of the libraries aren't present.
Error handling with JavaScript is somewhat lackluster. With this in mind, you should do your best to catch and handle errors and avoid sending them to the end-user. In order to prevent errors and allow for scalability, you should test for functions that aren't present in the script where you are calling them.
One of the most powerful idioms available in JavaScript is the anonymous function closure: e.g. (function(){})();. If you are unfamiliar with this, it simply creates an anonymous scope bubble that can be used to prevent automatic global variables, or trick JavaScript into allowing private variables. Unfortunately, this idiom isnt available in ActionScript 2.0. It simply doesnt work. (As of ActionScript 3.0, it works perfectly.)
This means that, on the surface, the only way to prevent time line variables from being constantly created is an init function of sorts. (ActionScript 2.0 has a pseudo global object which is the main time line of a movie level, and a totally global object named _global.) This also means that private variables are restricted to the creation of object classes. I personally get annoyed at times with classes in ActionScript. One of the things that has always bugged me with ActionScript 2.0 and the introduction of classes is that they are hard to make portable. (I work on no less than 3 computers in a single week, and 4-5 when on business trips, so portability is paramount to my work.) Rather than being able to simply include the classes in the same folder as the flash working file (*.fla), you must specify where on the computer the includes are. This is just annoying if you work on the file on several different computers. There are a couple of ways to avoid naming the class include folder on each computer, but they are as much of a pain as the default method. Fortunately, there is a solution.
