![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
JSMin+ version 1.4
Version 1.4 of JSMin+ is available for download. Because we are still actively using JSMin+ at Tweakers.net we did make some minor improvements since I released version 1.3 for the public now more than 2 years ago, but I never felt those improvements warranted a new public version. Until now.
This week I received an email from MediaWiki informing me that they imported JSMin+ into their code base as a library and they suggested some code changes, asking me if I would consider including them in the public version. Because these changes made sense I hereby am happy to oblige
That still would have made this only a very minor release, so I decided to fix at least one other major problem that has been reported to me several times: the fact that JSMin+ was quite memory-intensive, especially when minifying large (eg combined) javascript files.
To fix that I moved part of the minification process to the JS parser itself where it can minify chunks of the parse tree which can be disposed after that. I made this change in such way that it is still possible to get a complete parse tree from the JS parser.
From a test I ran with the unminified source code of JQuery 1.6.2 memory usage went down from 40+MB to only around 8MB
Complete changelog for JSMin+ 1.4:
The latest version is available on http://files.tweakers.net/jsminplus/jsminplus.zip
You can read more about JSMin+ in the announcement post.
This week I received an email from MediaWiki informing me that they imported JSMin+ into their code base as a library and they suggested some code changes, asking me if I would consider including them in the public version. Because these changes made sense I hereby am happy to oblige
That still would have made this only a very minor release, so I decided to fix at least one other major problem that has been reported to me several times: the fact that JSMin+ was quite memory-intensive, especially when minifying large (eg combined) javascript files.
To fix that I moved part of the minification process to the JS parser itself where it can minify chunks of the parse tree which can be disposed after that. I made this change in such way that it is still possible to get a complete parse tree from the JS parser.
From a test I ran with the unminified source code of JQuery 1.6.2 memory usage went down from 40+MB to only around 8MB
Complete changelog for JSMin+ 1.4:
- Remove an empty statement and the closing ?>
(as per suggestion by platonides of MediaWiki: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92560) - Remove dynamic creation of OP_* and KEYWORD_* defines and declare them on top
(as per suggestion by platonides of MediaWiki: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92563) - Reduce memory footprint by minifying by block-scope (within the parser itself)
- Some more byte-saving improvements, eg:
- 100000 => 1e6
- return !foo => return!foo
- return -1 => return-1
- Some small performance improvements:
- split up handling of string literals by quotestyle (simplifies the regular expression used)
- change matching of numeric tokens to be more efficient
- JScript conditional compilation support is (still) not complete yet
- Performance can still be improved even more
- No support yet for variable-name minification
- No ES5 support
The latest version is available on http://files.tweakers.net/jsminplus/jsminplus.zip
You can read more about JSMin+ in the announcement post.
28-05 Adoptie, daar kies je toch zelf voor?
Comments
By
Spider.007,
Sunday 24 July 2011 10:28
Wow, the reduced memory usage is a very nice accomplishment! Also, mediawiki's inclusion of your library is a great confirmation of the quality of this library.
Thanks for this update!
Thanks for this update!
[Comment edited on Sunday 24 July 2011 10:28]
By
YopY,
Sunday 24 July 2011 10:42
I'd really really really like to see a big comparison between JS minifiers and such technologies (or make one of my own), comparing compression speed, size, performance of resulting JS (some minifiers change the actual code), ease of use, etc. In the last few years, there's been a huge increase in popularity for Javascript and, resultingly, tools - see Github.
By
Vold,
Sunday 24 July 2011 12:05
Awesome project, really cool that it is also being used for one of the biggest websites in the world! Just looked at the code, but I was wondering what your advised usage of this script is.
I assume you don't use this script in realtime, but do you have a so to say "deployment to production" script that once minifies all the .js files? Or maybe a cron job at specific intervals? And if so, is the performance that important? Because the impact of the script remains really small if it is used so rarely...
Anyways, keep up the good work.
I assume you don't use this script in realtime, but do you have a so to say "deployment to production" script that once minifies all the .js files? Or maybe a cron job at specific intervals? And if so, is the performance that important? Because the impact of the script remains really small if it is used so rarely...
Anyways, keep up the good work.
By
Erkens,
Sunday 24 July 2011 12:23
I use it during deployment, really nice to see this updated version. One of the reasons I use this minifier is that every function is on a seperate line, which makes debugging in a live situation not that hard!
By
crisp,
Monday 25 July 2011 01:05
Do note that MediaWiki is currently only using this library for it's JS parser to do automated syntax-checking. Afaik JSMin+ is the only existing (port of a) JS parser in PHPSpider.007 wrote on Sunday 24 July 2011 @ 10:28:
Wow, the reduced memory usage is a very nice accomplishment! Also, mediawiki's inclusion of your library is a great confirmation of the quality of this library.
Thanks for this update!
They have some home-brew minifier for JS, which is less efficient but a lot faster...
I think it depends on the use case which tool would fit best. I tried a lot of minifiers but couldn't find a decent one written in PHP at the time I wrote JSMin+. There was only a PHP port of Crockford's JSMin, but that tool dictated some code style that I couldn't fully agree with.YopY wrote on Sunday 24 July 2011 @ 10:42:
I'd really really really like to see a big comparison between JS minifiers and such technologies (or make one of my own), comparing compression speed, size, performance of resulting JS (some minifiers change the actual code), ease of use, etc. In the last few years, there's been a huge increase in popularity for Javascript and, resultingly, tools - see Github.
I know that JSMin+ does a better job at minification compared to JSMin, but it is around 5 times slower. Google Closure Compiler and YuiCompressor may be able to sqeesh out some more bytes (but I watch those projects closely
), but they also have more options such as variable name minification. Only downside (for me) is: those libraries are not PHP-based.Besides that I think it is very cool that I could put the Narcissus library written by Brendan Eich himself to good use
I actually don't recommend doing minification on demand at all. Javascript files, being normally static, should best be served from a server that's dedicated and tuned to serving static files.Vold wrote on Sunday 24 July 2011 @ 12:05:
Awesome project, really cool that it is also being used for one of the biggest websites in the world! Just looked at the code, but I was wondering what your advised usage of this script is.
I assume you don't use this script in realtime, but do you have a so to say "deployment to production" script that once minifies all the .js files? Or maybe a cron job at specific intervals? And if so, is the performance that important? Because the impact of the script remains really small if it is used so rarely...
We actually run a script when checking out our trunk repository to our staging server which checks for changed JS and CSS files and performs minification (and also combines certain files). Those minified files can then be pushed to production when we do a release.
So indeed, performance is not much of an issue for us; minification is done only once and only when necessary.
[Comment edited on Monday 25 July 2011 01:50]
By
jurp5,
Monday 25 July 2011 07:59
You've seen https://github.com/mishoo/UglifyJS/? It's a minifier using node.js which compresses even better, and faster! than closure compiler
By
crisp,
Monday 25 July 2011 09:39
It's not PHP-basedjurp5 wrote on Monday 25 July 2011 @ 07:59:
You've seen https://github.com/mishoo/UglifyJS/? It's a minifier using node.js which compresses even better, and faster! than closure compiler
I briefly looked at it, but there are some things that I don't really like. First of all the number of open issues (
). But secondly I don't like minifiers that actually change code (apart from syntax). Some of those minification tricks are known to have a negative performance impact. It also makes debugging more difficult.
By
s.stok,
Tuesday 30 August 2011 15:50
There is a PHP Port, but its still in development.
https://github.com/kbjr/UglifyJS.php
Nice to see there is a new version, I use it in https://github.com/roller...ork/Filter/cJSMinPlus.php
Variable-name minification is basically the only thing that is missing in JSMin+
https://github.com/kbjr/UglifyJS.php
Nice to see there is a new version, I use it in https://github.com/roller...ork/Filter/cJSMinPlus.php
Variable-name minification is basically the only thing that is missing in JSMin+
That's great, I have to stick for some time with JSMin because of memory issues, but now I think I can have another try with this one
Thanks for this great minification tool! I have written an extension - called scriptmerger - for the CMS TYPO3 (http://typo3.org) that utilizes this library.
http://forge.typo3.org/projects/extension-scriptmerger
http://forge.typo3.org/projects/extension-scriptmerger