Tuesday, May 19, 2009

Better Javascript in Coldfusion

I gave a presentation today at work on improving your Javascript skills, as it relates to Coldfusion development. While there were a million things I would've like to cover, I only had an hour. Here are some highlights that might be worth passing on:
  • Avoid <cfinput> and <cfform>
    These tools, while helping to make your Coldfusion development faster, really cripple us as coders. I believe that every HTML developer (those who code in PHP, CF, etc.) needs to know Javascript. The js code generated by Coldfusion is very bulky and not necessarily optimized.

  • Avoid using Coldfusion variables in your Javascript code.
    Think it through and parameterize your JS rather than being lazy and including #variable# directly in the code.
    Good and Bad Javascript example

  • Move your Javascript to external files
    By placing your js in an outside file, linked to by your Coldfusion code, you allow the browsers to cache something that doesn't change too often. This results in increased bandwidth savings, better logical separation and enforcement of keeping CF out of JS.

    In addition, if you have access to a "resource service" that you can tell to include a particular js file (as opposed to using the <script> tag) you'll be able to implement a minify/pack/gzip solution as well as a combining technique at a later date. A service like this can prevent multiple script tags for the same file when the HTML is rendered.

  • Think cross-browser, at all times.
    Sure, maybe today your company says "We only support IE". But I can almost guarantee you that tomorrow it will be "We only support IE and Firefox." In one set of code I saw recently, the js would simply reference "myInput.value". Apparently this works in IE, but doesn't work as well in Firefox. If they had done a proper getElementById() or even
    document.myForm.myInput.value there wouldn't have been issues.

  • Get behind jQuery (or some Javascipt abstraction library)
    By using a tool like jQuery for DOM element selection, like $('#myInput'), you enable abstraction of how you get the object. These tools are also optimized differently for different browsers, allowing you to use a single style of object fetching, without writing a lot of "if IE" statements.

  • If you name an object, also give it an ID.

  • Remember, ID's are meant to be unique amongst all elements on a page.

  • If you need to "group" objects, just add a non-styled class element to the objects. Then you can use something like jQuery to get all the elements with that class.

  • Don't use versioning in your file names.
    If you have myCode.1.2.3.js and you reference that in your code, then you have to refactor all your pages that reference that file when you want to upgrade. Just copy that file to myCode.js, then you swap out the files when a newer version comes along with no code changes.

  • Comment, comment, comment!
    Can't stress this enough. Even if you're the only developer on the project and always will be, commenting is still valuable. I can't tell you how many times I've come back to some code, no matter what language I used, and had no immediate recognition of the code I had written or how it worked. Commenting is so important.

  • Try dynamic event binding
    If you have 10 phone fields with onblur="formatPhone(this);", why not add a class to those fields, like class="phone". Then with something like jQuery, you can create an document.ready event that will bind the formatPhone() custom function to all objects of input#phone that it can find. You could save a whole lot of bandwidth on a site that dishes out such a page frequently.

  • Remember, there's always more optimization to be done
    Most developers are receiving a paycheck from a company that has hired them to produce results. Because of this we have to balance speed with quality. Typically, however, a little forethought can go a long way. Rush, rush, rush is never the answer. Spend 3 hours now to do it right versus 1 hour to "bang it out" and you'll be spending that 1 hour now and 5 later trying to refactor it and correct it. (And that's just you....what about other developers on your team that may get saddled with having to fix your poorly thought out code?)
- Will Belden
May 19, 2009
Updated: August 22, 2009