The coder’s dogma

Experts will forgive the slightly imprecise title, since this advice applies to client-side scripting
in general. These ideas came together over time, matured, and were replaced or completely
reversed as I gained experience. Equally important were the questions, points of confusion, and myths
I came across in JavaScript discussion groups.

The purpose of this article is to point out some basic rules for coders. If you decide to follow
these few lines of advice, first realize that many features of advanced scripting today
are unusable because browsers implement them differently.
There’s no cause for concern: today’s browsers offer plenty of functions
to make pages more usable if you apply them properly.

Most of these rules came out of a simple question: why? We live in hurried times
and often skip basic questions, even when answering them would reveal
much more of the context around a problem.

Looking back at the history of client-side scripting, there were two main reasons for its creation:
to allow as much user interaction as possible and to work with forms. Move along that timeline
to the present, and increasing interaction was the main driver of the rapid development of scripting.
Today it is easy to implement complex client-server exchanges with techniques such as
XML-RPC, drag-and-drop operations, and dynamic changes to
part or even all of a document.

The golden rule: Sometimes less is more

Think very carefully about any use of client-side scripting on your pages or in your web applications.
Always remember that especially on the internet, many users have scripting disabled or restricted. In that
case, dynamic menus and similar features become unusable bits of code and the pages become entirely inaccessible.
Remember that from the user’s point of view, less really is more.

Rule two: Only standards-based code is usable

Avoid all proprietary features! Unfortunately this bad habit is common. A typical example is using the all collection, which is
a proprietary feature of the Internet Explorer family. Always follow the applicable ECMAScript specification and
test the code in at least Internet Explorer, Mozilla or another Gecko-like browser, and Opera. That
way you can find differences between JavaScript and JScript implementations.

Rule three: Save bandwidth

Always try to separate the code from the page. Move it to external files so users only have to
download it once and can rely on the cache after that. You save both bandwidth and
your users’ money. This also makes the code easier to reuse and share across pages.

Rule four: Shared libraries and objects

When possible, write functions and objects so you can use them in multiple parts of your
application or project. This has several benefits:

• one place to store the code, so a change takes effect in several places at once
• easier code management
• one place for internationalization
• clearer code
• see rule three

Rule five: Comments and versioning

Comment all your code carefully. If you have no established code conventions, make your own and,
most importantly, follow them throughout. Remember that code is written once but read and fixed a thousand times.
You may not always be its user. Someone else might have to maintain it.

Good comments are invaluable, especially in shared libraries and components, when you return to them months later,
up at night trying to decipher bugs. Versioning code is invaluable too. What’s worked well for me is
keeping each shared component in its own file. With comments the code
might look like this.

/*
  @author:  Roman Pichlik
  @email:   [email redacted] 
  @date:    13.12.2002
  @version: 1.13
  @description: Metoda otevírá nové okno, jehož URL je určena argumentem foo.
  */
  function acme(foo){
    window.open(foo);
  }

For more complex constructs it helps to leave a usage example.