Javascript best practices - Using server-side values

Question

For the past few years I have always used a client-side hidden <input> field to store a server-side value and use it in Javascript land.

For example, let's say I need an Ajax timeout value from my app configuration.

I'd probably store it like this in my JSP:

<input type="hidden" id="ajaxTimeout" value="${serverValue}" />

and then use it like this where my AJAX call lived in an external file:

$("#ajaxTimeout").val()

I was having a discussion about this today and it was suggested that it is best practice to store values which are only going to be used by Javascript within HTML <meta> tags.
Does this matter? Is there a preferred way to obtain server-side information which is solely to be used in Javascript?
My understanding is that if the hidden input field is not part of a form then it is safe enough to use to store value as it won't be attached to any requests. Having said that, I've always thought this was indeed a bit of a hack.

Thoughts?

::EDIT::
Two fantastic answers:

• Use objects literals for general in-page data that is not tied to any particular DOM element.
• Use data attributes to store custom data tied to DOM elements: http://www.w3.org/TR/2010/WD-html5-20101019/elements.html#attr-data

Answer 1

We personally do something like this:

var options = {
    selector: '#divId',
    serverSideVariableHere: <%=AspNetProperty %>,
    anotherServerSideVariableHere: <%=AspNetPropertyTwo %>
}
var viewModel = new KnockoutViewModel(options);
ko.applyBindings(viewModel, $(options.selector)[0]);

This is simply an example using KnockOut JS, but this idea can be expanded to any JavaScript library you choose to use (or not ;))

We then pass these options to whatever use them, such as Knockout ViewModels, or whatever. That way our JavaScript remains testable and we can pass in whatever values we want to our tests.

Answer 2

In addition to the plain old object literal method given in other answers, if the value you want to pass to the client is about a specific DOM element (or there is a DOM element that represents the logical object that the value is about), you can put the value in a data attribute:

<div id="videoplayer" data-startplayingat="1:02">HTML Content</div>

This is accessible as an entire attribute, data-startplayingat, or in modern browsers there is the dataset attribute. jQuery syntax is $('#videoplayer').data('startplayingat').

The official W3C spec on data attributes explains all this.

Here are a few interesting highlights:

• The name must not use upper case letters, and must be XML compatible.
• The dataset attribute converts dashes, such that a name like start-playing will become startPlaying.

One potential drawback for the object literal method (which I like and have used myself) is that if you want the object in a .js file, then normally static javascript files have to be run through your dynamic parser--which will cause a potentially small (but still present) performance loss. Putting the object declaration into a <script> tag in an HTML file works around this, but then you can have script load order issues to deal with.

Answer 3

Using meta tag for something other than browser meta-"instructions" is no less of a hack IMO.

I would consider storing JavaScript data where it belongs - in JavaScript, using JavaScript object literals.

Answer 4

I strongly prefer JSON snippets in data- attributes. This lets you scope them to the related HTML element, and you don't pollute your Javascript global namespace, or have to generate additional code to handle namespacing otherwise. Coupled with a JSON serialiser on the server side this minimises having to manually escape anything in your values.

(Also I have a Thing™ against <script> tags with content in general. View and logic separation and all that.)