Which is better, js arrays or hidden input tag fields?

[Randell D.]

Folks,

I have a large amount of values to store (we're talking tens, if not
hundreds of bytes). I need this for a client side application - ignore
the security consequences for the moment - however my question is, which
is more performance effective, or easier on a clients resources?

I mean - if I have several <input type=hidden> tags with my values that
I can reference, would this have a greater overhead then, for example,
having an ten arrays with a hundred elements with an average element
length of say, ten characters?

I don't know how to measure this hence why I'm throwing the question out
there to someone with a bit more javascript on their shoulders then my
six months plus...

all help - via the newsgroup - so all can learn, would be appreciated,
thanks,

randelld

 

[Lee]

Randell D. said:

Folks,

I have a large amount of values to store (we're talking tens, if not
hundreds of bytes). I need this for a client side application - ignore
the security consequences for the moment - however my question is, which
is more performance effective, or easier on a clients resources?

I mean - if I have several <input type=hidden> tags with my values that
I can reference, would this have a greater overhead then, for example,
having an ten arrays with a hundred elements with an average element
length of say, ten characters?

Using Javascript arrays is much more efficient, both in run time and
in the amount of text to download. As far as I have been able to tell,
the only reason that some people use hidden form fields to pass data
to a page is because they don't know any better.

By the way "hundreds of bytes" is tiny.
The data that you describe is about 10k, which is still small.
That's about the size of the Google logo image.

If there are security consequences, you should not ignore them,
even for the moment. Don't expect to be able to prevent the
users from seeing anything that you send to their browser.

 

[Christopher Benson-Manica]

Using Javascript arrays is much more efficient, both in run time and
in the amount of text to download. As far as I have been able to tell,
the only reason that some people use hidden form fields to pass data
to a page is because they don't know any better.

As someone who helps maintain pages that make extensive use of hidden
form fields that are populated with script before the form is
submitted, I'm interested in hearing about the alternative

 

[Lee]

Christopher Benson-Manica said:

As someone who helps maintain pages that make extensive use of hidden
form fields that are populated with script before the form is
submitted, I'm interested in hearing about the alternative

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"
};

 

[Grant Wagner]

As someone who helps maintain pages that make extensive use of hidden
form fields that are populated with script before the form is
submitted, I'm interested in hearing about the alternative

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.

 

[Mick White]

Grant Wagner wrote:
[snip]

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) { ... }
or:
while(ii--){...}


instead of:

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

[snip]

Mick

 

[Grant Wagner]

Grant Wagner wrote:
[snip]

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) { ... }

or:
while(ii--){...}

Indeed. Although I've avoided that particular optimization because:

while (ii--) {
// ...
ii = -1;
}

would miss 0 and keep right on going until ii reached...
Number.NEGATIVE_INFINITY? No, I think Number.NaN? I'm not even sure, but
it would probably take a long time to get there, and would most likely
generate a number of syntax errors along the way.

It's probably an unrealistic concern in carefully authored code, but I
figure people reading my code will have enough trouble figuring out what
I'm doing, I don't need to be any more cryptic .

 

[Randy Webb]

Grant Wagner wrote:
[snip]

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) { ... }

or:
while(ii--){...}

Indeed. Although I've avoided that particular optimization because:

while (ii--) {
// ...
ii = -1;
}

would miss 0 and keep right on going until ii reached...

-2 would be as negative as ii could get since you are resetting it each
iteration, unless the ii = -1 is in an if() branch (or while).

 

[Randell D.]

Randell D. said:



Using Javascript arrays is much more efficient, both in run time and
in the amount of text to download. As far as I have been able to tell,
the only reason that some people use hidden form fields to pass data
to a page is because they don't know any better.

By the way "hundreds of bytes" is tiny.
The data that you describe is about 10k, which is still small.
That's about the size of the Google logo image.

If there are security consequences, you should not ignore them,
even for the moment. Don't expect to be able to prevent the
users from seeing anything that you send to their browser.

Many thanks for that - I agree with your arguements - In addition, there
is one extra advantage of using a js array over hidden fields that I
just thought off... If my array is in an external javascript file, and
its downloaded to the client, then it will be in the users cache -
Future requests to download the same array file should in theory mean
that its read from the cache as opposed to over the wire.

I'll follow the route of arrays - I think it is better...

And the data will run on an intranet - I will have a sanity check server
side to check nobody has tampered with the data but because I know my
userbase I don't see it a problem in this case..

Cheers
Randell D.

 

[Grant Wagner]

Grant Wagner wrote:
[snip]

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) { ... }

or:
while(ii--){...}

Indeed. Although I've avoided that particular optimization because:

while (ii--) {
// ...
ii = -1;
}

would miss 0 and keep right on going until ii reached...

-2 would be as negative as ii could get since you are resetting it
each iteration, unless the ii = -1 is in an if() branch (or while).

Fine, I didn't provide a complete, clear and consise example. So here:

var ii = 10;
while (ii--) {
document.write(ii + '<br>');
if (ii == 0) ii--;
}

As you can see, a negative value of -ii- is not interpreted as -false-,
so the loop continues to run until -ii- is... ?

The reasoning is the same as why you do not write:

for (var ii = 0; ii != 10; ++ii) { ... }

and instead write:

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

This reduces the risk of the loop counter inadvertantly passing over 10
without ever being 10. while (ii--) exhibits this same risk (of passing
over 0 without ever being 0).