Should we test the minified versions of our javascript files as we develop them, or is it an extremely low risk that the minified javascript does not differ in function from the un-minified version?
Running your test suites against them should be enough.
...
You do have test suites... right?
Run them through jslint before minifying them and if they pass that they should minify without a problem. The key here is to not forget a ; since minifying will remove all linefeeds. Also declaring variables helps the minifying process, but not doing so will not break anything by minifying.
I have not seen any of my scripts behaving differently so far after minifying them but sill i do test them before making them public just to make sure everything has been done correctly.
And you are supposed to sort of test it before using/making it public just to make sure that it works the way you wanted.
If you have done everything correctly in non-minified version, it should be not a problem.
It depends on what you minify with. Closure Compiler and YUI Compressor fully tokenize and parse scripts and tend to handle almost anything most browsers will accept. JSMin (particularly modified versions) are mostly reliable, but stay away from anything regex-based.
Agreed on svinto's advice.
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.
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 have a quite big JavaScript for HTML page for a device.
But it's a bit slow. I tried compressing JavaScript files but it's still not satisfactory.
So I was thinking, is it possible to make it as a Just in Time that is compiled converted to machine code and use it? (Hope my understanding is correct) I use a WebKit based browser.
Anybody please who have done this, please provide links to "How To" pages or info about the same.
Both Safari and Chrome do JIT compilation of Javascript already. In fact, the only browser in widespread use that doesn't is IE8 and earlier. This is one of the main reasons why IE8 is so much slower than the competition these days.
But reading between the lines of your question, my guess is that you're not quite understanding what JIT compilation is. JIT compilation happens on the browser; you don't need to change your code in any way at all in order for the browser to be able to do JIT compilation on it for you.
What it sounds like you're actually thinking of is bytecode compilation, such as Java does. This bytecode is effectively a half-way compiled language which is then itself JIT compiled when you run the program. If this is what you're thinking of, I can confirm that this is not an option for browser-based Javascript code.
Google have been toying with a technology called 'Native Client' (NaCl), which would allow you to provide compiled code to the browser, but this is not available yet except in development versions of Chrome.
In any case, compiling may make your code run quicker, but it wouldn't solve the fundamental issue of why it's running slowly, which is likely to be a far better thing to resolve. (even compiled code will perform badly if it has bottlenecks; compilation in itself doesn't magically make slow code better)
If you want to find out why your script is running slowly, I recommend using a profiling tool, such as the one built into Firebug or Chrome's Developer Tools. This will help you identify the parts of your code which are running slowly.
You could also try the YSlow tool, which can also give useful information on javascript performance.
You also state that you've compressed your script to try to get it to go faster. Compressing the script will help it to download quicker (because it's a smaller file), but it won't do anything for the speed that the code runs at.
Is it possible to run JavaScript code in parallel in the browser? I'm willing to sacrifice some browser support (IE, Opera, anything else) to gain some edge here.
If you don't have to manipulate the dom, you could use webworkers ... there's a few other restrictions but check it out # http://ejohn.org/blog/web-workers/
Parallel.js of parallel.js.org (see also github source) is a single file JS library that has a nice API for multithreaded processing in JavaScript. It runs both in web browsers and in Node.js.
Perhaps it would be better to recode your JavaScript in something that generally runs faster, rather than trying to speed up the Javascript by going parallel. (I expect you'll find the cost of forking parallel JavaScript activities is pretty high, too, and that may well wipe out any possible parallel gain; this is common problem with parallel programming).
Javascript is interpreted in most browsers IIRC, and it is dynamic on top of it which means it, well, runs slowly.
I'm under the impression you can write Java code and run it under browser plugins. Java is type safe and JIT compiles to machine code. I'd expect that any big computation done in Javascript would run a lot faster in Java. I'm not specifically suggesting Java; any compiled language for which you can get a plug in would do.
As an alternative, Google provides Closure, a JavaScript compiler. It is claimed to be a compiler, but looks like an optimizer to me and I don't know much it "optimizes". But, perhaps you can use that. I'd expect the Closure compiler to be built into Chrome (but I don't know for a fact) and maybe just running Chrome would get your JavaScript compiler "for free".
EDIT: After reading about what about Closure does, as compiler guy I'm not much impressed. It looks like much of the emphasis is on reducing code size which minimizes download time but not necessarily performance. The one good thing they do in function inlining. I doubt that will help as much as switching to a truly compiled langauge.
EDIT2: Apparantly the "Closure" compiler is different than the engine than runs JavaScript in Chrome. I'm told, but don't know this for a fact, that the Chrome engine has a real compiler.
Intel is coming up with an open-source project codenamed River Trail check out http://www.theregister.co.uk/2011/09/17/intel_parallel_javascript/
Jquery.com provide 2 version of jquery library. I always use Minified version because i never edit anything in jquery base file. but what is the use and purpose of another Uncompressed Code version? Does people edit main library file to get something?
If yes then if we edit anything in main file then we can't use google ajax library link.
Production (19KB, Minified and Gzipped)
Development (120KB, Uncompressed Code)
If you're using the minified version during development, browsers will tell you there's an error on line X, but line X might consist of hundreds or even thousands of lines of uncompressed code. This makes it very, very difficult to figure out what exactly caused the problem.
Developing against uncompressed code thus allows you to see what's causing problems and fix. Minified jQuery should always be used in production, and the core functionality of jQuery shouldn't be tweaked - that's what plugins are for.
edit 5/2014: Source maps have been implemented in many browsers to allow debugging of minified code. https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#source-maps
It just makes it much easier to read the source code of jQuery, especially during debugging to see what is happening with a problem in your application.
It's for Debugging (although I would argue that if you're using jQuery, you should be looking through the source to understand it).
In ASP.NET at least, when using the ScriptManager control, you can assign one script to use in Debug mode and another to use in Release mode, so using the uncompressed version in debug allows you to step through the source and figure out if an issue you're having is coming from there, but when you finally build the release, you'll use the minified and gzipped version.