Webmaster Forum / HTML, CSS, Scripts / JavaScript / January 2005

Christopher Benson-Manica said:

Hidden form fields are good for passing data to the server-side code
that is going to process the form, but if you're passing data to be
used by client-side code, it's simpler to just write Javascript into
the page.  So instead of generating code like:

<input type="hidden" name="alpha" value="a1">
<input type="hidden" name="beta" value="23">

You would generate (in your <script> block):

 var alpha="a1";
 var beta="23";

or create an Object:

 var formData = { alpha: "a1",
                  beta:  "23"
                };

He is referring to passing data _to_ a page, not from one page to
another.

Basically, if you want dynamic server-side values to be manipulated from
client-side JavaScript you have two options:

<script type="text/javascript">
var myArray = [
   <%= serverSideArray.join(',\n') %>
];
</script>

or

<!-- this could be made more efficient by putting
all array elements into a single hidden input with
a unique delimiter, then splitting the value on the
client -->
<% for (var ii = 0; ii < serverSideArray.length; ++ii) { %>
<input type="hidden"
name="element<%= ii %>"
value="<%= serverSideArray[ii] %>">
<% } %>

Both will make the -serverSideArray- values accessible from client-side
JavaScript. There are some very good reasons why you may wish to use the
second method however, one of them being that you need those values on
the _next_ page (after form submission).

Of course, if you need those values on the server on form's target, and
they originally came from the server, it might be more efficient to
simply retrieve them or calculate them again on the server when needed.

As for the original poster's question regarding efficiency. If you're
asking that question, you're using the wrong tool.

<url: http://blogs.msdn.com/ericlippert/archive/2003/11/18/53388.aspx />

"High performance is unimportant -- as long as the page doesn't appear
to hang, its fast enough."

"Do not rely on "tips and tricks" for performance.  People will tell you
"declared variables are faster than undeclared variables" and "modulus
is slower than bit shift" and all kinds of nonsense.  Ignore them.
That's like mowing your lawn by going after random blades of grass with
nail scissors.  You need to find the WORST thing, and fix it first.
That means measuring."

<url: http://www.codinghorror.com/blog/archives/000185.html />

"Arguments about which method results in code that is easier to read and
easier to maintain will be gladly entertained. Arguments about speed
will not. Stop micro-optimizing and start macro-optimizing: per Lippert,
code that makes sense is code which can be analyzed and maintained, and
that makes it performant."

Please note I'm guilty of micro-optimizing myself. I often write loops
in which iteration order doesn't matter as:

var ii = length;
while (ii-- > 0) { ... }

instead of:

for (var ii = 0; ii < length; ++ii) { ... }

because the first one is "faster". Please understand, the time it takes
to _do something_ inside the loop is probably going to far outweigh any
speed gains achieved by reversing the direction of the loop. However,
I'm old and set in my ways, so I will continue to stick to this design
choice.