Earlier, I suggested to use Code Downloading in order to reduce the size of AJAX application. I left the term undescribed, but I will change this now:
As JavaScript is an interpreted language, it is quite easy to load additional code, even after the application has “started”. This means that only code absolutely necessary to display the app has to be loaded initially.
In the following example, we define a function test() in the context of an object App. Then via Ajax the original code is overwritten. Naturally also new functions can be loaded.
The downloaded code is eval’uated, i.e. it is executed. You cannot only execute statements but also define variables and functions.
Source of load.js:
App.test = function() {
alert("additional code loaded");
}
I have set up an example implementation of this.
This allows more flexibility for larger apps. My “negative” example, Kiko, could use this method to enormously reduce the amount of code to be loaded initially.
I alse see the possibility to only store encrypted Javascript source code on the server and decrypt it on-the-fly (of course also this would only prevent script kiddies from stealing, but it could challenge some hacker a bit more).
Hi Alex, it sounds like I guessed right wrt “code downloading”. FYI Here’s demo based on an alternative approach – changing the head. The main part is:
if (self.uploadMessages) { // Already exists
return;
}
var head = document.getElementsByTagName(“head”)[0];
script = document.createElement(‘script’);
script.type = ‘text/javascript’;
script.src = “upload.js”;
head.appendChild(script)
eval() is probably better from a memory perspective, this is just an interesting alternative.
Regarding encryption, Richard Schwartz started a conversation a while ago about JS decryption to protect data on the host side – Host-Proof Hosting. Hadn’t considered it from a JS perspective because – as you allude to – it’s easy enough to reveal the JS. But given the lengths people go to in order to protect their scripts, it’s an interesting idea.
Yes, I’m sure my technique using Blowfish could be used to give some protection to downloaded code — but since the client-side would have to know the key to decrypt, the protection would be minimal. Script-kiddie protetion, as alluded to, at best. The other issue with using Blowfish is that the crypto-text is binary, so it would normally be base64 encoded after encyrption — which expands the size of the download. So you might want to compress and then encrypt — hoping to break even or maybe even save a few bits, at the cost of some extra client-side cycles. And really, the compression alone might provide just as much script-kiddie protection as the crypto
-rich
Be careful when using XHR for downloading js code. Firefox does not cache any data when using XHR and therefore the old school method (as explained by Michael above) is usually better.