javascript packer versus minifier - javascript

I was wondering what the differences/benefits of the packer vs the minifier were, i.e. Should you deploy a packed or minified version in your web app?
Example code:
var layout = {
NAVVISIBLE : 1,
Init : function()
{
this.Resize();
},
Dimensions : function()
{
var d = document, s = self, w, h;
if (s.innerHeight)
{ w = s.innerWidth; h = s.innerHeight; }
else if (d.documentElement && d.documentElement.clientHeight)
{ w = d.documentElement.clientWidth; h = d.documentElement.clientHeight; }
else if (d.body)
{ w = d.body.clientWidth; h = d.body.clientHeight; }
return new Array(parseInt(w), parseInt(h));
},
Resize : function()
{
var dim = this.Dimensions();
try
{
$('tbl_container').width = px(dim[0] - 25);
$('row_container').height = px(dim[1] - 100);
$('dat_container').width = px(dim[0] - (this.NAVVISIBLE ? 275 : 25));
$('dat_container').height = px(dim[1] - 100);
}
catch(e) {}
},
GoSideways : function()
{
var nc = $('nav_container');
var dc = $('dat_container');
nc.style.display = this.NAVVISIBLE ? 'none' : '';
dc.width = px(parseInt(dc.width) + (this.NAVVISIBLE ? 250 : -250));
this.NAVVISIBLE ^= 1;
},
FrameLoad : function(url)
{
if (url)
content_frame.document.location = url;
}
};
minified:
var layout={NAVVISIBLE:1,Init:function()
{this.Resize();},Dimensions:function()
{var d=document,s=self,w,h;if(s.innerHeight)
{w=s.innerWidth;h=s.innerHeight;}
else if(d.documentElement&&d.documentElement.clientHeight)
{w=d.documentElement.clientWidth;h=d.documentElement.clientHeight;}
else if(d.body)
{w=d.body.clientWidth;h=d.body.clientHeight;}
return new Array(parseInt(w),parseInt(h));},Resize:function()
{var dim=this.Dimensions();try
{$('tbl_container').width=px(dim[0]-25);$('row_container').height=px(dim[1]-100);$('dat_container').width=px(dim[0]-(this.NAVVISIBLE?275:25));$('dat_container').height=px(dim[1]-100);}
catch(e){}},GoSideways:function()
{var nc=$('nav_container');var dc=$('dat_container');nc.style.display=this.NAVVISIBLE?'none':'';dc.width=px(parseInt(dc.width)+(this.NAVVISIBLE?250:-250));this.NAVVISIBLE^=1;},FrameLoad:function(url)
{if(url)
content_frame.document.location=url;}};
packed:
eval(function(p,a,c,k,e,d){e=function(c){return(c<a?'':e(parseInt(c/a)))+((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};if(!''.replace(/^/,String)){while(c--){d[e(c)]=k[c]||e(c)}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('5 B={3:1,C:6(){2.n()},v:6(){5 d=k,s=y,w,h;9(s.u){w=s.A;h=s.u}r 9(d.a&&d.a.c){w=d.a.p;h=d.a.c}r 9(d.b){w=d.b.p;h=d.b.c}D z x(g(w),g(h))},n:6(){5 7=2.v();F{$(\'N\').8=4(7[0]-o);$(\'P\').m=4(7[1]-l);$(\'i\').8=4(7[0]-(2.3?E:o));$(\'i\').m=4(7[1]-l)}L(e){}},H:6(){5 t=$(\'I\');5 j=$(\'i\');t.J.G=2.3?\'Q\':\'\';j.8=4(g(j.8)+(2.3?q:-q));2.3^=1},M:6(f){9(f)O.k.K=f}};',53,53,'||this|NAVVISIBLE|px|var|function|dim|width|if|documentElement|body|clientHeight|||url|parseInt||dat_container|dc|document|100|height|Resize|25|clientWidth|250|else||nc|innerHeight|Dimensions||Array|self|new|innerWidth|layout|Init|return|275|try|display|GoSideways|nav_container|style|location|catch|FrameLoad|tbl_container|content_frame|row_container|none'.split('|'),0,{}))

Packed is smaller but is slower.
And even harder to debug.
Most of the well known frameworks and plugins are only minified.
Take a look at the google minifier: http://code.google.com/intl/en-EN/closure/compiler/
They offer a firebug plugin for debugging minified code.

Packer does more then just rename vars and arguments, it actually maps the source code using Base62 which then must be rebuilt on the client side via eval() in order to be usable.
Side stepping the eval() is evil issues here, this can also create a large amount of overhead on the client during page load when you start packing larger JS libraries, like jQuery. This why only doing minify on your production JS is recommend, since if you have enough code to need to do packing or minify, you have enough code to make eval() choke the client during page load.
For a good minifier, I would look to using Google's Closure Compiler
http://code.google.com/closure/compiler/
The SIMPLE_OPTIMIZATIONS mode is what I would recommend using, as it cleans whitespace/comments and munges(reduces) variables. It also does some simple code changes that basically amount to code clean up and micro optimizations. You can see more about this on the Getting Started with the Closure Compiler Application
or the checking out the packaged README.
YUI Compressor is another option(from Yahoo) but it doesn't reduce the file size as much as CC does.
There is also a tool from Microsoft, the name escapes me at the moment but that apparently delivers similar results to CC. That one could be a better or worse option, depending on your environment. I've only read about it in passing, so further investigation would be required.

If your server gzips files before sending them to the browser (which is very often the case) then packer is not the way to go. I've tested a number of files, and even though packer makes smaller files than minification, it makes larger zipped files. While I'm not an expert, I think the reason is fairly straight-forward.
A big part of zipping is to find repeated character sequences and replace them with a shorter place holder to be unpacked later. This is the same thing packer does, except zip algorithms are much more efficient. So when you pack a file you are in a way pre-zipping it, but with an algorithm that is less efficient than an actual zip file. This leaves less work for the zip algorithm to do, with a subsequent decrease in zipping efficiency.
So if you are zipping the files, then packer will actually produce larger downloads. Add to this the additional downsides of packer mentioned in the above answers, and there is really no good reason to use packer.

Both aims at lowering the size of JavaScript to enable fast download on the client browser.
Minifier only removes unnecessary things like white space characters and renaming variable to smaller names wherever possible. But a Packer goes one step further and does whatever it can do to minimize the size of JavaScript. For e.g. it converts source code to Base62 while preserving it's mappings to be evaluated by client.

Depending on the code packed, the packed solution ca lead to script-errors, while the minified will work.
So test with different browsers, after packing your code. If it doesn't work anymore, try the minified version, which always should work.

A "packer" is the same as a "minifier". The most common tool that calls itself a "packer" is http://dean.edwards.name/packer/ which gives the option (turned off by default) to base62 encode. Base62 encoding is probably a bad idea: https://stackoverflow.com/a/1351624/24267.

Related

An object disappears after packing a JavaScript library

I have created a JavaScript library and packed it with these options selected : Shrink Variables and Base62 Encoded at this url: http://dean.edwards.name/packer/. In this library I have declared an object ax, but when I use the packed version in my web page I get an error saying Uncaught ReferenceError: ax is not defined.
The original code of this library looks like below.
var ax = {
scaleUp:function(win) {
//code omitted
},
downGrade:function(win) {
//code omitted
}
}
In my web page in which I am using this library, I have code like below. This code works, if instead of packing, I minify it using Microsoft's Minifier or just use the original JavaScript library without minification or packing.
var result = ax.downGrade(w);
Question :
Why is the variable ax not accessible with packed version? Do I need to add something else when using the packed version?
UPDATE 1:
I could not get the packed file to work but packing my code through another compression utility at following url worked in my case: http://jsutility.pjoneil.net/. It provided an equally good compression.
I am still not sure why the utility at original url failed to produce a working version of my library, even though my original code works without any errors on any web page.
Check your console for errors before trying to call ax. Explicitly place semi-colons where they belong.Example at the end of the definition for ax you should put a semi-colon, even though in standard code it's good as is. Remove the explicit var declarations. When I did these things:
ax = {
scaleUp:function(win) {
alert("up");
},
downGrade:function(win) {
alert("down");
}
};
result = ax.downGrade();
Ran without issue in jsFiddle and console: http://jsfiddle.net/7kdnw65n/. I suspect it has to do with how the algorithm "shrinks" the variables. The resulting pack was:
eval(function(p,a,c,k,e,r){e=String;if(!''.replace(/^/,String)){while(c--)r[c]=k[c]||c;k=[function(e){return r[e]}];e=function(){return'\\w+'};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p}('0={5:1(2){3("6")},4:1(2){3("7")}};8=0.4();',9,9,'ax|function|a|alert|downGrade|scaleUp|up|down|result'.split('|'),0,{}))

Namespacing Hierarchy, Minify and Cross-Browser Compatibility

I've been using the following model for Namespacing my newest Scripts. So far, it has some distinct advantages that, while I'm sure could be replicated in other ways, really help to in my coding process. Unfortunately, I've come across a significant disadvantage... When using some JS compression utilities, they mangle the code badly enough that I must avoid many advantageous options. Luckily, the code I save with this model helps mitigate the "damages".
I'm still curious to know if there is a more viable solution as the min.js only fail consistently in Chrome/IE. I know the below is a little too abstract for some. Are there any experts that might point me in the right direction. I've used YUI, Packer and JSMin. JSMin works reliably, but is not nearly as efficient...
/* Global Namspace */
(function (T) {"use strict";
/* Top.Sub1 */
(function(S1) {
// ... Some methods (public/private)
/* Top.Sub1.Mini */
(function(M) {
// ... Some methods (public/private)
}(S1.Mini = S1.Mini || function(o){}));
}
(T.Sub1 = T.Sub1 || function(o){}));
/* Top.Sub2 */
(function(S2) {
// ... Some methods (public/private)
/* Top.Sub2.Mini1 */
(function(M1) {
// ... Some methods (public/private)
}(S2.Mini1 = S2.Mini1 || function(o) {}));
/* Top.Sub2.Mini2 */
(function(M2) {
// ... Some methods (public/private)
}(S2.Mini2 = S2.Mini2 || function(o) {}));
} (T.Sub2 = T.Sub2 || function(o) {}));
} (window.Namespace = window.Namespace || function(o){}));
UPDATE: The most common error I am faced with is "unexpected token" of various sorts.. sometimes a ')' and sometimes a '}'. Every once in a while, it is a '('. I haven't yet addressed gzip as I want this out of the way.
UPDATE 2: Have checked/removed ns with a Tidied-jsHint passing file and still does not minify correctly. It definitely has to do with this model... Does anyone have a clear answer as to why? If not, further recommendations are welcome. P.S. the Github has been updated with Tidied-jsHint passing code.
I'd say read this article about what needs to be done and what needs to be avoided for good minification – http://alistapart.com/article/javascript-minification-part-II
And then choose a proper modules framework like AMD or commonjs.
UPD. My main advice will be to use a linter on your code like http://jshint.com and adhere to a coding style like http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml It mostly comes with explanations of why something will break in certain sitautions. It's also going to make your code more approachable for open source contributors.
After testing nearly every option on every minifier I could get my hands on, the code minifies quite fine. (With and without the tidy, etc...) The issue comes when any of the minifiers try to replace or obfuscate symbols. In particular, it does not handle this for loop well:
for (i = 0; i < l; i++) {
_.points[i] = new S.Point(_, pts[i]);
}
Removal of the loop allows for the optimization to occur correctly.

Javascript and jQuery file structure

I have created a sizable application javascript and jQuery. However my file structure is getting a bit messy!
At the moment I have one large JS file with a if ($('#myDiv').length > 0) { test at the top to only execute the code on the correct page, is this good practice?
There is also a mixture of plain JS functions and jQuery extensions in the same file e.g $.fn.myFunction = function(e) {.
I also have a few bits of code that look like this:
function Product() {
this.sku = '';
this.name = '';
this.price = '';
}
var myProduct = new Product;
Basket = new Object;
My question is for pointers on good practice regarding javascript and jQuery projects.
The code if ($('#myDiv').length > 0) { is not good practice. Instead, make your page specific JS as functions and execute them in the corresponding page . Like this:
var T01 = function(){
// JS specific to Template 01
};
var T02 = function(){
// JS specific to Template 02
};
HTML head of Template 01:
<script type="text/javascript"> $(T01); </script>
Consistency is the golden rule.
You can discuss design patterns back and forth, but if you want to have easily maintainable code where new people can come in and get an overview fairly quickly, the most important part, whatever design patterns you chose, is to have a consistent code base.
It is also the hardest thing to do - keeping your codebase clean and consistent is probably the hardest thing you can do as a programmer, and especially as a team.
Of course the first tip I can give you is to separate the jQuery extensions in their own source files. You can always serve everything together with a minification tool, so you should not worry about performance.
About the code youo mention, it could be simplified to
var Product = {
sku: '',
name: '',
price: ''
}
var myProduct = objectCopy(Product);
var Basket = {};
provided you write a simple objectCopy function which loops through the object own properties and just copies them to a new object (you can make a shallow or a deep copy, according to your needs).
Finally, if you think your code is starting to get messy, you may want to learn some patterns to organize JS code, like the module pattern. Alternatively, if you are familiar with doing this on the backend, you may want to organize your application following the MVC pattern. personal advertisement - I have written myself a tiny library which helps organize your code in this fashion. There are also many other libraries for the same task, often adding other functionality as well.
If you follow the MVC pattern, your page will actually correspond to some action in some controller, and you could just start it with a call like
<script>someController.someAction()</script>
in the head of your document, hence removing the need for the manual check for #myDiv. If you use my library MCV, it will be enough to declare your body like
<body class="mcv:controller/action">
and start the application with
$(document).ready(function() {
mcv.autostart();
});
Yes it's good practice to put as much of your code into a seperate JS file as this could then be compressed before transmission and hence speed up download time. However no you should not have code that looks like
if ($('#myDiv').length > 0) {
on every page. Split your JS code up into manageable functions and call those as-and-when you need to.
I don't see a problem with mixing JS and jQuery functions up in the same file.

How can I easily maintain a cross-file JavaScript Library Development Environment

I have been developing a new JavaScript application which is rapidly growing in size.
My entire JavaScript Application has been encapsulated inside a single function, in a single file, in a way like this:
(function(){
var uniqueApplication = window.uniqueApplication = function(opts){
if (opts.featureOne)
{
this.featureOne = new featureOne(opts.featureOne);
}
if (opts.featureTwo)
{
this.featureTwo = new featureTwo(opts.featureTwo);
}
if (opts.featureThree)
{
this.featureThree = new featureThree(opts.featureThree);
}
};
var featureOne = function(options)
{
this.options = options;
};
featureOne.prototype.myFeatureBehavior = function()
{
//Lots of Behaviors
};
var featureTwo = function(options)
{
this.options = options;
};
featureTwo.prototype.myFeatureBehavior = function()
{
//Lots of Behaviors
};
var featureThree = function(options)
{
this.options = options;
};
featureThree.prototype.myFeatureBehavior = function()
{
//Lots of Behaviors
};
})();
In the same file after the anonymous function and execution I do something like this:
(function(){
var instanceOfApplication = new uniqueApplication({
featureOne:"dataSource",
featureTwo:"drawingCanvas",
featureThree:3540
});
})();
Before uploading this software online I pass my JavaScript file, and all it's dependencies, into Google Closure Compiler, using just the default Compression, and then I have one nice JavaScript file ready to go online for production.
This technique has worked marvelously for me - as it has created only one global footprint in the DOM and has given me a very flexible framework to grow each additional feature of the application. However - I am reaching the point where I'd really rather not keep this entire application inside one JavaScript file.
I'd like to move from having one large uniqueApplication.js file during development to having a separate file for each feature in the application, featureOne.js - featureTwo.js - featureThree.js
Once I have completed offline development testing, I would then like to use something, perhaps Google Closure Compiler, to combine all of these files together - however I want these files to all be compiled inside of that scope, as they are when I have them inside one file - and I would like for them to remain in the same scope during offline testing too.
I see that Google Closure Compiler supports an argument for passing in modules but I haven't really been able to find a whole lot of information on doing something like this.
Anybody have any idea how this could be accomplished - or any suggestions on a development practice for writing a single JavaScript Library across multiple files that still only leaves one footprint on the DOM?
The jQuery github has a similar setup to the one you speak of. There is even a Makefile / ant build.xml that use the google closure complier.
The basic concept is to develop all your stuff in separate files, then use cat (or something similar) to put all the files together.
cat intro.js core.js featureOne.js featureTwo.js featureThree.js outro.js > build/script.js
The code inside intro.js and outro.js from jQuery:
// intro.js
(function(window, undefined) {
// outro.js
})(window);
Take a look at how this library is built
http://github.com/oyvindkinsey/easyXDM
The files are separated, but merged together, placed into a closure, and run through jslint by the ant script (build.xml).
The ant script also does conditional 'compilation', string replacements and minification.
I recommend that you split your code base into AMD/RequireJS-style modules.
The AMD format seems to meet most of your requirements, and is rapidly becoming a de facto standard.

How to 'minify' Javascript code

JQuery has two versions for download, one is Production (19KB, Minified and Gzipped), and the other is Development (120KB, Uncompressed Code).
Now the compact 19kb version, if you download it, you will see is still a javascript executable code. How did they compactify it? And how can I 'minify' my code like that too?
DIY Minification
No minifier can compress properly a bad code.
In this example i just wanna show how much a minifier does.
What you should do before you minify
And regarding jQuery... i don't use jQuery.jQuery is for old browsers,it was made for compatibility reasons .. check caniuse.com, almost everything works on every browser (also ie10 is standardized now) , i think now it's just here to slow down your web application...if you like the $() you should create your own simple function.And why bother to compress your code if your clients need to download the 100kb jquery script everythime?how big is your uncompressed code? 5-6kb..? Not to talk about the tons of plugins you add to to make it easier.
Original Code
When you write a function you have an idea, start to write stuff and sometimes you end up with something like the following code.The code works.Now most people stop thinking and add this to a minifier and publish it.
function myFunction(myNumber){
var myArray = new Array(myNumber);
var myObject = new Object();
var myArray2 = new Array();
for(var myCounter = 0 ; myCounter < myArray.length ; myCounter++){
myArray2.push(myCounter);
var myString = myCounter.toString()
myObject[ myString ] = ( myCounter + 1 ).toString();
}
var myContainer = new Array();
myContainer[0] = myArray2;
myContainer[1] = myObject;
return myContainer;
}
Here iss the minified code (i added the new lines)
Minified using (http://javascript-minifier.com/)
function myFunction(r){
for(var n=new Array(r),t=new Object,e=new Array,a=0;a<n.length;a++){
e.push(a);
var o=a.toString();
t[o]=(a+1).toString()
}
var i=new Array;
return i[0]=e,i[1]=t,i
}
But are all those vars , ifs, loops & definitions necessary?
Most of the time NO !
Remove unnecessary if,loop,var
Keep a copy of your original code
Use the minifier
OPTIONAL (increases the performance & shorter code)
use shorthand operators
use bitwise operators (don't use Math)
use a,b,c... for your temp vars
use the old syntax (while,for... not forEach)
use the function arguments as placeholder (in some cases)
remove unneccessary "{}","()",";",spaces,newlines
Use the minifier
Now if a minifier can compress the code your doing it wrong.
No minifier can compress properly a bad code.
DIY
function myFunction(a,b,c){
for(b=[],c={};a--;)b[a]=a,c[a]=a+1+'';
return[b,c]
}
It does exactly the same thing as the codes above.
Performance
http://jsperf.com/diyminify
You always need to think what you need:
Before you say "Noone would write code like the one below" go and check the first 10 questions in here ...
Here are some common examples i see every ten minutes.
Want a reusable condition
if(condition=='true'){
var isTrue=true;
}else{
var isTrue=false;
}
//same as
var isTrue=!!condition
Alert yes only if it exists
if(condition==true){
var isTrue=true;
}else{
var isTrue=false;
}
if(isTrue){
alert('yes');
}
//same as
!condition||alert('yes')
//if the condition is not true alert yes
Alert yes or no
if(condition==true){
var isTrue=true;
}else{
var isTrue=false;
}
if(isTrue){
alert('yes');
}else{
alert('no');
}
//same as
alert(condition?'yes':'no')
//if the condition is true alert yes else no
Convert a number to a string or viceversa
var a=10;
var b=a.toString();
var c=parseFloat(b)
//same as
var a=10,b,c;
b=a+'';
c=b*1
//shorter
var a=10;
a+='';//String
a*=1;//Number
Round a number
var a=10.3899845
var b=Math.round(a);
//same as
var b=(a+.5)|0;//numbers up to 10 decimal digits (32bit)
Floor a number
var a=10.3899845
var b=Math.floor(a);
//same as
var b=a|0;//numbers up to 10 decimal digits (32bit)
switch case
switch(n)
{
case 1:
alert('1');
break;
case 2:
alert('2');
break;
default:
alert('3');
}
//same as
var a=[1,2];
alert(a[n-1]||3);
//same as
var a={'1':1,'2':2};
alert(a[n]||3);
//shorter
alert([1,2][n-1]||3);
//or
alert([1,2][--n]||3);
try catch
if(a&&a[b]&&a[b][c]&&a[b][c][d]&&a[b][c][d][e]){
console.log(a[b][c][d][e]);
}
//this is probably the onle time you should use try catch
var x;
try{x=a.b.c.d.e}catch(e){}
!x||conole.log(x);
more if
if(a==1||a==3||a==5||a==8||a==9){
console.log('yes')
}else{
console.log('no');
}
console.log([1,3,5,8,9].indexOf(a)!=-1?'yes':'no');
but indexOf is slow read this https://stackoverflow.com/a/30335438/2450730
numbers
1000000000000
//same as
1e12
var oneDayInMS=1000*60*60*24;
//same as
var oneDayInMS=864e5;
var a=10;
a=1+a;
a=a*2;
//same as
a=++a*2;
Some nice articles/sites i found about bitwise/shorthand:
http://mudcu.be/journal/2011/11/bitwise-gems-and-other-optimizations/
http://www.140byt.es/
http://www.jquery4u.com/javascript/shorthand-javascript-techniques/
There are also many jsperf sites showing the performance of shorthand & bitwsie if you search with your favorite searchengine.
I could go one for hours.. but i think it's enough for now.
if you have some questions just ask.
And remember
No minifier can compress properly a bad code.
You could use one of the many available javascript minifiers.
YUI Compressor
Google closure compiler
Dean Edwards packer
JSMin
Google just made available a javascript compiler that can minify your code, elimiated dead code branches and more optimizations.
google javascript compiler
Regards
K
If you are using the VSCode editor, there are lots of plugins/extensions available.
The MinifyAll for instance is a very good one - compatible with many extension.
Install it and reload VSCode. Then click on your file, open command palette (Ctrl+Shift+p), ant type minify this document (Ctrl+alt+m) other available options there also like preserve original document and so on! Easy!
I recently needed to perform the same task. While the compressors listed at The JavaScript CompressorRater do a great job and the tool is very useful, the compressors were not playing nice with some jQuery code I am using ($.getScript and jQuery.fn checks). Even the Google Closure Compressor choked on the same lines. While I could have eventually ironed out the kinks it was far to much squinting to do constantly.
The one that finally worked without issue was UglifyJS (thanks #Aries51), and the compression was only slightly less than all the others. And similar to Google it has a HTTP API. Packer is also nice and has language implementation in Perl, PHP, and .NET.
Along with minifying you can base64 encode it too. It makes your file much more compressed. I'm sure you have seen js files that are wrapped inside an eval() function with parameters (p,a,c,k,e,r) passed. I read it in this article How to Minify a Javascript File?
I have written a tiny script which calls a API to get your script minified, check it out:
#!/usr/bin/perl
use strict;
use warnings;
use LWP::UserAgent;
use HTTP::Request;
use Fcntl;
my %api = ( css => 'https://cssminifier.com/raw', js => 'https://javascript-minifier.com/raw' );
my $DEBUG = 0;
my #files = #ARGV;
unless ( scalar(#files) ) {
die("Filename(s) not specified");
}
my $ua = LWP::UserAgent->new;
foreach my $file (#files) {
unless ( -f $file ) {
warn "Ooops!! $file not found...skipping";
next;
}
my ($extn) = $file =~ /\.([a-z]+)/;
unless ( defined($extn) && exists( $api{$extn} ) ) {
warn "type not supported...$file...skipping...";
next;
}
warn "Extn: $extn, API: " . $api{$extn};
my $data;
sysopen( my $fh, $file, O_RDONLY );
sysread( $fh, $data, -s $file );
close($fh);
my $output_filename;
if ( $file =~ /^([^\/]+)\.([a-z]+)$/ ) {
$output_filename = "$1.min.$2";
}
my $resp = $ua->post( $api{$extn}, { input => $data } );
if ( $resp->is_success ) {
my $resp_data = $resp->content;
print $resp_data if ($DEBUG);
print "\nOutput: $output_filename";
sysopen( my $fh, $output_filename, O_CREAT | O_WRONLY | O_TRUNC );
if ( my $sz_wr = syswrite( $fh, $resp_data ) ) {
print "\nOuput written $sz_wr bytes\n";
my $sz_org = -s $file;
printf( "Size reduction %.02f%%\n\n", ( ( $sz_org - $sz_wr ) / $sz_org ) * 100 );
}
close($fh);
}
else {
warn: "Error: $file : " . $resp->status_line;
}
}
Usage:
./minifier.pl a.js c.css b.js cc.css t.js j.js [..]
There are currently 2 ways of minifying your code:
you apply minifiers at the backend side of your application - here the advantage is that you can apply versioning and are more in control of your code - you can practically fully automate the process of minification and best practice would be to apply it before your code is uploaded to the server - this is best used when you have a lot of frontend (to be minified) Javascript and CSS code:
http://yui.github.io/yuicompressor/
Many such tools are available for Node and npm as well - it's good practice to automate the mnification of Javascript with Grunt.
you can use some of the existing free tools for minification that are running online - these practically allow you to do the same, but manually. I would advice you to use them when the amount of your javascript / css code is smaller - not many files
http://www.modify-anything.com/
You can use javascript minifier of ubercompute.com to minify your code, It will minify your javascript code upto 75% of their original version.
Try out this JavaScript minifier from fixcode.org.
It's a very effective tool to minify JavaScript
Import code via URL
import from file
copy/download output

Categories

Resources