No JS obfuscator is worth the money and sweat to use them.
So, I'd say no, you can't really protect it, and don't bother spending cash on paid obfuscators (if you want to waste time, feel free to use the free ones out there, though they're barely worth your time too). Just use a good minifier / compressor / compiler to reduce the pay load. It will already make it harder to read, but not longer to run as will a lot of obfuscators. And it's still less readable to make it slightly more annoying to read and discourage some.
Also, when distributing a client, you're not really protecting yourself that much either. Disassemblers exist and knowledgeable software engineers who know how to use them are legion. Don't rely on obfuscation / obscurity for security, and don't consider a client a trade secret.
You could obfuscate the code, making it harder to understand, with a minifier such as the yui-compressor. Though its purpose is to compress the code so that the cost of bandwidth can be cut down or if you are concerned for having it load fast enough for your users.
By the way, don't worry, others will try to steal your site...
We found through a Google Alert that a shady chinese site completely ripped the site for their own (not even replacing the logo). Apparently they tried to set up their own store. The problem was that they didn't have the graphical assets that our backend provided. Thus they clearly haven't had any use other than to show off on "hey, look what we can do".
For years we've seen several freelancer.com ads where we were referred to which didn't seem to pan out, probably due to the ridiculously proposed budgets, short time schedules and poor description of what they want to do with it. For some reason the people who put these ads up have no idea how incredibly complex the business behind the website really is.
Sometimes people are really lazy: One time we've got a call from a company who wanted to know who designed our website. Apparently some design agency was using us as reference and the problem is that we did it all in-house.
"Protected"? No. "Inconvenient"? Yes. (Just as with binary.)
At a certain level, no popular operating systems (yet) can prevent a sufficiently motivated actor from recovering the in-memory representation of your program and reverse-engineering it. So the "protection" is only relative to the value of your code to another.
If you need lots of security on your client side code then your doing something wrong. You should be doing your complex logic and validating inputs on the server side.
On a side note, its also worth mentioning that its also trivial in most languages to get from compiled code to human readable code. There are techniques to make it harder but none of them is perfect.
..because they can implement your app on their own server, and use your back-end resources to power their site. Many client-side apps store an appKey that gives them access to the backend. That's how the server knows it's an authorized client.
Worse, I don't want them to be able to modify my client-app, such that they can clone my site, and fool users into logging into my site, while also submitting the user's password to their own database as a harvesting mechanism.
Also, imagine I offer a free web app/service .. another site downloads the client-app, and modifies it such that they charge for access, handling billing/payment collection on their own server, but otherwise relying upon the API services on my server to provide the backend to their webApp offering (that I created).
At least with the code minified, it is unlikely that they can easily edit the client-app to charge people money, or clone my site and harvest passwords, etc.
protected by gnat Feb 22 '17 at 22:39
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?