I don't think Javascript tricks work very well against motivated spammers. It is trivial to use headless WebKit client to execute Javascript and ajax requests.
I use something similar in my own site: a field in which the commenter is asked to fill a specific value. If they're running JavaScript, I fill it in for them and hide the element. So far, it works perfectly.
As other commenters have pointed out, however, this kind of defence only works against generic attacks, and defending against a targeted spam attack will always be difficult. But for the generic case, there will continue to be simple things you can do to thwart naive attacks. One that springs to mind is to introduce a scripted timing element. A spam bot won't wait a minute before submitting, but a user should at least have read the post they're commenting on.
But running javascript multiplies their processing costs substantially and it also means that at that point their costs can be driven up far higher simply by making the computation required to post higher - it doesn't take much - say a few hundred milliseconds of hash calculation on posting - to suddenly tie up a lot of resources for someone trying to spam as many people as they can for as few resources as possible.
For any spammer that has softer targets it makes little to no sense to bother.