I'm using the RequireJS Optimizer on a project of mine and, by default, it uses UglifyJS. However, I was encountering an error ('anim' is undefined) when running on IE and Opera. Switching to the Closure Compiler with no other configuration change, just sticking to defaults, makes the problem go away.
How can I get an effective diff of the optimized output these two tools produce?
I don't mean to compare the capabilities of the two, either way is fine with me, but this may help point out a bug in one or the other.
First you'll need to merge each minifier's output to single line in case it adds newlines to avoid some obscure old browser bugs (at least GCC does). Then you can use visual diff utility that highlight changes inside single line between two compared variants. At least meld and winmerge have this functionality. Most other should have it too.
Run both through closure compiler whitespace only mode with pretty printing enabled. This will make it easier to isolate the differences.
Related
I have herd V8 compiles "hot code" optimise javascript performance. Is there any way I can tell what code has been compiled and what code has not?
First and foremost you will need to profile your code in the Profiles tab of the Javascript console in Chrome to see what is worth testing. If a function, module, or whatever you are trying to test does not take up much time, it won't be worth your effort.
V8's JIT is going to make assumptions about your code, if those assumptions are true the code will be lightning fast. If not V8 will deoptimize that code as your program continues. Here is a for instance from my own tests. In the code below I was testing a merge sort function I had written.
console.time('order');
msort(ob);
console.timeEnd('order');
The first run of 60000 random numbers completes after 8ms, and all of the following jump up to around 16ms. Basically the JIT has issues with something I wrote so it recompiled my code. I have seen the exact opposite occur where code jumps to twice as fast. If you want to look at it, this is not the exact version, but one using es6 module syntax.
https://github.com/jamesrhaley/es2015-babel-gulp-jasmine/blob/master/src/js/mergeSort/mergeSort.js
Also if your code was not worth optimizing, then it won't be optimized to begin with. Here is a couple of links that helped me improve my speed when writing js.
https://www.youtube.com/watch?v=UJPdhx5zTaw
https://www.smashingmagazine.com/2012/11/writing-fast-memory-efficient-javascript/#so-how-does-javascript-work-in-v8
If you are willing to build a standalone version of v8, you can just run the shell as follows: d8 --trace-opt foo.js (you might also want to deploy --trace-deopt, since your code might get deoptimized (and then reoptimized again..)).
Another useful option is --print-code which will let you see all the versions of machine code for all the functions which were compiled although this one is probably an overkill. Also there is --print-opt-code.
And lastly use d8 --help to see what other useful options v8 can take.
There seem to be a number of differences (beyond performance of course) between both browsers when using Javascript. I am not even sure those are bugs or indeed different evaluations. In my applications (large, complex IDEs) I noticed here and there that Chrome is doing things different:
Array::indexOf and sorting appears different (hard to isolate for me)
scripts dealing with blur and focus seem to be different
a number of other minor issues with CSS
some other issues I can't remember of right now. The point of this post is to figure out what's different, nothing else :-)
I am also not really sure that the Chrome differences are really my faults and so I was wondering there things to know about Chrome vs FF when it comes to Javascript. My test-units do run all fine except in Chrome...
I did search a lot but I couldn't find any recommendation, guide or simple cheat list; possibly some folks here know better :-)
(ff/chrome version doesn't seem to matter)
thanks!
This is a very large question as each are built on different frameworks and therefore support functions differently, especially once you start going back a few versions.
But here is a simple page that lets you dig into the differences of each.
http://caniuse.com/#compare=firefox+42,chrome+47 (change versions to whichever you want)
This is a small portion and you can already see there are too many differences for anyone here to list.
In addition to canIuse, there's also kangax's compatibility tables. However your question appears to be geared more towards an under-the-hood implementation comparison, I can't help you there. Anything not in the spec (or marked as implementation-defined) is fair game: for instance object property order is not guaranteed but both seem to maintain insertion order when iterating via for...in.
Is there a version of quickcheck that works for Javascript and that is well maintained? I have found several such as check.js and claire, but none of them seem to support shrinking of failing test cases, which has always struck me as the most useful part of the whole problem.
I'm creator of jsverify. I'll try constantly to make it better, bug reports and feature requests are welcomed.
There are also a list of other javascript generative testing libraries in a readme. So far I haven't found any other good alternative to the jsverify.
I recently released https://github.com/dubzzz/fast-check
I built it in order to answer several limitations I encountered in the existing quickcheck implementations in JavaScript.
It comes natively with a shrink feature which can shrink even combination of arbitraries (the frameworks I tried were failing on oneof like arbitraries).
It also can generate large objects and arrays.
By default it tends to try smaller values first in order to detect trivial edge cases while it covers all the possible inputs in next runs.
Lots of other features are on-going or already available :)
Cheers,
Nicolas
I wrote quick_check.js, which has a nice library of generators. Shrinking is not there yet, but is planned.
There seems to be a dearth of good quickcheck-like testing tools in javascript. However they are to be better supported in typed languages, and in fact you can write your tests in one of those languages if you wish.
To avoid dealing with runtime interop, I'd recommend going with a language which compiles to JS and runs on node.js (eg: Purescript with purescript-quickcheck), or a java-based language using the Nashorn engine provided in Java 8, for example ScalaCheck. You could even use ghcjs and the original flavor of the quickcheck library!
I am playing aorund with using LESS along with respond.js to streamline the development of a new site. Both LESS and respond are quite simply neat. However, with LESS in IE I have run into many problems.
For starters in IE8 mode my IE10 reported that id did not understand "map". No problems, I wrote up an Array.prototype map extension. Then it said that it did not understand isArray, once again in IE8 mode. Prototype extensions to the rescue again. Now it comes back saying something along the lines of SyntaxError: Invalid operand to 'in': Object expected
I am not in fact aware of what in might be but in any case I cannot keep adding adhoc prototype extenions on the fly in the hope that things will eventually settle down. Either LESS is unusable with IE or else someone here can point me to all the fixes needed to make it work.
Answer for your question:
First of all, LESS client side compilation is supported only in IE9+.
You could probably fix this using shims and polyfills for ES5, like these.
But please, don't.
What you should probably do (and forget the first part):
However, despite of really good caching mechanisms provided by the LESS compiler (eg. using localStorage to preserve generated code) using it i production isn't considered a good practice.
GruntJS and Bower.io work in the console, but are relatively easy to configure. Basically, you set them up once and forget they've ever existed:)
Livereload provides you with a GUI and it's incredibly easy to use.
I used GruntJS for frontend development with backend developers working with PHP (CakePHP, Zend, Laravel) and it made our lives much, much easier :)
It seems much more reasonable to streamline your frontend development workflow using a task runner like GruntJS or Brunch.io or install Livereload. These tools will monitor the file changes and generate a new CSS file on every save (and also, reload your CSS on the fly).
You can install GrunJS with watch and LESS plugins and keep is very simple this way. You could even use LESS Node.js package installed globally to the job.
I am looking for way (preferably and online site) to a reverse Uglify of some javascript. The Website: http://jsbeautifier.org/ is great for minifed code, but it is does not do a great job for ugly stuff.
There is this awesome online tool, JSNice, that makes a great job of finding names to obfuscated variables.
We make even obfuscated JavaScript code readable.
We will rename variables and parameters to names that we learn from thousands of open source projects.
Furthermore, often we are also able to guess or infer type annotations.
Chrome dev tools ability to Pretty Print
All you need to do is to click the { } icon on the bottom toolbar to activate this feature. Of course, the names will still be obfuscated (depending on what program minfied the JavaScript in the first place), but you will at least be able to set break points and debug the code.
Source: Tip #2 in this archived article.
Depends on what options you used when you uglify your code. If you just remove the line breaks, then Chrome dev tools will be able to do a great work as sirinivas explained. But if you mangle the code, then there is no way you can get the exact previous code. (in uglifying var logngvariable = a + b; becomes var c=a+b;. there is no way a tool can figure out the previous name logngvariable )
On the otherhand if you want an un-uglified code you may not uglify it at the first place... :)