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 10 years ago.
Between Yahoo! UI Compressor, Dean Edwards Packer and jsmin, which produces better results, both in terms of resulting footprint and fewer errors when obfuscating.
A great way to compare the best compressors is The JavaScript CompressorRater by Arthur Blake.
What you're usually interested in is the size after compressing with GZIP (you should configure your web server to perform the compression).
The best results are usually from the YUI Compressor or Dojo ShrinkSafe. The differences were so small that after a while I stopped comparing and I just use the YUI Compressor.
EDIT:
since the original time this question was asked, 2 new minifiers have been released. They're both usually at least as good as, if not better than, the YUI Compressor.
Google's Closure Compiler. Includes an aggressive advanced optimization mode that's sometimes applicable.
Microsoft's Ajax Minifier (search this page for "minifier")
EDIT 2:
UglifyJS, chosen by the jQuery team for the official 1.5 release
Better is a bit subjective here, since there are multiple factors to consider (even beyond those you list):
Compressed size doesn't tell the whole story, since an aggressive compressor can result in slower run-time performance due to the additional time needed to run unpacking code prior to browser interpretation.
Errors are easiest to avoid when you control the input code - judicious use of semicolons goes a long way. Run JSLint over your code, and fix any problems reported.
The style and size of the code itself will affect the results, of course.
And finally, it's worth keeping in mind that server-side gzip compression will always result in a smaller download than any code compression, although some code compression tools will combine with gzip more effectively.
My recommendation is to run the code you intend to compress through several compressors (an automated comparison tool such as CompressorRater helps...), and choose based on the results - remembering to test, profile and compare the actual page load times afterward.
Definitely check out Dojo Shrinksafe. It was reworked recently and apparently the performance has been improved.
Full disclosure, I'm behind this: http://www.toptensoftware.com/minime which does minification, obfuscation and a reasonable set of lint style checks. Currently it produces smaller output than Yui, not quite as good as Closure.
This is an old question and the Google Closure Compiler didn't exist then. I haven't used it yet, but it looks really good.
As a Mootools user, I notice that Mootools has replaced Dean Edwards' Packer by YUI Compressor. I also remember there was a discussion on Ajaxian.com where Julien (Compressor author) pointed out the areas where YUI Compressor did better. I used Compressor and have never seen any problem, but I have never studied to which produces fewer error when obfuscating.
YUI Compressor compresses more safely and compactly than Packer does. I believe Packer needs the JavaScript to be perfectly formed otherwise it will cause a JavaScript error when the script is loaded. Still, regardless of which you use, you'll get the biggest performance increase by Gzipping your file.
There's also a port of the YUICompress for .NET (which includes a build task for TFS) on Codeplex.
Related
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 9 years ago.
We are a small team of developers building a javascript application.
If we weren't using jQuery, we'd want to spend a lot of time making sure the code is cross-browser compatible, and we would run unit tests on all the platforms we supported. This is time-consuming, and adds to our workflow, or takes time to set up.
But, we do use jQuery. Do we still really need to do all that cross-browser testing?
I'm looking for some arguments for and against doing extensive cross-browser testing (i.e., using TestSwarm or something similar) if we already use jQuery -- a library that basically eliminates cross-browser issues.
Thoughts?
jQuery runs on all major browsers, but it always depends on the implementation and anything may go wrong, so it is always a good practice to test it across browsers.
Doing this you will be safer. 99% of the code will work correct but there is still a risk involved for 1% of the code and that 1% may creep critical bugs.
But, we do use jQuery. Do we still really need to do all that cross-browser testing?
Yes
I'm looking for some arguments for and against doing extensive cross-browser testing
Because jQuery might have quirks you might not know about, unless you are really updated with their builds, bugs and fixes.
jQuery might not have patched all differences.
As far as I know, there was this difference in the older versions because IE did not support changing the type of the input when the element was already created:
//IE:
$('<input type="text"/>');
//Other browsers:
$('<input/>',{
type : 'text'
});
jQuery does not patch everything.
This argument holds true as to why map() is patched, but not reduce(). A bug report was created for this, but most of the responders replied that reduce isn't required internally thus it was omitted.
jQuery, like other software, has bugs too
Because there might be some newer JS API that your team members might consider stable when they aren't. An example is querySelectorAll which works quite well already, supported in many browsers, but has quirks which are different from what you'd expect.
Just because you use a great CSS framework doesn't mean all layout problems have been solved. You still even do UI testing to make sure everything looks the same. Same logic should go for all languages, even JS.
How extensively you test depends entirely on your application. It’s a bit of a “How long is a piece of string?” question.
I would say that with jQuery specifically, I’ve encountered bugs in IE 8 and older, often due to invalid HTML, that haven’t presented in other browsers.
And, as #kinakuta’s comment pointed out, jQuery doesn’t cover every browser JavaScript API, or replace the language itself. I’d imagine it’s unlikely that every significant line of JavaScript you write in your application will be jQuery.
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 10 years ago.
I'm developing Desktop-Software with different OO-based languages. I haven't got in touch with web development since recently. I just started playing around with jQuery and jQuery Mobile to build simple web applications.
I noticed that my projects usually end up with a HTML-file as a base and a *.js file which contains the methods, eventhandlers etc. This somewhat feels like programming spaghetti code and I can't think of how this could work with more complex projects. (Reusability, Performance, ...)
Usual jQuery-Tutorials are just showing trivial examples which work well with the "all methods into a single script-file"-approach. I also read somewhere, that it is better to provide just a big file because it is faster to load just one file instead of a lot small files.
Can someone tell me how bigger jQuery-projects are structured and what the reasons for that are?
I'll try to break up your question into smaller parts:
"I noticed that my projects usually end up with a HTML-file as a base and a *.js file which contains the methods, eventhandlers etc. This somewhat feels like programming spaghetti code and I can't think of how this could work with more complex projects."
Sounds like your OO background has you spoiled. Javascript won't force you to use it's prototypal inheritance, and neither will jQuery. Nevertheless, it is there. Douglas Crockford wrote a piece about moving from a classical OO-centric inheritance to the prototypal equivalent: Prototypal Inheritance in Javascript
"Usual jQuery-Tutorials are just showing trivial examples which work well with the "all methods into a single script-file"-approach."
Yes, putting all your code in one file will work fine for a small website or web-app, but it doesn't scale.
However this is no difference from putting all your C method declarations in one header and all the code in one source file. My point being that you don't have too.
I'd recommend you look at a script loader like RequireJS as a solution to this problem. In worst case there's still nothing wrong with putting your script tags inline in your HTML code but this also doesn't scale well.
"I also read somewhere, that it is better to provide just a big file because it is faster to load just one file instead of a lot small files."
Well ... yes, but this is negligible in most cases. Even if you do see a drop in performance, why treat your development code as your production? Use a compression tool such as YUI Compressor to compress and merge your JavaScript. Smaller load times without the pollution.
Final piece of advice: jQuery is not going to help you solve your JavaScript architecture problems any more than a dictionary will help you structure a sentence. (In other words, don't rely on jQuery examples to teach you good JavaScript practices).
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 10 years ago.
I occasionally write JavaScript code. I am interested in minifying it for better performance, but I don't plan to spend to much time on that, especially in testing the minified result.
I found this online service:
http://www.lotterypost.com/js-compress.aspx
So a couple questions:
Is it reliable?
Microsoft AJAX minifier vs. YUI Compressor, what's the best option?
Any other similar online tool to recommend (and why is it better than the above link)?
Google's Closure Compiler
is an excellent Javascript minifier and compiler. It analyzes the code and reports the detectable errors. It removes redundant space and unreferenced code, and renames objects to shortest possible names. You just need to compile together all Javascript files that belong to one HTML page.
That link you post happens to be the one that I use too.
Use the MS AJAX Minifer. It's way better than the yui one. besides:
http://stephenwalther.com/blog/archive/2009/10/16/using-the-new-microsoft-ajax-minifier.aspx:
The Microsoft Ajax team (I work on
this team) has been using this tool
internally for a number of years. For
example, we use the Microsoft Ajax
Minifier to minify the Microsoft Ajax
Library before publishing it.
Well if you don't trust me, run your source code (if you don't have an actual source code to test, just grab the source at http://code.jquery.com/jquery-1.6.2.js) through both and see which is more "minified".
==
Google has the Google Closure Compiler but it analyzes your code and removes unreferenced code (to furthur reduce the size of the resultant file). However usually this is not what you want because even though the functions/variables are not referenced within that file, it may be referenced from your other js files that make up your site)
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 12 years ago.
For scripting on web browsers, the only option now is using javascript.
I wonder if Ruby ever could make it to the web browsers?
It's highly unlikely cause MS doesn't have any reasons for letting Ruby to become first class citizen, wouldn't that be bad for their current platform? I don't know how Apple sees it.
If Ruby can't be first class citizen in the browsers, how likely is it that a add-on could be installed on the browser, letting the browser execute Ruby also. In that way, we programmers could just use Ruby instead.
Your best bet is probably a "language converter" like:
http://rb2js.rubyforge.org
Honestly though I would just bite the bullet and learn Javascript. A plug-in could be created, but it would never catch on: businesses won't inconvenience their customers just so that their programmers can use the language of their choice.
I don't like JS that much. For a scripting language its way too much verbose, it suffers from bad design decisions that got into the ECMA standard... It has however some nice features which make it unique and powerful.
I wish the web was more agnostic with client-side languages, but its very unlikely, sadly.
If you want something that feels like Ruby you may try CoffeeScript. You write your code in CoffeeScript which then gets turned into JavaScript. It borrows a lot of ideas from Ruby and Python which makes a great mix.
http://jashkenas.github.com/coffee-script/
I am personally enjoying it very much.
It may not be in the near future or it may never be implemented as the browser scripting language. But people are playing around with that idea. Check out rubyinside.com, they seem to have a working demo. The last time I checked the demo page crashed the browser :(
But don't loose hope yet ;)
It's not exactly using Ruby as a replacement for Javascript, but you can run Ruby on Silverlight (and Moonlight, the Linux implementation of Silverlight).
No one can tell the future, but I'd say it's incredibly unlikely. Browser vendors aren't likely going to want to support multiple client side scripting languages (see the death of VBScript in the browser). Javascript fills the client side niche already so there's no reason to vendors to introduce a new language just so that there is an alternative syntax. 3rd party plugins aren't really a good solution either because users get no benefit from installing it (unlike something like Flash which can offer functionality that HTML/Javascript can't).
There are some Javascript libraries that try to emulate a Ruby style of coding -- for instance, JS.Class.
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.
I'm looking for a free JavaScript obfuscator. Would compression be enough? What tools would you recommend? Of course, I don't need military-style obfuscation, I need a simple way to prevent kiddies from stealing my javascript by looking at the source or by using something simple such as unescape().
Thanks,
Tom
Your problem is that no matter how much you compress it or hide it, eventually the browser has to interpret it. The best you can do is renaming all variables to meaningless random vars, and removing all comments and whitespace.
A few good tools:
http://www.dev411.com/dojo/javascript_compressor/
http://javascriptcompressor.com/Default.aspx
http://developer.yahoo.com/yui/compressor/
You can use /packer/
http://dean.edwards.name/packer/
As a rule of thumb, do not use a obfuscator that uses eval since this will slow down your page, use a compressor that doesn't. This will provide obfuscation for newbies, anyone else will not be deterred by any obfuscator anyway.
Most obfuscators will create a strings representing the code in the end and then use eval, this can be undone by a simple alert statements, whats the point?
If you want simple obfuscation and excellent compression, I can recommend the YUI Compressor from Yahoo.
Check out For those looking - http://javascript-reference.info/javascript-obfuscators-review.htm - pretty good overview of JS obfuscators
I will second the recommendation for YUI Compressor as well, works very well and can compress and obfuscate, also makes recommendations on javascript coding.
I vote for Packer as well. There are online versions, Standalone Versions, and even a Console Version that I use to Automagically pack my javascripts when I build my web apps.
Try http://digua.sourceforge.net.
http://www.javascriptobfuscator.com/Default.aspx
http://ajaxian.com/archives/utility-javascript-obfuscator