If all the functions are equal with equal parameters, or equal ( or derivable ) functions where the parameters can be easily derived programatically per link, i.e. via setting some dummy property on the link and using it to generate or lookup the function parameters. Otherwise I can invisage an equally huge JS file... Plus, it would take some noticable, although not restrictive, post-load time to dynamically set the onload property for 6000 links..

But in return of all this you get flexibility, the ability to change the logic without sifting through 6000 lines of your markup. Plus the load times would be less than or at the most equal to the time taken to set onclick on 6000 links by hardcoding them.

I guess this is one of those choices the OP would have to make based on his requirements.

>>I guess this is one of those choices the OP would have to make based on his requirements.

Pretty much.

>> But in return of all this you get flexibility, the ability to change the logic without sifting through 6000 lines of your markup. Plus the load times would be less than or at the most equal to the time taken to set onclick on 6000 links by hardcoding them.

I would debate that using JS to generate onclick handlers could save much on download time and configurabilty unless the functions and their parameters can be derived automatically with a minimum of link-specific information hardcoded anywhere in either the JS or HTML. i.e, for extreme example cases:

( hardcoded )
= association between a's and click handlers is hardest, function name can't be changed easily, most flexible; because different functions can be called.

( changing 'c' classed 'a' elements to call an onclick function with a parameter equal to the a's id )
=association between a's and click handlers is medium, function name can be changed in JS, but id's have to be changed in HTML and function name can't be changed ( unless more than one class is used ), there is a noteable decrease in HTML size, but at a runtime cost compared to hardcoding. Small JS file also. Might be optimum, might not. Especially when considering that you can't legally put all characters in an 'id' attribute.. perhaps would be better to use id's as a lookup into a collection/dictionary, but then the size of the JS + HTML exceeds the size of the hardcoded HTML.

( changing 'c' classed 'a' elements to call an onclick function with a parameter pulled from an array , based on the order of the classed a's ( very messy ) )

=association between a's and click handlers is weak, but highly confusing to change anything. Very little benefit in the smaller HTML, because the JS becomes massive. Not recommended.

Of course... if your some_func( ) really takes no parameters, and is always the same call, ( aside from the obvious question; why have 6000 of them?? ) generating the onclick handler from JS will always save alot of download bandwidth..

thanks all for your replies.

i have tested both methods and there is very little load time difference between each case. onclick is generally faster but i find myself having to add the
anyway to stop to postback

BUT

after some soul searching found this why not to use href="javascript"

and i qoute
this pretty much summed up what i have got to do. Considering this web app is built for IE only on a local intranet i have tried the method suggested above to append the ONCLICK with return false; and have had no troubles.

dont ask me why IE only, suffice to say the companies i am writing for are local councils and all have stressed they will never use any other browser except IE (which means they will never use a decent browser) but thanks again to all who commented