views:

85

answers:

6

Hey guys.. I am writing a Windows application in C# that minifies CSS files and packs JS files as a batch job. One hurdle for the application is, what if the user selects a JavaScript file that has already been packed? It will end up increasing the file size, defeating my purpose entirely!

Is opening the file and looking for the string eval(function(p,a,c,k,e,d) enough? My guess is no, as there are other JS packing methods out there. Help me out!

+3  A: 

One might suggest that you compare the size of the pre and post packed JS and return/use the smaller of the two.

UPDATE based on question in comment by GPX on Sep 30 at 1:02

The following is a very simple way to tell. There may be different, or more accurate, ways of determining this, but this should get you going in the right direction:

var unpackedJs = File.ReadAllText(...)
var unpackedSize = jsContent.Length;
var packedJs = ... // Your Packaging routine
File.WriteAllText(pathToFile, unpackedSize < packedJs.Length ? unpackedJs : packedJs)
Jordan S. Jones
This is quite a logical solution, but I open the file, read the content, change it and then save it. It would be helpful if I could figure out the file size before writing to the file. Any pointers?
GPX
A: 

I would check file size and lines of code (e.g.: average line length). These two information should be enough to know if the code is sufficiently compact.

Try this demo.

galambalazs
A: 

When you create/save a minified file, use the standard file name convention of "Filename.min.js". Then when they select the file, you can check for that as a reliable indicator.

I do not think it is wise to go overboard on the dummy-proofing. If a user (who is a developer, at that), is dumb enough to double-pack a file, they should experience problems. I know you should give them the benefit of the doubt, but in this case it does not seem worth the overhead.

Josh Stodola
I agree. But what I had in mind was a one-shot soultion that would just do the job without giving the users the additional task of editing their code, even if it's as trivial as ".min" in all JS references.
GPX
A: 

If you're using a safe minimization routine, your output should be the same as the input. I would not recommend the routine you mention. MS's Ajax Minifier is a good tool and even provides dll's to use in your project. This would make your concern a non-issue.

lincolnk
I don't see what you mean by "safe". PACKER has been used by pretty much everyone for many years. It's at least as safe as putting your code through a web browser.
Billy ONeal
Yes. PACKER is safe, in that a repack of an already packed JS would still make it useful, but only bigger in file size!
GPX
A: 

I would suggest adding a '.min' prefix to the extension of the packed file, something like 'script.min.js'. Then just check the file name.

Other than that, I would suggest checking how long the lines are, and how many spaces are used. Minified/packed JS typically has almost no spaces (typically in strings) and very long lines.

Valera
+1  A: 

I direct you to a post that suggests packing is bad.

http://ejohn.org/blog/library-loading-speed/

Rather use minification. Google Closure compiler can do this via a REST web service. Only use a .min.js extension for minified (not packed).

Gzip will do a better job and will be uncompressed by the browser. Its best to switch on zip compression on the server which will zip a minified file down further.

Of course this raises the question 'How can I tell if my Javascript is already minified!'

James Westgate
Thanks for the link, James. But personally, I think the overhead of 'unpacking' the packed JavaScript by your browser isn't much of a game-changer, because these days, everyone has well-powered machines and it won't make much of a difference. Just my argument. What do you think?
GPX
Well the unpacking is done in JavaScript - that is at best going to be jit compiled - but what is worse is that it has to happen every time the page is loaded - even if the script is coming from cache. Gzip compression makes a smaller file, and it is unzipped by the browser once and then put in the cache. Plus it is really easy to set up and you never have to do anything, even when you change the file. For me it's a no brainer.
James Westgate