Our project has more than 300 JSP files and more than 200 JavaScript files. I'd like to do some cleanup, removing unnecessary JS files. Even if the JSP includes the JS maybe none of the functions are used. The goal is to reduce both complexity and time needed to load the page. My IDE is Eclipse. Giving the dynamic nature of JavaScript I guess it will be hard or even impossible.
If it's conceivable that the application can be tested with a lot of coverage (i.e. going through every dialog, error message, and situation imaginable) you may be able to work with your access log files - compare the list of JS files to those fetched after period x of heavy use.
An alternative implementation of this would be setting up a "honeypot" (see my answer to this question).
Both these methods are of course "soft" in that their quality relies in how throroughly the application is actually used during testing time.
If you have any way of grepping all script references, that would be preferable. Maybe you can do a global search on {anything}.js, that would match most ways how to embed a JS file.
To find out what functions and javascript files are used in a project, you need code coverage tools, like JSCoverage or Code coverage for Firebug. These tools will return the functions used and the files used. Using these with an automated test suit like the Selenium or randomized testing should give you a fairly good idea which files are loaded.
If the files are loaded dynamically, you can also use Firebug or Fiddler to log the requests for the JS files.
Unfortunately if you want certainty, not just extremely high likeliness that you get with the above tools, you would have to generate a calling graph for your entire webapp, maybe using a Javascript Compiler, like Rhino...
Related
I am using jquery fileupload plugin and it has 7-8 js files which it loads.
Now others developers are also working on site and sometime it cause confusion and difficult to find which js file is used where.
So i am thinking if i can combine 7 files in one file so that i can know that thats my file
Try this to compile your javascript file or code.
http://closure-compiler.appspot.com
While possibly overkill in this particular case, it might be worth checking out grunt. It will let you keep your files divided into multiple files for when you are working on them, and as soon as any file change compiling, minifying and combining them into a single/groups of files as desired, while also allowing you to define the load order of your code.
It requires some setup the first time you run it (which you can later use as a template) but greatly improves the process of combining/minifying files, and also has support for processing coffescript and sass among others, as well as writing unit tests for your code.
I use Rake to compile Javascript (and SASS to CSS, as well). It minifies the files in a unique JS. It's written in Ruby, but it's easy to configure and it works very fine.
But if more developers are working on the same code, another good idea I strongly suggest is to to use a SVN (sub-version control system), as TortoiseSVN or Git. This will allow many developers to work on the same source files, without losing any change.
This may be a dumb question for web guys. But I am a little confused over this. Now, I have an application where I am using a couple of Javascript files to perform different tasks. Now, I am using Javascript bundler to combine and minify all the files. So, at runtime there will be only one app.min.js file. Now, Requirejs is used to load modules or files at runtime. So, the question is if I already have all things in one file, then do I need requirejs? Or what is a use case scenario where I can use requirejs and/or bundler?
Please let me know if any further details are needed.
Generally you only use RequireJS in its loading form during development. Once the site is done and ready for deployment, you minify the code. The advantage here is RequireJS knows exactly what your dependencies are, and thus can easily minify the code in the correct order. Here is what it says on the RequireJS website:
Once you are finished doing development and want to deploy your code for your end users, you can use the optimizer to combine the JavaScript files together and minify it. In the example above, it can combine main.js and helper/util.js into one file and minify the result.
This is a hotly contested issue among many proficient javascript developers. Many other languages have a "compilation" phase where the entire program is bundled up for deployment (JBoss's .WAR files come to mind). Programmers that come from more traditional backgrounds often favor this approach.
Javascript has seen such growth in recent years that it is difficult to chart exact best practices, but those that appreciate the more functional nature of Javascript often prefer the module loading approach (like require.js uses).
I wrote Frame.js which works much like require.js, so my bias is towards the module loader approach.
To answer your question directly, yes, it is one or the other.
Most that argue for packing your scripts into a single file believe it enables more compression and is thus more efficient. I believe the efficiency advantages of packaging are negligible in most cases because: (1) module load times are distributed over the entire session, (2) individual modules can be compressed to nearly the same percentage, (3) individual modules can be cached by the server and routers separately, and (4) loading scripts only when they are needed ultimately allows you load less code for some users and more code overall.
In the long run, if you can see an advantage to dynamic script loading use it. If not, bundle your scripts into a single file.
It depends on your application. If you're making a server-side app with only modest javascript (less than 100kb minified) then go for total bundling, you're probably going to be fine.
But if you're making a javascript app and have a ton of code in it, then your needs are going to be different.
For example, in my app I bundle all the core files. There's jQuery, underscore, backbone, my main app files, my user login system, my layout system, my notifications and chat system, all are part of my big initial file.
But I have many other modules as well that isn't part of the initial bundle, that are loaded after those.
The forums, the wiki, the wysiwyg, color picker, drag/drop, calendar, and some animation files are part of the second category. You need to make reasonable decisions about what's commonly used and needed immediately vs what can be delayed.
If I include everything immediately I can get above a meg of javascript, which would be insane and make the initial boot unacceptably slow.
The second category starts downloading after initSuccess event fires from the initial file.
But the second category is more intelligent than the first in that it loads what's more important first. For example if you're looking at the wiki it'll load the wiki before it loads the color picker.
I did find a very interesting tool for identify unused css definitions in a web project.
http://www.sitepoint.com/dustmeselectors/
Are there similar tools also for javascript projects?
P.S.
I know there is no program for deterministically finding unused code. But I am looking for a report to identify possible unused code. Then the last decision will always be your own.
Problem is there is no way to be really sure. Suppose the following:
The initial HTML site is practically empty. There is a lot of JS code though, which seems to be unused.
OnLoad, a function is called which launches an AJAX query to the server. The server returns a lot of HTML code, which is the body of the site. This body contains lots of JavaScript functions.
The initial body is replaced with the body received via AJAX. Suddenly, all code is used.
Static analysis utilities are therefore useless. I do not know whether there exists a browser extension that marks all JS usage from a running browser though.
You can try using tombstones to safely locate and remove dead code from your JavaScript.
https://blog.bugsnag.com/javascript-refactoring-with-bugsnag-and-tombstones/
In order to find the unused assets, to remove manually, you can use deadfile library:
https://m-izadmehr.github.io/deadfile/
It can simply find unused files, in any JS project.
Without any config, it supports ES6, JSX, and Vue files:
The one that comes to mind most quickly is Javascript LINT (http://www.javascriptlint.com/) and JSLint (http://www.jslint.com/).
Beware though: the latter hurts your feelings.
In my project each page has a bunch of dependent Javascript and Css. Whilst developing I just dumped this code right into the page but now I'm looking to clean it up...
it appears that the general approach out there is to package all the Javascript/CSS for an application into two big files that get minimised.
This approach has the benefit that it reduces bandwidth since all the front-end code gets pulled in just once from the server... however, I'm concerned I will be increasing the memory footprint of the application by defining a whole ton of functions for each page that I don't actually need - which is why I had them on a per-page basis to begin with.
is that something anyone else cares about or is there some way to manage this issue?
yes, I have thought of doing conditional function creation since I need to run code conditionally for each page anyway - though that starts to get a bit hackish in my view.
also, is there much cost to defining a whole ton of Css that is never used?
Serving the javascript/CSS in one big hit for the application, allows the browser to cache all it needs for all your pages. If the standard use case for your site is that users will stay and navigate around for a while then this is a good option to use.
If, however, you wish your landing page to load quickly, since there is a chance that the user will navigate away, consider only serving the CSS/javascript required for this page.
In terms of a performance overhead of a large CSS file - there will be none that is noticeable. All modern browsers are highly optimised for applying styles.
As for your javascript - try not to use conditional function creation, conditional namespace creation is acceptable and required, but your functions should be declared only in one place.
The biggest thing you can do for bandwidth is make sure your server is compressing output. Any static document type should be compressed (html, js, css, etc.).
For instance the jQuery Core goes from approx. 90KB to 30KB only because of the compressed output the server is sending to browsers.
If you take into account the compression, then you have to create some mammoth custom JS includes to really need to split-up your JS files.
I really like minifying and obfuscating my code because I can put my documentation right into the un-minified version and then the minification process removes all the comments for the production environment.
One approach would be to have all the shared javascript minified and compressed into one file and served out on each page. Then the page-specific javascript can be compressed/minified to its own files (although I would consider putting any very common page's javascript into the main javascript file).
I've always been in the habit of compressing/minifying all of the CSS into one file, rather than separate files for each page. This is because some of the page-specific files can be very small, and ideally we share as much css across the site as possible.
Like Jasper mentioned the most important thing would be to make sure that your sever is GZIPing the static resources (such as javascript and css).
If you have a lot of javascript code you can take a look on asynchronous loading of js files.
Some large project like ExtJs or Qooxdoo have build in loaders to load only required code, but here is a lot of libs which simplify this, and you can use in your project (e.g. head.js, LAB.js).
Thanks to them you can build application which loads only necessary files, not whole javascript code which in case of big apps can be a heavy stuff for browser.
When building, or "on the fly" (perhaps with caching) when the users request pages.
And what are the dis/advantages of each.
When the site moves from dev to the live server.
I always have an uncompressed version of the JS on the dev server and a minimized version on the live server.
The advantage of that is when developing i can run into JS trouble and fix it very simply, but i need to run each changed script through a minimizer, but for me its not that much.
When building or deploying to a stage environment is a good time to compress javascript. That way you will have a chance to test it in the stage environment and catch any errors that could occur.
Occasionally, there are errors that do come up when compressing. You may want to include a command-line version of jslint that runs before compressing, to make sure that the js passes. That will minimize, but not eliminate, all compression errors.
I'd imagine that on-the-fly would be an unnesessary unless you were adding dynamic data to the JavaScript (in which case there are better ways around it). IT's just a needless expenditure that will only slow down the page load.
Personally, I'd do so when deploying/building the app, it's a one-time thing really.
I'd say you have the js files as you'd code them in source control, when you kick off an automated build that's when, as part of your build script, it runs all the javascript files through a compressor. This way when you deploy it to a test / staging environment you've got the latest script but also compressed for performance testing and as they would be once they go to production.
I agree that on-the-fly is probably not really necessary (and eats up some cpu cycles) if the JS does not change.
There might be some middleware involved though which can check if the JS has changed and compress it only if requested (and maybe even group various JS files into one resulting one).
A good thing when deploying might also be to add some time stamp or random string as parameter to the JS link (e.g. .../scripts.js?t=cdkjnsccsds7sc8cshcsjhbcs). That way when the JS changes you use a different string and there will be no caching problems because it's a new URL. Same for CSS.