Got a quick-and-dirty Web application? Then a quick-and-dirty script will probably be fine. Small apps don’t strain resources, and so they generally execute quickly even if they’re not particularly well written. But if the app isn’t quick and dirty, then dirty scripting means the app certainly won’t be quick.
If the same script code is going to be used in multiple pages, you can make the app more efficient by caching the code. By caching it in the browser, you pay a modest price up front by requiring the browser to download the code the first time. But you’ll recoup it many times over through the decreased load time.
It’s easy to do. Tag the script in your app with <script>, and specify the file containing the script with the src attribute:
Tip #2: Accumulate HTML in string variables
When you write a large amount of content to a page, you may be building the page content element by element as it loads, using document.write( ). This works fine, but cranking out HTML this way is I/O-intensive.
An alternative is to confine yourself to a single use of document.write( ). Instead of generating the HTML in pieces, assemble it in a string. When it’s all loaded into a string variable, use document.write( ) once to put it to the page (Listing A).
Tip #3: Do large array lookups as string searches
Plowing through an array is always a cycle drain. Why? Because in addition to the repetitive evaluation, you have the overhead of the control structure you’ve set up to loop through the array. You’re better off using the built-in mechanics.
Tip #4: Avoid inefficient commands in recursive code
If you’re doing a tree search, for instance, to retrieve an element in a child node, you should avoid using a DOM method itself (to identify the element) in the loop-control logic; the overhead you’ll suffer is a killer. Why? Because when a method is invoked, it is evaluated, and that costs cycles and is completely unnecessary. Instead, invoke the method once and load the ID of the element you’re seeking into a local variable.
Another killer function is eval( ). It’s useful for converting a text object ID into an actual object reference. The problem is that it’s a cycle hog, and it’s most often used to do wholesale mass references to page elements when there are lots and lots of them and their names really aren’t important. But don’t go there; you’ll bring your app to its knees.
Instead, try using DOM’s native features for identifying elements—that is, instead of creating object referents by assigning arbitrary names and making them real with eval( ), go with the names that already exist (in DOM; which DOM expression you’d use for this depends on the type of element you’re trying to name). Note that this use of DOM document expressions differs from the example above. Each reference is distinctly useful, creating an authentic object reference, as opposed to repetitively invoking a method when it needs to be invoked only once.
Scott Robinson is a 20-year IT veteran with extensive experience in business intelligence and systems integration. An enterprise architect with a background in social psychology, he frequently consults and lectures on analytics, business intelligence and social informatics, primarily in the health care and HR industries.