Like blue_cowdawg, I'm a little confused about your premise, and I would like to understand it better.

users are encouraged to fill in a form with a varying number of fields

I understand "a field on an html form" as being a particular, distinct input element (type-in, radiobutton, etc), so I can't figure out how a form can have a varying number of fields when javascript is disabled. If you meant something else, could you please explain?

- all of the fields have the same basic premise(being an answer to a question),

Combining this with the "variable number" issue, what does this imply?

1. A given question can have one or more answers, or
2. There can be a variable number of questions, at the user's discretion, each having one answer, or
3. The user can add questions and have multiple answers on any given question.

Personally, I would expect a good solution to be different depending on which of those three describes the problem. (But there might be a suitable abstraction that I'm not seeing.)

Users are able to dynamically add fields(which would also mean dynamically naming them)

This sort of reiterates the two preceding questions. Does it imply dynamically adding the form input methods, whether or not javascript is enabled? And, does it imply that the user is adding questions, or extra answers to a given question, or both?

Assuming, as andyford does, that non-javascript users need a round-trip transaction with the server each time they add a new input element to the form, managing the naming seems like a trivial issue. To allow the javascript-enabled users to "economize" on all that back-and-forth traffic, the first problem (seemingly trivial) would simply be to make sure that the javascript uses the same strategy as the server-side cgi script when assigning names to newly added fields, so that the end result is the same no matter what sort of user is involved.

In either case, it seems like the more challenging issues revolve around how to make all this coherent to the users, so they understand what is expected of them. After that, there might be a strategy question about how to organize the code to reduce the maintenance pains that are bound to arise from having two implementations (with and without javascript) for "the same thing".

Hmm. That makes me wonder... how hard would it be to write a perl module for creating (some portion of) a web form, such that a perl function could be written to translate that module's code into equivalent, working javascript? (Or maybe there's some way of specifying a form layout, such that it can be used to automatically generate both perl code and javascript code to implement it?)