Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I want to make a JavaScript application that's not open source, and thus I wish to learn how to can obfuscate my JS code? Is this possible?
Obfuscation:
Try YUI Compressor. It's a very popular tool, built, enhanced and maintained by the Yahoo UI team.
You may also use:
Google Closure Compiler
UglifyJS
UPDATE: This question was originally asked on 2008, and The mentioned technologies are deprecated. you can use:
terser - more information in web.dev.
Private String Data:
Keeping string values private is a different concern, and obfuscation won't really be of much benefit. Of course, by packaging up your source into a garbled, minified mess, you have a light version of security through obscurity. Most of the time, it's your user who is viewing the source, and the string values on the client are intended for their use, so that sort of private string value isn't often necessary.
If you really had a value that you never wanted a user to see, you would have a couple of options. First, you could do some kind of encryption, which is decrypted at page load. That would probably be one of the most secure options, but also a lot of work which may be unnecessary. You could probably base64 encode some string values, and that would be easier.. but someone who really wanted those string values could easily decode them. Encryption is the only way to truly prevent anyone from accessing your data, and most people find that to be more security than they need.
Sidenote:
Obfuscation in Javascript has been known to cause some bugs. The obfuscators are getting a little better about it, but many outfits decide that they see enough benefit from minifying and gzipping, and the added savings of obfuscation isn't always worth the trouble. If you're trying to protect your source, maybe you'll decide that it's worth your while, just to make your code harder to read. JSMin is a good alternative.
I'm surprised no one has mentioned Google's Closure Compiler. It doesn't just minify/compress, it analyzes to find and remove unused code, and rewrites for maximum minification. It can also do type checking and will warn about syntax errors.
JQuery recently switched from YUI Compresser to Closure Compiler, and saw a "solid improvement"
Obfuscation can never really work. For anyone who really wants to get at your code, it's just a speed bump. Worse, it keeps your users from fixing bugs (and shipping the fixes back to you), and makes it harder for you to diagnose problems in the field. Its a waste of your time and money.
Talk to a lawyer about intellectual property law and what your legal options are. "Open Source" does not mean "people can read the source". Instead, Open Source is a particular licensing model granting permission to freely use and modify your code. If you don't grant such a license then people copying your code are in violation and (in most of the world) you have legal options to stop them.
The only way you can really protect your code is to not ship it. Move the important code server-side and have your public Javascript code do Ajax calls to it.
See my full answer about obfuscators here.
You can obfuscate the javascript source all you want, but it will always be reverse-engineerable just by virtue of requiring all the source code to actually run on the client machine... the best option I can think of is having all your processing done with server-side code, and all the client code javascript does is send requests for processing to the server itself. Otherwise, anyone will always be able to keep track of all operations that the code is doing.
Someone mentioned base64 to keep strings safe. This is a terrible idea. Base64 is immediately recognizable by the types of people who would want to reverse engineer your code. The first thing they'll do is unencode it and see what it is.
There are a number of JavaScript obfuscation tools that are freely available; however, I think it's important to note that it is difficult to obfuscate JavaScript to the point where it cannot be reverse-engineered.
To that end, there are several options that I've used to some degree overtime:
YUI Compressor. Yahoo!'s JavaScript compressor does a good job of condensing the code that will improve its load time. There is a small level of obfuscation that works relatively well. Essentially, Compressor will change function names, remove white space, and modify local variables. This is what I use most often. This is an open-source Java-based tool.
JSMin is a tool written by Douglas Crockford that seeks to minify your JavaScript source. In Crockford's own words, "JSMin does not obfuscate, but it does uglify." It's primary goal is to minify the size of your source for faster loading in browsers.
Free JavaScript Obfuscator. This is a web-based tool that attempts to obfuscate your code by actually encoding it. I think that the trade-offs of its form of encoding (or obfuscation) could come at the cost of filesize; however, that's a matter of personal preference.
What i would do:
A. Troll the hacker!
This is will be in the second part my fake/obfuscated secret javascript code LAUNCHER.
The one you see in the source code.
What does this code?
loads the real code
sets a custom header
posts a custom variable
var ajax=function(a,b,d,c,e,f){
e=new FormData();
for(f in d){e.append(f,d[f]);};
c=new XMLHttpRequest();
c.open('POST',a);
c.setRequestHeader("Troll1","lol");
c.onload=b;
c.send(e);
};
window.onload=function(){
ajax('Troll.php',function(){
(new Function(atob(this.response)))()
},{'Troll2':'lol'});
}
B. Obfuscate the code a little
What is that?
thats the same code as above in base64
this is not the SECRET javascript code
(new Function(atob('dmFyIGFqYXg9ZnVuY3Rpb24oYSxiLGQsYyxlLGYpe2U9bmV3IEZvcm1EYXRhKCk7Zm9yKGYgaW4gZCl7ZS5hcHBlbmQoZixkW2ZdKTt9O2M9bmV3IFhNTEh0dHBSZXF1ZXN0KCk7Yy5vcGVuKCdQT1NUJyxhKTtjLnNldFJlcXVlc3RIZWFkZXIoIlRyb2xsMSIsImxvbCIpO2Mub25sb2FkPWI7Yy5zZW5kKGUpO307d2luZG93Lm9ubG9hZD1mdW5jdGlvbigpe2FqYXgoJ1Ryb2xsLnBocCcsZnVuY3Rpb24oKXsgKG5ldyBGdW5jdGlvbihhdG9iKHRoaXMucmVzcG9uc2UpKSkoKX0seydUcm9sbDInOidsb2wnfSk7fQ==')))()
C Create a hard to display php file with the real code inside
What does this php code?
Checks for the right referrer (domain/dir/code of your launcher)
Checks for the custom HEADER
Checks for the custom POST variable
If everything is ok it will show you the right code else a fake code or ban ip, close page.. whatever.
<?php
$t1=apache_request_headers();
if(base64_encode($_SERVER['HTTP_REFERER'])=='aHR0cDovL2hlcmUuaXMvbXkvbGF1bmNoZXIuaHRtbA=='&&$_POST['Troll2']=='lol'&&$t1['Troll1']='lol'){
echo 'ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdkaXYnKSkuaW5uZXJUZXh0PSdBd2Vzb21lJzsNCg==';//here is the SECRET javascript code
}else{
echo 'd2luZG93Lm9wZW4oJycsICdfc2VsZicsICcnKTt3aW5kb3cuY2xvc2UoKTs=';
};
?>
base64 referrer = http://here.is/my/launcher.html
SECRET javascript = document.body.appendChild(document.createElement('div')).innerText='Awesome';
FAKE = window.open('', '_self', '');window.close();
Now .. if you define event handlers in the SECRET javascript it's probably accessible.. you need to define them outside with the launchcode and pointing to a nested SECRET function.
SO... is there a easy wayto get the code?
document.body.appendChild(document.createElement('div')).innerText='Awesome';
I'm not sure if this works but i'm using chrome and checked Elements,Resources,Network,Sources,Timeline,Profiles,Audits but i didn't find the line above.
note1: if u open the Troll.php url from Inspect element->network in chrome you get the fake code.
note2: the whole code is written for modern browsers. polyfill needs alot more code.
EDIT
launcher.html
<!doctype html><html><head><meta charset="utf-8"><title></title><script src="data:application/javascript;base64,KG5ldyBGdW5jdGlvbihhdG9iKCdkbUZ5SUdGcVlYZzlablZ1WTNScGIyNG9ZU3hpTEdRc1l5eGxMR1lwZTJVOWJtVjNJRVp2Y20xRVlYUmhLQ2s3Wm05eUtHWWdhVzRnWkNsN1pTNWhjSEJsYm1Rb1ppeGtXMlpkS1R0OU8yTTlibVYzSUZoTlRFaDBkSEJTWlhGMVpYTjBLQ2s3WXk1dmNHVnVLQ2RRVDFOVUp5eGhLVHRqTG5ObGRGSmxjWFZsYzNSSVpXRmtaWElvSWxSeWIyeHNNU0lzSW14dmJDSXBPMk11YjI1c2IyRmtQV0k3WXk1elpXNWtLR1VwTzMwN2QybHVaRzkzTG05dWJHOWhaRDFtZFc1amRHbHZiaWdwZTJGcVlYZ29KMVJ5YjJ4c0xuQm9jQ2NzWm5WdVkzUnBiMjRvS1hzZ0tHNWxkeUJHZFc1amRHbHZiaWhoZEc5aUtIUm9hWE11Y21WemNHOXVjMlVwS1Nrb0tYMHNleWRVY205c2JESW5PaWRzYjJ3bmZTazdmUT09JykpKSgp"></script></head><body></body></html>
Troll.php
<?php $t1=apache_request_headers();if(/*base64_encode($_SERVER['HTTP_REFERER'])=='PUT THE LAUNCHER REFERER HERE'&&*/$_POST['Troll2']=='lol'&&$t1['Troll1']='lol'){echo 'ZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVFbGVtZW50KCdkaXYnKSkuaW5uZXJUZXh0PSdBd2Vzb21lJzsNCg==';}else{echo 'd2luZG93Lm9wZW4oJycsICdfc2VsZicsICcnKTt3aW5kb3cuY2xvc2UoKTs=';}; ?>
The problem with interpreted languages, is that you send the source to get them working (unless you have a compiler to bytecode, but then again, it is quite trivial to decompile).
So, if you don't want to sacrifice performance, you can only act on variable and function names, eg. replacing them with a, b... aa, ab... or a101, a102, etc. And, of course, remove as much space/newlines as you can (that's what so called JS compressors do).
Obfuscating strings will have a performance hit, if you have to encrypt them and decrypt them in real time. Plus a JS debugger can show the final values...
Try JScrambler. I gave it a spin recently and was impressed by it.
It provides a set of templates for obfuscation with predefined settings for those who don't care much about the details and just want to get it done quickly. You can also create custom obfuscation by choosing whatever transformations/techniques you want.
Contrary to most of the other answers I suggest against YUI Compressor; you should use Google Closure.
Not much because it compresses more, but mostly because it will catch javascript errors such as a = [1,2,3,]; which make IE go haywire.
I can recommend JavaScript Utility by Patrick J. O'Neil. It can obfuscate/compact and compress and it seems to be pretty good at these. That said, I never tried integrating it in a build script of any kind.
As for obfuscating vs. minifying - I am not a big fan of the former. It makes debugging impossible (Error at line 1... "wait, there is only one line") and they always take time to unpack. But if you need to... well.
A non-open-source Javascript-based application is fairly silly. Javascript is a client-side interpreted language.. Obfuscation isn't much protection..
JS obfuscation is usually done to reduce the size of the script, rather than "protect" it. If you are in a situation where you don't want your code to be public, Javascript isn't the right language..
There are plenty of tools around, but most have the word "compressor" (or "minifier") in its name for a reason..
You can't secure client side code: just press F12 on Google Chrome, pause javascript execution and you will get all strings, even those encrypted. Beautify it and rename variables and you will get almost the original code.
If you're writing server side javascript (i.e. NodeJS) is afraid of someone hacking into your server and want to make the hacker work more difficult, giving you more time to get your access back, then use javacript compilers:
You need to use Closure Compiler on Advanced Compilation, as it's the only tool that renames all your variables, even if those are used in multiple files/modules. But it just have a problem: it only work if you write in it's coding style.
I would suggest first minify with something like YUI Compressor, and then convert all string and numbers to HEX Values using something like http://www.javascriptobfuscator.com/
With this, the code would be rendered near impossible to understand and I think at this Stage it will take more time for a Hacker to re-enact your code than actually if he re-wrote from scratch. Rewriting and Cloning is what you cant actually stop. After all we are free-people !
Try this tool Javascript Obfuscator
I used it on my HTML5 game not only it reduced it size from 950KB to 150 but also made the source code unreadable closure compilers and minifiers are reversable I personally dont know how to reverse this obfuscation.
Dean Edward's Packer is an excellent obfuscator, though it primarily obfuscates the code, not any string elements you may have within your code.
See: Online Javascript Compression Tool and select Packer (Dean Edwards) from the dropdown
I'm under the impression that some enterprises (e.g.: JackBe) put encrypted JavaScript code inside *.gif files, rather than JS files, as an additional measure of obfuscation.
I've been using Jasob for years and it is hands down the best obfuscator out there.
It has an advanced UI but is still intuitive and easy to use.
It will also handle HTML and CSS files.
The best way to use it is to prefix all of your private variables with something like an underscore, then use the sort feature to group them all together and check them off as targets for obfuscation.
Users can still view your source, but it's much more difficult to decipher when your private variables are converted from something like _sUserPreferredNickName to a.
The engine will automatically tally up the number of targeted variables and prioritize them to get the maximum compression.
I don't work for Jasob and I get nothing out of promoting them, just offering some friendly advice.
The downside is that it's not free and is a little pricey, but still worth it when stacked against alternatives - the 'free' options don't even come close.
Have you tried Bananascript? It produces highly compressed and completely unreadable code.
I am using Closure-Compiler utility for the java-script obfuscation. It minifies the code and has more options for obfuscation.
This utility is available at Google code at below URL:
Closure Tools
But now a days I am hearing much of UglifyJS. You can find various comparison between Closure Compiler and UglifyJS in which Uglify seems to be a winner.
UglifyJS: A Fast New JavaScript Compressor For Node.js That’s On Par With Closure
Soon I would give chance to UglifyJS.
As a JavaScript/HTML/CSS obfuscator/compressor you can also try Patu Digua.
You definitely should consider taking a look at Obfuscriptor.
I goes beyond the typical Javascript minifying tricks we've seen from other tools such as YUI Compressor or Google Closure.
The obfuscated code looks more like encrypted. Unlike anything I've seen before.
I've used this in the past, and it does a good job. It's not free, but you should definitely take a look.
JavaScript Obfuscator & Encoder
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I've spent the last couple days researching different arguments for and against different MVC frameworks but what's become very apparent is that there's absolutely no correct answer to this question as it's heavily dependent on a number of different factors specific to the underlying project.
The advice I am repeatedly coming across is select a framework on the following points: Ease of use, productivity, testability, community, documentation
While that's all well and good advice, I still think that there are a few more things to consider specific to the actual code-base you'll be working on.
That being said, hypothetically if you were to arrive at work one day and asked to select the "best" Javascript MVC framework for your code base to handle the entire front end of an existing product (keeping in mind that there is a current codebase and you'd want the framework to be able to handle the "transition" period as you shifted to the new framework over time), what are the factors/questions you believe would be necessary to consider to make a well informed decision? These can be factors/considerations/questions about the MVC frameworks themselves AND/OR the current code base / technologies current in use (ie. Ruby backend, other libraries currently in use, product functionality, etc).
Scalability and performance are extremely important as this product would have a fairly large volume of users.
Just due to stability and maturity of certain frameworks alone I've factored down realistic choices to Angular, Backbone + Marionette and Ember (although this one is still up in the air). Each one is a different beast by its own right and functions very differently, hence the need for my original question on what factors and questions would you ask to figure out which is the "ideal" (I use that word very loosely) choice?
Your question is probably going to be closed since it is both "too broad" and "primarily opinion based", making it not a good fit for this site.
But since I was faced with exactly this same decision not so long ago, I'll share my impressions of the three frameworks. Please also read this article (from someone more experienced than me) if you haven't already.
AngularJS
Pros: "Magically" hooks up functionality between the view and the logic and allows getting a lot done with minimal code. Frees you from having to do a lot of DOM manipulation. Easy to start off simple and build up (for the most part).
Cons: AngularJS's strong points can also be seen as its weak points - many say that it does too much with its "magic" and that this makes it hard to troubleshoot when something goes wrong. Also, the "freedom from DOM manipulation" can turn into an "obstacle from DOM manipulation". Forces you to find plugins and libraries or make your own components that "do things the Angular way" for some tasks that would otherwise be trivial. Also violates separation of concerns by forcing you to place a lot of code in your HTML.
Backbone.JS
Pros: Provides a framework for imposing order upon your code and data structures without taking over your whole site design. "Plays well with others", as #dandavis has said in the comments section above.
Cons: Doesn't provide much in the way of UI support. Requires either bolting a UI framework on top of it (such as Marionette), or doing most of the manual labor yourself.
Ember.JS:
Pros: Provides a lot of UI assistance (with the help of handlebars, which is built into Ember) without violating separation of concerns. Events are hooked up in code (in a rather clean way too). Like Backbone, provides a framework for adding rigid structure to your app.
Cons: Requires mastering a lot of different concepts and setting up a lot of moving parts. Can require a lot of code and separate pieces to accomplish relatively simple things. Assumes the use of handlebars templates rather than plain HTML (which can be a plus or a minus, depending on one's preferences).
In the end, I went with AngularJS because I happened to like all the "magic" and ease-of-use that it provides. The following also helped me rule out the two other options:
Minimal UI functionality in Backbone meant I would have to hook it up myself (which I was trying to get away from in the first place), or go off and compare/contrast a whole bunch of other frameworks to put on top of Backbone. That would have been too much of a time investment at the time.
I ruled out Ember because much of the HTML markup work was delegated to another person, and it would have been unreasonable to force that person to learn how to use handlebars templates. That was a pretty big strike against Ember for my particular case.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I need to write a GUI related javascript library. It will give my website a bit of an edge (in terms of functionality I can offer) - up until my competitors play with it long enough to figure out how to write it by themselves (or finally hack the downloaded script). I can accept the fact that it will be emulated over time - thats par for the course (its part of business). I just want to have a few months breathing space where people go "Wow - how the f*** did they do that?" - which gives me a few months of free publicity and some momentum to move onto other things.
To be clear, I am not even concerned about hard core hackers who will still hack the source - thats a losing battle not worth fighting (and in any case I accept that my code is not "so precious"). However, what I cannot bear, is the idea of effectively, simply handing over all the hard work that would have gone into the library to my competitors, by using plain javascript that anyone can download and use. If someone is going to use what I have worked on, then I sure as hell don't want to simply hand it over to them - I want them to work hard at decoding it. If they can decode it, they deserve to have the code (they'll most likely find out they could have written better code themselves - they just didn't have the business sense to put all the [plain vanilla] components in that particular order) - So, I'm not claiming that no one could have written this (which would be a preposterous claim in any case) - but rather, what I am saying is that no one (up to now) has made the functionality I am talking about, available to this particular industry - and I (thinking as an entrepreneur rather than a geek/coder), want to milk it for all its worth, while it lasts i.e until it (inevitably) gets hacked.
It is an established fact that not one website in the industry I am "attacking" has this functionality, so the value of such a library is undeniable and is not up for discussion (i.e. thats not what I'm asking here).
What I am seeking to find out are the pros and cons of obfuscating a javascript library, so that I can come to a final decision.
Two of my biggest concerns are debugging, and subtle errors that may be introduced by the obfuscator.
I would like to know:
How can I manage those risks (being able to debug faulty code, ensuring/minimizing against obfuscation errors)
Are there any good quality industry standard obfuscators you can recommend (preferably something you use yourself).
What are your experiences of using obfuscated code in a production environment?
If they can decode it, they deserve to have the code (they'll most likely find out they could have written better code themselves - they just didn't have the business sense to put all the [plain vanilla] components in that particular order).
So really, you're trying to solve a business issue with technical measures.
Anybody worth his salt as a Javascript programmer should be able to recreate whatever you do pretty easily by just looking at the product itself, no code needed. It's not like you're inventing some new magical thing never seen before, you're just putting pieces together in a new way, as you admit yourself. It's just Javascript.
Even if you obfuscate the script, it'll still run as-is, competitors could just take it and run with it. A few customizations shouldn't be too hard even with obfuscated code.
In your niche business, you'll probably notice pretty quickly if somebody "stole" your script. If that happens, it's a legal issue. If your competitors want to be in the clear legally, they'll have to rewrite the script from scratch anyway, which will automatically buy you some time.
If your competitors are not technically able to copy your product without outright stealing the code, it won't make a difference whether the code is in the clear or obfuscated.
While you can go down the long, perilous road of obfuscators, you generally don't see them used on real, production applications for the simple reason that they don't really do much. You'll notice that Google apps, which is really a whole heap of proprietary and very valuable JavaScript when you get down to it, is only really minimized and not obfuscated, though the way minimizers work now, they are as good as obfuscated. You really need to know what you're doing to extract the meaning from them, but the determined ones will succeed.
The other problem is that obfuscated code must work, and if it works, people can just rip it wholesale, not understanding much of it, and use it as they see fit in that form. Sure, they can't modify it directly, but it isn't hard to layer on some patches that re-implement parts they don't like without having to get in too deep. That is simply the nature of JavaScript.
The reason Google and the like aren't suffering from a rash of cut-and-paste competitors is because the JavaScript is only part of the package. In order to have any degree of control over how and where these things are used, a large component needs to be server-based. The good news is you can leverage things like Node.js to make it fairly easy to split client and server code without having to re-implement parts in a completely different language.
What you might want to investigate is not so much obfuscating, but splitting up your application into parts that can be loaded on-demand from some kind of service, and as these parts can be highly inter-dependent and mostly non-functional without this core server, you can have a larger degree of control over when and where this library is used.
You can see elements of this in how Google is moving to a meta-library which simply serves as a loader for their other libraries. This is a step towards unifying the load calls for Google Apps, Google AdSense, Google Maps, Google Adwords and so forth.
If you wanted to be a little clever, you can be like Google Maps and add a poison pill your JavaScript libraries as they are served dynamically so that they only operate in a particular subdomain. This requires generating them on an as-needed basis, and while it can always be removed with sufficient expertise, it prevents wholesale copy-paste usage of your JavaScript files. To insert a clever call that validates document.href is not hard, and to find all these instances in an aggressively minimized file would be especially infuriating and probably not worth the effort.
Javascript obfuscation facts:
No one can offer a 100% crack free javascript obfuscation. This means that with time and knowledge every obfuscation can be "undone".
Minify != obfuscation: When you minify your objective is: reduce code size. Minified code looks completly different and its much more complex to read (hint:jsbeautifier.com). Obfucation has a completly different objective: to protect the code. The transformations used try to protect Obfuscated code from debugging and eavesdropping. Obfuscation can even produce a even bigger version of the original code which is completely contrary to the objectives of minification.
Obfuscation != encryption - This one is obvious but its common mistake people make.
Obfuscation should make debugging much much harder, its one of it objectives. So if it is done correctly you can expect to loose a lot of time trying to debug obfuscated code.That said, if it is done correctly the introduction of new errors is a rare issue and you can easily find if it is an obfuscation error by temporarily replacing the code with non obfuscated code.
Obfuscation is NOT a waste of time - Its a tool. If used correctly you can make others waste lots of time ;)
Javascript obfuscation fiction: ( I will skip this section ;) )
Answer to Q2 - Sugested obfuscation tools:
For an extensive list of javascript obfuscator: malwareguru.org. My personal choice is jscrambler.com.
Answer to Q3 - experiences of using obfuscated code
To date no new bugs introduced by obfuscation
Much better client retention. They must come to the source to get the source;)
Occasional false positives reported by some anti-virus tools. Can be tested before deploying any new code using a tool like Virustotal.com
Standard answer to obfuscation questions: Is using an obfuscator enough to secure my JavaScript code?
IMO, it's a waste of time. If the competitors can understand your code in the clear (assuming it's anything over a few thousand lines...), they should have no trouble deobfuscating it.
How can I manage those risks (being
able to debug faulty code,
ensuring/minimizing against
obfuscation errors)
Obfuscation will cause more bugs, you can manage them by spending the time to debug them. It's up to the person who wrote the obfuscation (be it you or someone else), ultimately it will just waste lots of time.
What are your experiences of using
obfuscated code in a production
environment?
Being completely bypassed by side channel attacks, replay attacks, etc.
Bugs.
Google's Closure Complier obfuscates your code after you finish writing it. That is, write your code, run it through the compiler, and publish the optimized (and obfuscated) js.
You do need to be careful if your using external js that interfaces with the lib though because it changes the names of your objects so you can't tell what is what.
Automatic full-code obfuscation is so far only available in the Closure Compiler's Advanced mode.
Code compiled with Closure Advanced mode is almost impossible to reverse-engineer, even passing through a beautifier, as the entire code base (includinhg the library) is obfuscated. It is also 25% small on average.
JavaScript code that is merely minified (YUI Compressor, Uglify etc.) is easy to reverse-engineer after passing through a beautifier.
If you use a JavaScript library, consider Dojo Toolkit which is compatible (after minor modifications) with the Closure Compiler's Advanced mode compilation.
http://dojo-toolkit.33424.n3.nabble.com/file/n2636749/Using_the_Dojo_Toolkit_with_the_Closure_Compiler.pdf?by-user=t
You could adopt an open-source business model and license your scripts with the GPL or Creative Commons BY-NC-ND or similar
While obfuscation in general is a bad thing, IMHO, with Javascript, the story is a little different. The idea is not to obfuscate the Javascript itself but to produce shorter code length (bandwidth is expensive, and that first-time users may just be pissed off waiting for your Javascript to load the first time). Initially called minification (with programs such as minify), it has evolved quite a bit and now a full compiler is available, such as YUI compiler and Google Closure Compiler. Such compiler performs static checking (which is a good thing, but only if you follow the rules of the compiler), minification (replace that long variable name with 'ab' for example), and many other optimization techniques. At the end, what you got is the best of both worlds, coding in non-compiled code, and deploying compiled (, minified, and obfuscated) code. Unfortunately, you would of course need to test it more extensively as well.
The truth is obfuscator or not, any programmer worth his salt could reproduce whatever it is you did in about as much time as it took you. If they stole what you did you could sue them. So bottom line from the business point of view is that you have, from the moment you publish, roughly the same amount of time it took you to implement your design until a competitor catches up. Period. That's all the head start you get. The rest is you innovating faster than your competitors and marketing it at least as well as they do.
Write your web site in flash, or better yet in Silverlight. This will give your company unmatched GUI, that your competitors will be salivating about. But compiled nature of flash/dotnet will not allow them easily pick into your code. It's a win/win situation for you ;)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Coffeescript looks pretty cool. Has anyone used it? What are its Pros & Cons?
We've started to use CoffeeScript in our product - a non-public facing website which is basically an app for browsing certain kinds of data.
We use CoffeeScript as a command-line compiler (not on the server, which we'd eventually like to do).
PROS (for us):
It gets rid of a lot of needless clutter in javascript (eg braces, semi-colons, some brackets) to the extent that the code is cleaner & easier to comprehend at-a-glance than javascript
20-30% less lines of code than javascript (to do exactly the same thing)
CoffeeScript not only removes noise but adds keywords, classes, and features like heredocs to make coding cleaner and somewhat more enjoyable
Given the previous points, it is undoubtedly faster to code in CoffeeScript once you learn the ropes
CONS
When using the command-line compiler: to debug, you're looking at different code when solving the problem (javascript) as when writing the fix (coffeescript). However, somewhat unbelievably, our CoffeeScript is so awesome we've never needed to debug it!
Importantly, we can turn back at anytime. Our coffeescript compiler is just producing readable javascript, so if anyone changes their mind or can't figure something out, then we can just drop back to using the javascript that coffeescript produced - and keep coding.
We use coffeescript for all of the javascript in BusyConf. A large portion of BusyConf is a client side application that runs in browers, including support for offline mode.
All of our coffeescript code is fully tested. The tests themselves are written in coffeescript, and use the Qunit framework (which is written in javascript). We also wrote an extension to the Qunit framework that makes the tests nicer. The Qunit extension is written in CoffeeScript. Our application has a mobile version which is written in CoffeeScript, and it uses the Sencha Touch framework (which is written in javascript).
The take away from that is that you can freely intermix javascript dependencies in your application, but all of the code you write (your application code, tests, etc) can (and should!) be coffeescript.
Almost a year later, it's worth posting some updates:
Ruby on Rails 3.1 is incorporating official CoffeeScript support, which means it's going to see far more real-world use. I gave a talk at RailsConf last month, where most of the attendees hadn't heard of CoffeeScript before and—given dhh's strong endorsement—were eager to get into it.
There's a book on CoffeeScript, currently in eBook and soon to be in print from The Pragmatic Bookshelf. It's called CoffeeScript: Accelerated JavaScript Development, and it's by yours truly. It's based on CoffeeScript 1.1.1.
The language has actually changed very little in the six months between 1.0 and 1.1.1; nearly all of the changes qualify as "bugfixes." I had to make very few tweaks to the code in the book for the transition from 1.0.1 to 1.1.1. However, I'm sure the language will see more significant changes in the future.
The most definitive list of CoffeeScript projects is on the CoffeeScript wiki's In the Wild page.
I'd say that most of the production use of CoffeeScript so far is in conjunction with Appcelerator to create iPhone/Android apps. (Wynn Netherland of The Changelog blurbed my book by describing CoffeeScript as "my secret weapon for iOS, Android, and WebOS mobile development"), but there's going to be a lot more use in production Rails apps—and, I hope, elsewhere—in the coming months.
Coffeescript was used in the Ars Technica reader for iPad http://arstechnica.com/apple/news/2010/11/introducing-the-ars-technica-reader-for-ipad.ars
I really love Coffeescript these days. Essentially the entire HotelTonight iPhone application is written in it (using Appcelerator Titanium, which lets you write "native" apps in JavaScript - they are not web apps, say like Phonegap). I chose to use Coffeescript in this case because it makes organizing and maintaining a large amount of JS a lot easier. I also find it simply a lot more pleasurable to write code with Coffeescript (vs. JavaScript). We also use Coffeescript for the JS in our Rails app, but this is incredibly minor/small amount of code in relation to the entire phone app.
The pros mostly have to do with just being a nicer syntax, but also that it standardizes an OO mechanism, and then adds some nice additions (list comprehensions, some scope things, etc.).
The cons are almost zero for me. The primary one is that it's an extra layer to debug. You will need to look at the generated JS (which is VERY readable and nice), and then map that to your Coffeescript code. For us, this hasn't been an issue at all, but YMMV.
In the end, my take is, there is zero risk in terms of using it on a production app, so, don't let that be a blocker. Then, go try it out. Write some code with it, compare that to what you'd write in JS, look at the generated code to see if you are comfy with being able to read that for debugging needs. Also, hang out in the #coffeescript IRC, people are good there. And finally, see how it would integrate with your app, e.g. what's your "build" process (e.g. for Rails, try Barista, for something standalone, just use the included "coffee -w", etc.).
Coffeescript really just makes writing JS easier. You end up with cleaner, more efficient code.
That being said, you still can only do whatever you can do in vanilla JS. Once you use coffeescript enough, it does become a lot easier to write (good) JS.
So if you haven't used JS a ton, I'd suggest learning coffescript instead. You'll get better, cleaner, less buggy code. If you're already really fluent in JS, it might not be a good idea to start using coffeescript on a "real" app.
(Also, coffeescript does irk me a bit in that it seems to encourage rather "floofy" code. I don't know if it's a good thing or a bad thing, but it seems an extreme case of TMTOWTDI)
Note that although there is a compiler, you don't get static checking due to JavaScript's dynamic nature. As written in the FAQ:
Static Analysis
CoffeeScript uses a straight source-to-source compiler. No type
checking is performed, and we can't work out if a variable even exists
or not. This means that we can't implement features that other
languages can build in natively without costly runtime checks. As a
result, any feature which relies on this kind of analysis won't be
considered.
IDE support is less mature than that of JavaScript (Cloud9 has syntax highlight support, but Eclipse JSDT has refactorings and more): https://stackoverflow.com/questions/4084167/ide-or-its-add-in-for-coffescript-programming
All of my projects include very similar tasks and quite recently I've been thinking I should write a library to handle most of the heavy lifting so I can write short, simple, easy to read code that interacts with the library to get the jobs done. Looking at other frameworks, specifically jQuery & YUI, they work in different ways. jQuery mostly seems to extend & simplify the DOM using a global object/function whereas YUI uses namespaces and modules. I understand that this is because they have different goals as libraries and each have their merits.
Most specifically, I'm looking for answers to the following questions:
Is it best to use namespaces, eg gui.scrollbar.attach(), or a global method such as $(domObj).attachScrollbar()?
Is it best to include individual parts as seperate js files or as a single js file where components are copied/pasted? I know the eBay Shopping API SDK has many .js files in seperate folders, wouldn't this suffer a significant performance hit?
Is there any other advice you would give to someone looking to create a javascript library?
I've marked as community wiki because I didn't want to risk the question being closed - I'm genuinely seeking advice here.
Thanks
EDIT
I should have originally stated that I'm not re-inventing the wheel, I'm looking to simplify many common tasks between Windows Desktop Gadgets, so I don't need the cross-browser compatibility of other libraries and their core functionality doesn't really apply to what I'm doing. I tried to keep the question general and not specifically relating to desktop gadgets, so that this question would be useful for others.
Simple answer to your question: write your library using an existing one.
I have some javascript files written in jQuery just for such purposes.
More specifically,
If you are going for java-style object oriented-ness, go for namespaces. I prefer the jquery way of writing plugins.
If you are writing your own "toolkit", it would be best to copy and paste the dependencies (minified) into your source code. This way
a. you avoid the overhead you mentioned
b. you prevent unnecessary dependencies creeping up externally.
Cheers!
Concerning your first question, the two options are really the same IMO. Instead of a global object like YAHOO or gui, you have a global function like $. In both cases you have a global variable that holds your namespace.
Is there any reason why you can't use one of the many libraries out there already? This seems like a case of reinventing the wheel. These libraries have been around for years and have already tackled many of the issues that you will surely run into when trying to write your own.
In terms of some of your questions:
This is really a matter of preference IMO. As long as you get your functions out of the global namespace that is the major thing. However, this design choice will drive many others down the line.
It is best to include all core functionality in one file and then to chunk the rest into files that are required for a bit of functionality. You want to keep the number of files down, but you also don't want the user to have to download a lot of stuff that they don't need.
Having said all that, I restate that you should look at using one of the libraries already out there unless you have a very good reason not to. Keep in mind that you will need to test in all old browsers as well as any new browsers that come out.
jQuery, YUI, Prototype, Mootools, extJS are a few of the most popular