Because there is no public record / log of how Nintex's Javascript changes between versions, they are going to have to test and see what errors (if any) they encounter. You even have to do this between upgrades on the same year platform.

Kinda unfortunate, but it's the only way I've ever discovered of finding changes between versions / platforms. 

Thanks. I've worked with Nintex Forms 2013 in the past. And one of the posts did mention that JS was introduced in Nintex Forms 2010 as of version 1.5.1 (I think), the above question came to mind. But it seems I'll (or actually a colleague) will have to figure that out himself.

Also just to add a little more info. the Syntax of js doesn't really change (though *available* syntax and certain methods can only be used in certain browsers, IE being the worst of them because it's no longer updated).

I recommend if at all possible, set up a single server Development SharePoint with Nintex running on a Dev License. if you're on the base support package you should have access to at least 1 dev license, and if you (or your customer) is on the more premium support package then I believe they can get as many dev licenses as they want. At least then they can see how the upgrade will work without it being "live" and breaking things in real time. 

Once things are good on the Dev side, then you can just choose to just copy WFs / Forms from that environment to the production, or from 2010 to whatever. 

Another benefit to having a Dev environment is that any updates that need to be done to the environment (from Nintex) can be done to that server FIRST to see if it breaks anything! It's a HUGE HELP because having your production go down from custom JS, suuuuucks!

Good luck in this endeavor! 

@MegaJerk, thank you. As for the last.. believe me I had my fair share of JS no longer working due to a Forms update... and that was in a Dev, Acceptance and Production street 🙄

As for the JS syntax I actually refer to the specific (proper) enclosure where one has to put the actual code snippets:

NWF$(document).ready(function() {

});

Ahh yeah that won't change, but I would recommend using: 

or 

As they both run at the very end when the Form has had all of its Controls created and their initial Rules / Positions processed, with RegisterBeforeFillerVisible firing just before the user could see the form, and RegisterAfterReady firing immediately upon the form becoming visible / usable to the user.

However, that's just my own preference for keeping things in order. NWF$(document).ready(function(){}); will absolutely still work though. 

(for more reading on the subject, see: https://community.nintex.com/t5/Community-blogs/The-Big-Event-A-Closer-Look-At-Nintex-Form-Events/ba-p/79521 specifically the "Order of Operations" section)

Yup,

Javascript syntax wouldn't change.

If you want to use jQuery syntax; lookup the jQuery version used in that Nintex build and all the syntax would be applicable here too.

But the class names / ids  belonging to controls and containers might. This is a problem. The other problem is you wouldn't really know about this unless you were proactively looking for it.

Good luck