In general, JavaScript is highly portable. However, it is dubious as to whether a server-side script would be useful on the client side, so some measure of discretion is required when talking about portability. Even so, it is likely that many useful functions would work in different contexts although the way they are used may be different.

Portability of code needs to be considered at the outset of any development project. A script is portable to the extent that it can be used on a variety of platforms.

Generally, code in a function is more portable than an entire script-driven application. You might reuse functional blocks of code from one project to another. JavaScript facilitates this reuse due to its semi-object-oriented nature.

If you adhere strictly to the ECMAScript standard, then your script may port between compliant implementations with the minimum of difficulty.

Note that portability does not imply that a script you design to work client side is guaranteed to work meaningfully on the server side. There is the small matter of fitness for purpose and suitability.

However, it is not unreasonable to expect a script be able to run identically in all versions and flavors of web browsers. Realistically though, this is very difficult to accomplish because of the browser developers having added proprietary extensions to their implementations. They also increase the difficulty due to the amount of incomplete and incorrect support for standardized behavior. Furthermore the standard is ambiguous in a few areas leading to functional interpretations, which can vary from browser to browser.

For example, both MSIE and Netscape can scroll the contents of a window or frame. MSIE will scroll under script control whether the window has a scroll bar or not. Netscape Navigator will only scroll if a scroll bar is flagged true and is actually present.

Furthermore when scrolling is possible (on Netscape it can be accomplished without scroll bars by using layers), each browser scrolls in the opposite direction, as the scroll value is incremented.

Do not assume that expressions will evaluate the operands in the order of presentation. There are various ways to tokenize and interpret expressions and they can evaluate individual items in different sequence order, or in some cases may omit to evaluate an operand, when an early prediction of the outcome is possible.

Be wary of using non uniform character values that appear to display a certain character, which is not the correct one, defined in the Unicode character set. Rather, escape the character either with a Unicode escape or if it is appropriate for the context as an HTML character entity.

Be careful with quotes and escaping of them. If you escape a single quote using the HTML character entity, then some web browsers will un-escape the source text before interpretation. This breaks:

myString = 'some text with a ' single quote';

the HTML character entity is decoded too soon, by the browser as the page is read into its memory cache. Then the script is interpreted, and the interpreter sees this:

myString = 'some text with a ' single quote';

The additional quote terminates the string too soon and the remainder is interpreted as code. This can have very unpredictable consequences. The apostrophe should be escaped like this:

myString = 'some text with a \' single quote';

Inevitably, there will be occasions where you need to factor your script to cope with machine dependant behavior. You should collect the machine dependant code into clearly identified functions. You can use the eval() function to great effect here by detecting the name of the browser and algorithmically generating the name of a function to call which you can then invoke via an eval().

Cross-references:

Wrox Instant JavaScript - page - 11