Never put anything you don't want to be read by visitors into files that will be directly included to a URL response. No "secrets" (e.g., account/password combinations) should ever be in such files. You need some sort of controller that has access to your secure layers and mediates the handling of sensitive information without returning any of it in the response. This can be any of the usual types, e.g., servlet, jsp, php, perl, etc.
As for non-secret info that you just prefer not to make publicly available, the best you can hope for is to obfuscate it beyond the means of the lighter-weight programmer types to figure out. You can minify the code, removing all comments and whitespace. You can use non-documentating names for methods and fields. Means you have to manage multiple files that do the same thing, since the obfuscated version is not likely to be very easily directly supportable; then, evolutionary changes have to be made to the regular version, and a new obfuscated version created ...ugh!
Frankly, it ain't worth the effort just to hide source code that will be included client-side. Look at the quality of the source code released by Yahoo in their YUI JavaScript libraries. I've done some pretty nifty stuff in JavaScript, but, for everything I've done that would be generally useful, there are alternate implementations as good or better that have been published by one of the Open Source library groups. When I find my code being recycled by others, I'm flattered. I enjoyed solving the problem - if it saves someone else some effort, cool.
Do you think that your code is worth "stealing" in some way that negatively impacts your business? If not, and there are no "secrets" in the code, let 'em look and accept the compliment that anyone was interested.