As a javascript developer I usually end up writing a lot ofcode/classes and organized into several different files and this requires aproper file structure. Nothing new of course, but being the application I’mworking at the moment written completely in javascript and having reached morethan 200 js files and around 60k~ lines of code(extjs based single page web app), this gives you an idea on the scale and importanceof organizing properly the code into classes and namespaces and mostimportantly the need for optimization of the code.
I’ve started building this app following Saki’s advices and after 1 year of development it proved to be a successful choice,as they allowed me to architect the code in a fully object oriented way, but Iended up with loads of files and performance on loading them in the browser wasvery poor or at least something that could be improved, and the solution was simple:use a server side script that would create a unique response out of a list of filepaths that would also define the order of inclusion, cache the response forsubsequent requests, and serve it as gzip for browser that can handle it. I’ve usedfor this purpose the Http handler developed by Omar Al Zabir that you can find here.
It works very well and I was able to save 85% of thebandwidth just using gzip, and into a unique request...a greatachievement! But now there is anotherissue...debugging the code. The application is written in C# and the javascriptfront-end loads the data in json format from a Rest based API developed withWCF, so the IDE of choice here is Visual Studio of course. The Visual Studiodebugger also works very well and I use it extensively beside firebug, and thefiles debugged are the same files that are loaded in the browser...if thebrowser loads the js through the http handler and not the physical files, then thedeveloper might incur into trouble with code cached by the http handler which mightnot necessarily be the latest version...so to avoid this I use the http handleronly on production and never while developing, unless for testing purposes, andthis is achieved with a small c# script and a flag on the web.config.
Great! On production everything seems to be workingproperly, but I’ve realized that I could go a step further and compress thecontent of the response, stripping out unnecessary comments and whitespaces andas soon as I found a C# port of the great javascript “filter” jsmin written by DouglasCrockford, I’ve immediately integrated it in the project and I discovered thatI could save another good 30% out of the gzipped version of the javascript!!
Douglas Crockford created another amazing piece of software whichis called jslint which is “...aJavaScript program that looks for problems in JavaScript programs”. Testing thejavascript code we write against jslint not only allow us to make sure thateverything will work once the code is minified with jsmin, but will also get usused to write better quality code that will be easier to mantain and understandby other developers...Brilliant!
But how can we integrate this into our development process inan automated way? we need some kind of tool that will tell us if the code is corrector not, the perfect tool would check for problems during compilation of the solutionand tell the file name and line number and a description of the problem prettymuch like visual studio does for c# code
...and here comes Jslint.VSVisual Studio addin!
It does everything stated above, the only issue being that it’snot something you have by default on the solution, it’s a visual studio addinthat needs to be installed manually on the developer machine and activated bythe user. It works pretty well and can be integrated in the build, it gives youa list of issues that you can double click on and go straight to the line wherethe problem is, with a description of what needs to be fixed...this is justgreat, I wish I had known this addin before, when started to write thisapplication, so I wouldn’t have to run through the thousands of issues that jslintfound on the current codebase!! Yes, there are plenty of small syntax errorsand as Douglas warns “JSLint will hurt your feelings” and it does, but once thoseissues are fixed you are 100% sure that your code is syntactically perfect.
I’m a big fun of Douglas Crockford and I’m sure a lot ofother javascript developers are, so if you haven’t does so, watch his lessonson YUI Theather or/andread his book Javascript:The good parts and use his tools to write better javascript code...
I hope you find this article helpful.