JS code generation to avoid de facto open-sourcing my code?

Question

I want to build a small library based on Raphael.JS for work, and none of us particularly like the idea of open sourcing our code. How insane would it be to write all the logic in Python and have it generate hardcoded JS for each "drawing", as a function of the input data? I know this could increase the size of the downloaded JS (especially if it involves unrolling loops), but our code would stay proprietary; no competitor would have the same capability as us the day after we release it.

Are there any other downsides than increased JS size? Can you guys talk me out of doing this?

Answer 1

This is a standard technique called obsfucation. There are solutions already available, some free:

http://www.google.com/search?q=javascript+obfuscator

Typically they don't introduce another language unnecessarily. Nor do they have to make the code larger, they may make it smaller.

Based on your comment, I detect two orthogonal concerns:

1. Write your code in Python to avoid having to write JS,
2. Obsfucate in some way that is better than all the existing JS-to-JS obsfucators.

The first one sounds like a false economy. Invest in learning how to use JS, and it will repay itself, based on the obvious trends in the software industry. There's no harm in learning and using more than one language.

The second one sounds ambitious - good luck. Seriously! If you have time to spend on that problem, who knows? Maybe you'll think of something that none of the other people working on it have thought of. It does happen sometimes.

You want to solve the same problem that obsfucation attempts to solve - to make your code executable but not understandable. Compilation from one language to another sometimes solves this problem as a byproduct of going from high-level to low-level representation.

However, Python and JS are both very high-level languages. You do not need to use a compiler to raise the level of the target language. JS is high-level enough already. So this is why I keep saying that you need obsfucation, even if you have an idea that you could get it by implementing compilation.

It is probably possible (maybe easiest) to write a compiler from Python to JS that does not perform much obsfucation, so the end result happens to be directly reusable and understandable. To get the side-effect of obsfucation that occurs naturally in (say) C-to-assembler compilation, you would need to target JS as if it was a low-level virtual machine, avoiding high-level constructs. This might slow down your program to a crawl, as effectively the obsfucation would need to be expensively reversed at runtime. So you will probably need to learn from the techniques used in obsfucation to ensure you get good results.

But another concern I glossed over is: you want to stay ahead of your competitors. If you devoted your time to solving the obsfucation problem (by whatever method), while your competitors concentrate on writing great interactive widgets in JS with Raphael, I know who I'd bet my money on to stay ahead.

Answer 2

If you're unrolling loops, inlining function calls, etc, you might also come up with the problem of increased parsing time for the JS code. Also, it will be way harder to debug.

If it is an option, I would go with server-side drawing of the images, Flash, Silverlight or something else of the kind.

Answer 3

You can never fully hide your client side code. If the browser can get to it human eyes can pry.

You can try things like this. I have never used it but it was a quick Google search away. There are bound to be more out there.