Should We Use Long-Name Or Short-Name in JavaScript Coding? - javascript

There is a discussion about JavaScript coding in my work group. Some people argues that we should use long-name for better readability; the others believes that short-name should be favored to same bits-on-wire.
Generally, it is about coding convention. One side believes that identifier such as "fAutoAdjustWidth" is OK, while others prefer to "fAtAjtW".
So, what's the better way? Should we sacrifice readability for performance or not?


Make it readable, and if you feel that the resulting JS file is to big, use one of many JS compactors before deploying the production version, while maintaining development version with long names.
BTW. if your really worried about bandwidth, use mod_deflate.


If you're worried about bits on the wire, you could always run a minifier on your code. Then you could develop with long names, and you could release with a much smaller file that
has equivalent functionality. The Yahoo YUI Compressor looks like it does whitespace compression and token compression.


Do these same people advocate not writing comments in their code? Be entirely clear and descriptive with your variable names.


while others prefer to "fAtAjtW"
Even if "bits-on-wire" was an issue (which it's not), a naming convention like this will make the code completely unmaintainable after the first week of working on the project.
Reading the code will get to be near impossible, and when writing the code people will constantly have to think about things like "was 'fAutoAdjustWidth' abbreviated 'fAtAjtW' or was it 'fAutAtW'?". It's a huge mental tax to pay while writing code that will result in far lower productivity.
On top of that, the problem is exacerbated by the fact that in Javascript you will get a new variable for every mistyped name!


Maybe the worry isn't about bits on the wire but the overhead of reading and re/over-viewing the code.
I tend to favor short names inside function and make function names as long as necessary, but as short as possible without loosing useful meaning.
No doubt it is a trade-off. It depends on whether you want your code to resemble natural language or be more implicit and compact.
Some prefix variable names to inject context information into them. I say, if that is necessary, the IDE should provide such injection capabilities as a visual overlay on the code via context symbolics.
The next version of Visual Studio will make such annotation gymnastics much easier via a fine-grained extensibility mechanism extended deep into the editor itself. I have not used Visual Studio for editing Javascript though.
I see now that your concern is indeed the space trade-off. This should never, ever, ever be an issue. Always always always favor readability over bits on the wire, esp. since compression exists, as noted by the other commentators.
The only thing I would add is the above, which is that sometimes comprehension is made easier with compact names over excessively long names. But it is harder to get short names right. Long names are much easier and faster to make right in my experience.
The reason for short names should never be data compression only cognitive efficiency. What works is individual.


Use big variable names because they help the programmer.
To save bits over the wire, minify your Javascript before deploying it to the production server. Dean Edwards' packer has an option to compress variable names, which looks like the best of both worlds for you.


Use the long names which are just enough to well describe variables and functions.
One of the reasons you many need short names is to make the file size smaller, but you can do that by tools while uploading online.


I would strongly advise against using short identifiers. Just reading your example shows how much more documentation is suddenly needed, when names like fAtAjtW are used. At some point it will get pretty much unmaintainable and this just for saving some bytes to transfer.
If the only reason for considering "short" names is to make the resulting script smaller and thus save some bandwidth, I would instead recommend using gzip compression, which will save you way more than a few bytes for an identifier.


One side believes that identifier such as "fAutoAdjustWidth" is OK, while others prefer to "fAtAjtW".
‘fAtAjtW’ is an unreadable, untypeable horror. Seriously, anyone prefers that? Hilarious and impossible to remember — is it ‘AtAjt’, or ‘AutAdj’...?
‘autoAdjustWidth’ would be a suitable full attribute name. (I'm not convinced about the ‘f’ prefix notation at all, but that's another issue.) Sometimes you want a very short name for a short-lived variable (eg. a temporary in a small loop), in which case I'd personally go straight for ‘var aaw’ rather than the above nightmare.
As for performance, there will be no difference. JavaScript doesn't care how long you make variable names, and assuming you're deflating your scripts on the way to the browser the compression will remove any transfer advantage of the shorter names.


Whoever thinks "fAtAjtW" is preferable is using some sort of pharmacalogical method in their programnming. fAutoAdjustWidth is very fine and very prudent. Javascript libraries do not use names like fAtAjtW for a reason. If you are worried about the size then probably your worries are misplaced. However, I recommend using some sort of minifier. However, that said, don't use ridiculously long; probably anything over 25-30 chars is going a bit far.


Use smaller names where it doesn't affect readability of your code. Bigger names are fine, but try only to use them where it really does make something easier for yourself and others to follow. Lastly (and as stated in other answers) minify your code, and / or turn on some kind of server compression mechanism such as apache's mod_gzip or mod_deflate to reduce the number of bits flowing through the wires.
With that said, I would prioritise readability over compactness of variable names.


Long and descriptive names.
And try and make methods as unique as possible. This helps navigability. If you want to find all usages of a particular method, there is less likelihood that you will conflict with another method that has the same name.
Modern Javascript IDEs can also do method refactoring (see : http://blue-walrus.com/2013/08/review-javascript-ides/ ). This is very hard if methods are called the same.

Related

How can I obfuscate the client side source code of my ES6 / React / Redux / Electron project? [duplicate]

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

How to defeat deobfuscation of obfuscated javascript code?

This is a generic question
I've seen javascript on some websites which is obfuscated
When you try to deobfuscate the code using standard deobfuscators (deobfuscatejavascript.com, jsnice.org and jsbeautifier.org)
, the code is not easily deobfuscated
I know it's practically impossible to avoid deobfuscation. I want to make it really tough for an attacker to deobfuscate it
Please suggest some ways I can acheive this
Should I write my own obfuscator, then obfuscate the output with another online obfuscator. Will this beat it?
Thanks in advance
P.S: I tried google closure compiler, uglifyjs, js-obfuscator and a bunch of other tools. None of them (used individually or in combination) are able to beat the deobfuscators

Obfuscation can be accomplished at several levels of sophistication.
Most available obfuscators scramble (shrink?) identifiers and remove whitespace. Prettyprinting the code can restore nice indentation; sweat and lots of guesses can restore sensible identifier names with enough effort. So people say this is weak obfuscation. They're right; sometimes it is enough.
[Encryption is not obfuscation; it is trivially reversed].
But one can obfuscate code in more complex ways. In particular, one can take advantage of the Turing Tarpit and the fact that reasoning about the obfuscated program can be hard/impossible in practice. One can do this by scrambling the control flow and injecting opaque control-flow control predicates that are Turing-hard to reason about; you can construct such predicates in a variety of ways. For example, including tests based on constructing artificial pointer-aliasing (or array subscripting, which is equivalent) problems of the form of "*p==*q" for p and q being pointers computed from messy complicated graph data structures.
Such obfuscated programs are much harder to reverse engineer because they build on problems that are Turing hard to solve.
Here's an example paper that talks about scrambling control flow. Here's a survey on control flow scrambling, including opaque predicates.
What OP wants is an obfuscator that operates at this more complex level. These are available for Java and C#, I believe, because building program analyzers to determine (and harness) control flow is relatively easy once you have a byte code representation of the program rather than just its text. They are not so available for other languages. Probably just a matter of time.
(Full disclosure: my company builds the simpler kind of obfuscators. We think about the fancier ones occasionally but get distracted by shiny objects a lot).

The public de-obfuscators listed by you use not much more than a simple eval() followed by a beautifier to de-obfuscate the code. This might need several runs. It works because the majority of obfuscators do their thing and add a function at the end to de-obfuscate it enough to allow the engine to run it. It is a simple character replacement (a kind of a Cesar cipher) in most cases and an eval() is enough to get some code, made more or less readable by a beautifier after that.
To answer your question: you can make it tougher ("tougher" in the sense that just c&p'ing it into a de-obfuscator doesn't work anymore) by using some kind of "encryption" that uses a password the the code gets from the server after the first round of de-obfuscation and uses a relative path that the browser completes instead of a full path. That would need manual intervention. Build that path in a complicated and non-obvious way and you have a deterrent for the average script-kiddie.
In general: you need something to de-obfuscate the script that is not in the script itself.
But beware: it does only answer your question, that is, it makes it impossible to de-obfuscate by simple c&p into one of those public de-obfuscators and not more. See Ira's answer for the more complex stuff.
Please be aware of the reasons to obfuscate code:
hide malicious intent/content
hide stolen code
hide bad code
a pointy haired boss/investor
other (I know what that is, but I am too polite to say)
Now, what do the people think, if they see your obfuscated code? That your investor insisted on it to give you money to write that little browser game everyone loves so much?

JavaScript is interpreted from clear text by your browser. If a browser can do it, so can you. It's the nature of the beast. There are plenty of other programming languages out there that allow you to compile/black box before distribution. If you are hell-bent on protecting your intellectual property, compile the server side data providers that your JavaScript uses.

No JavaScript obfuscation or protection can say it makes it impossible to reverse a piece of code. That being said there are tools that offer a very simple obfuscation that is easy to reverse and others that actually turn your JavaScript into something that is extremely hard and unfeasible to reverse. The most advanced product I know that actually protects your code is Jscrambler. They have the strongest obfuscation techniques and they add code locks and anti-debugging features that turn the process of retrieving your code into complete hell. I've used it to protect my apps and it works, it's worth checking out IMO

JavaScript log parser project: Bad idea?

There are numerous log files that I have to review daily for my job. Several good parsers already exist for these log files but I have yet to find exactly what I want. Well, who could make something more tailored to you than you, right?
The reason I am using JavaScript (other than the fact that I already know it) is because it's portable (no need to install anything) but at the same time cross-platform accessible. Before I invest too much time in this, is this a terrible method of accomplishing my goal?
The input will be entered into a text file, delimited by [x] and the values will be put into an array to make accessing these values faster than pulling the static content.
Any special formatting (numbers, dates, etc) will be dealt with before putting the value in the array to prevent a function from repeating this step every time it is used.
These logs may contain 100k+ lines which will be a lot for the browser to handle. However, each line doesn't contain a ton of information.
I have written some of it already, but with even 10,000 lines it's starting to run slow and I don't know if it's because I wasn't efficient enough or if this just cannot be effectively done. I'm thinking this is because all the data is in one giant table. I'd probably be better off paginating it, but that is less than desirable.
Question 1: Is there anything I failed to mention that I should consider?
Question 2: Would you recommend a better alternative?
Question 3: (A bit off topic, so feel free to ignore). Instead of copy/pasting the input, I would like to 'open' the log file but as far as I know JavaScript cannot do this (for security reasons). Can this be accomplished with a input="file" without actually having a server to upload to? I don't know how SSJS works, but it appears that I underestimated the limitations of JavaScript.
I understand this is a bit vague, but I'm trying to keep you all from having to read a book to answer my question. Let me know if I should include additional details. Thanks!

I think JavaScript is an "ok" choice for this. Using a scripting language to parse log files for personal use is a perfectly sane decision.
However, I would NOT use a browser for this. Web browsers place limitations on how long a bit of javascript can run, or on how many instructions it is allowed to run, or both. If you exceed these limits, you'll get something like this:
Since you'll be working with a large amount of data, I suspect you're going to hit this sooner or later. This can be avoided by clever use of setTimeout, or potentially with web workers, but that will add complexity to your project. This is probably not what you want.
Be aware that JavaScript can run outside of browsers as well. For instance, Windows comes with the Windows Script Host. This will let you run JavaScript from the command prompt, without needing a browser. You won't get the "Script too long" error. As an added bonus, you will have full access to the file system, and the ability to pass command-line arguments to your code.
Good luck and happy coding!

To answer your top question in bold: No, it is not a terrible idea.
If JS is the only language you know, you want to avoid setting up any dependencies, and you want to stay platform-independent... JavaScript seems like a good fit for your particular case.
As a more general rule, I would never use JS as a language to write a desktop app. Especially not for doing a task like log parsing. There are many other languages which are much better suited to this type of problem, like Python, Scala, VB, etc. I mention Python and Scala because of their script-like behaviour and minimal setup requirements. Python also has very similar syntax to JS so it might be easier to pick up then other languages. VB (or any .NET language) would work too if you have a Visual Studio license because of it's easy to use GUI builder if that suits your needs better.
My suggested approach: use an existing framework. There are hundreds, if not thousands of log parsers out there which handle all sorts of use-cases and different formats of logs that you should be able to find something close to what you need. It may just take a little more effort than Google'ing "Log Parsers" to find one that works. If you can't find one that suits your exact needs and you are willing to spend time making your own, you should use that time instead to contribute to one of the existing ones which are open source. Extending an existing code base should always be considered before trying to re-invent the wheel for the 10th gillion time.

Given your invariants "javascript, cross-platform, browser ui, as fast as possible" I would consider this approach:
Use command line scripts (windows: JScript; linux: ?) to parse log files and store 'clean'/relevant data in a SQLite Database (fall back: any decent scripting language can do this, the ready made/specialized tools may be used too)
Use the SQLite Manager addon to do your data mining with SQL
If (2) gets clumsy - use the SQLite Manager code base to 'make something more tailored'
Considering your comment:
For Windows-only work you can use the VS Express edition to write an app in C#, VB.NET, C++/CLI, F#, or even (kind of) Javascript (Silverlight). If you want to stick to 'classic' Javascript and a browser, write a .HTA application (full access to the local machine) and use ADO data(base) access and try to get the (old) DataGrid/Flexgrid controls (they may be installed already; search the registry).

Is obsfucation worthwhile?

Does it make sense to obsfucate Javascript? The only clear benefits I can see are to hide code (albeit non-proprietary in nature since it's client-side) from prying eyes and as a minimizer since often Javascript obsfucators do minimization as well.

I do not think that JavaScript obfuscation is worth the effort for concealment purposes in most general scenarios. However, minification is worth-it, for many reasons, which as you mentioned, has the minor side-effect of obfuscating code as well.

Well, if its not some cutting edge javascript code that should not be easily copied and reproduced, and the script is not too big in bytes, i would not do the bother. Its a bit hassle to do the obfuscating each time you need a deploy, and the benefit is small.
That is, the script is not too big , and code does not to be protected.
(even obfuscation does not really protect your code, just make it abit harder to understand)

I have used the YUI Builder, I find it good for reducing the size of my javascript a great deal. So minimization aspect of the obfuscation is a very useful in itself.
In terms of security, I guess anything you can do to make it harder for malicious user to figure out how your stuff works, the better off you are.
Lastly most obsfuscators will give you warnings or errors when it encounters badly written javascript, and as a whole will improve the quality of your code as well.
So in summary
Cons: You gotta run the obfuscator
Pros:
Smaller files
Harder for malicious users to figure out how your stuff works.
Higher quality javascript (if you listen to the obsfuscator).

I don't think it is worthwhile, because anyone motivated enough to get your code can still get it. As far as minimizing, I don't bother, since gzip mitigates the need for that.

Obfuscating is a side effect of minimizing. Your variables, functions, etc. are renamed to the shortest possible length to save space. Otherwise, minimizers would simply be white space removers.
While definitely possible to tell what your code is doing even if it was obfuscated, it will be much harder to someone "casually" looking at your code.

The Dojo library has a component called ShrinkSafe. It will compress your JavaScript file and will obfuscate the code some. This way, you can keep the originals somewhere and then release only the ones ran through ShrinkSafe.

Checking for code plagiarism with JavaScript

I was wondering how I can detect code plagiarism with Javascript. I want to test assignment submissions for homework I'm going to hand out.
I've looked at using MOSS, but—from what I've heard—it's pretty poor for anything other than C. Unfortunately, I can't test it yet because I don't have submissions.
How can I go about detecting code plagiarism with JavaScript?

They claim that MOSS works on Javascript. Why don't you just try it. Write a Javascript file, then modify it, like a cheater would modify somebody elses code and feed it to MOSS to see what it says?

I build Clone detection tools, that find similar blocks of code across files.
See CloneDR overview
and example reports. CloneDR works for a wide variety of languages, and uses
the langauge structure to makethe clone detection efficient and effective.

As per yar's comment pasting chunks of javascript into Google will work pretty well - but is stopping them cheating realistic?
Could you split the task into two parts, the first part allowing them to 'cheat' if they want to but tell them that there will be a second part of the task in class. Then have the class do exactly the same task in supervised class time.
If everyone has 'cheated' first time that's one thing. But if anyone is unable to redo their homework in class then they a) cheated (which is bad enough) and b) learnt nothing (which is worse).
Using the internet to 'research' is always going to happen - but its the ones who forget their 'research' that are cheating both you and themselves.

I wouldn't go out of my way to try and run through a plagiarism checker.
Code is code and bad code is bad code. People who can't code (those who are more likely to copy/paste code**) generally don't have good code. Difficulties (and questionable approaches around them) will be easily detectable if you even take a few seconds to check the source. Something just won't match up and it should smack you in the face.
**I would argue that adapted code isn't plagiarized unless it violates the authors distribution intent (e.g. violates copyright or license) and would encourage the students to simply document which existing resources, if any, they used as a base and/or incorporated as well as to encourage them to understand and adapt the code to fit their needs (and to make it better, so much code out there is soup). I do this all the time for "real programming work". Of course, it's not my curriculum :-)

Categories