Hidden input form variables are an obvious choice. There is already logic on most web application platforms including ASP.NET to handle the encoding, and the DOM will unencode it (somehow saying “decode” doesn’t sound right) when you retrieve it using something like document.getElementById("myformvariable").value.
The performance risk here is that while you are simply using the form variable as a convenient way of sending some data from the server down to the browser, the browser doesn’t know that. It thinks that the form data is actually needed for the next request and dutifully sends it back up to the server. If you are sending a lot of data (like the information used in a table), it can really hurt performance. If you look in a tool like HttpWatch, you may see this as an unusually large request size and a long transmission time:
If you look at the example above, you will see that the request actually sent more data than was received. You also see that almost a third of the time was spent just sending up the request to the client (the bright green). Beyond the fact that you are sending unnecessary data up, there are two factors that exacerbate the problem:
1. Many user’s internet connections have much faster download speeds than upload speeds. While it may be quick to send the data down, sending the same data back up is a lot slower
2. Upstream data is not compressed by the browser. While you can gzip the contents sent from the server, requests from the client just come in plain text. This is why in the example above, the postback is actually larger than the subsequent response
Here is the same request with this additional line:
As you can see, the amount of data sent is now tiny, and the bright green of send time is almost invisible. Problem solved!