10 Checks Before Launching Your Javascript

Inspired by the the article 15 Essential Checks Before Launching Your Website a small list of simple checks to a avoid unnecessary errors when getting your js code in production.

It does not contain the plain good old best practice rules on how you write your js code but these checks are mainly about code snippets that help you develop and debug your code in a fast and easy way that should not be around in the live version.

1. check for console statements (console.log, console.startTime....)
2. check for debugger statements
3. check your outcommented try catch statements
4. check for large outcommented old code fragments. If you are at the stage of going live this might be the time to get rid of it.
5. look for fixed url's which might work in the development environment but not on the production server
6. if you are using google maps make sure you have an api key for the live server
7. check for credentials in your comments or code (like usernames and passwords)
8. when using javascript libraries or frameworks make sure you include the minified production version and not the fully commented debug version.
9. off course the same goes for your own js files
10. and this last check works for me personaly: check on the "TO DO" string in the js code. When I still need to do some work on a part of the code I always flag it with a //TO DO comment.

This list is probably far from complete. Anybody any suggestions?

Some performance gain almost for free!

I am currently writing tomsplanner.com (you can check it out at tomsplanner.com).

And I can tell you developing RIA's is mainly about three things: performance performance and performance.

Today I stumbled upon this trick: http://yuiblog.com/blog/2008/07/22/non-blocking-scripts/

I didn't know it. What an easy way to gain some performance! It is almost as if you get some for free :o). It made my day.

Avoid default drag and drop behaviour in FF3

Fierfox 3 offers the user the possibility to drag and drop images around on the pages by default. Which is nice.... I guess. But this behaviour can mix with drag and drop routines written in javascript. So how to cancel the default drag & drop in Firefox 3?

document.addEventListener("draggesture", function(event){event.stopPropagation()},true);

or if you are using jquery: $(document).bind("draggesture",function(){return false})

I haven't seen any mention of this on the net so far so I thought is was worth mentioning it.

(For IE use $(document).bind("drag",function(){return false}))

(5) 4 reasons that make IE a better browser than Firefox (from the webapplication developers perspective)

- the unbeforunload event gives you the chance to warn the user when he/she leaves the page without saving his/her work.
- the contenteditable property of almost every element.
- direct access to the clipboard so you can actually implement a real cross page/document copy and paste functionality
- you can programaticaly open the 'save as' and the 'open' dialogs of the browser for saving data on the harddisk (later this year I will write a more detailed post on this).
- printing! Printing is sloppy in all browsers but IE7 (I don't know how IE8 is doing). When you print pages they seem to get rerendered by a totally different process then the process that renders the page for the screen. And this separate rendering process is full of nasty little bugs in every well known browser but IE7. With IE7 you actually get the feeling that it prints what you see on the screen.

Note: these are just 5 reasons that make IE a better browser than firefox. I am not saying that IE is a better browser than FF. There are a ton of reasons why you might consider firefox to be a better browser then IE. But to me it always seems possible to work around these bugs and quirks of IE with a bit of creative programing. But the above mentioned features can't be implemented by any amount of javascript programming in FF and that leaves you with... ehm nothing or at least less features for the FF user.

PS i know you can work around the lack of the contenteditable property in FF by using iframes and designmode... but editable content seems to me in the current time such a trivial option that I can not believe it is not implemented in FF yet.

performance json

Transformation of a big extensive javascript object to a json string can be slow. Working on tomsplanner I found that the generic functions to do such a thing get to slow in IE6. So I wrote a custom stringifier for the tomsplanner json-schema.

The result is that instead of 2413 milliseconds (using json2.js from json.org) it now takes 70 milliseconds to stringify a standard tomsplanner javascript model in IE6. In Firefox it takes 17 miliseconds instead of 1392 miliseconds.

Conclusion: if you work with big javascript objects you want to pass via json and performance is an issue then it really pays off to build your custom stringifier (especially because it is pretty straight forward and easy to do). Note: in tomsplanner the json will be checked for code injection so in my custom version I keep the security checks to a minimum.

The test page can be found here

Conflict jQuery and JSON

Douglas Crockfords json.js and John Resigs jquey.js conflict with each other. This is caused by a flaw in Javascript that is described in this article: http://yuiblog.com/blog/2006/09/26/for-in-intrigue/

So what do you do... Both libraries are really well written. and I haven't found any decent alternatives for Douglas json or Resigs jquery. So correct json or correct jQuery?

Of course the for..in loops in jQuery should be fixed. But fixing json.js is a more pragmatic aproach of the problem. Fixing json.js is a lot easier then fixing jQuery and more importantly json.js will have probably far less new versions and releases as jQuery. So the effort to stay up to date will be a lot smaller.

The adjusted version can be downloaded: json-noaugmenting.js

bug in IE7 when you change position of elements when pagezoom is used

In my humble opinion the pagezoom in IE7 is one of the most underestimated improvements of IE. Okay it has its flaws but it is a lot better then just resizing font-sizes. And imagine what you can do with it... now you can actually zoomin on the complete user interface of an application. I haven't seen any desktop application yet that can do just that.

But this pagezoom functionality also turns out to be one buggy $#%%^&$. (sorry for that)

What's wrong?
Just zoom your page to 125% and dynamically reposition an element with text in it. IE7 mispositions the text completely and it does it in a pretty random way. When you resize the browser window, after repositioning your element, IE7 will force some kind of redraw of the page and the problem will be corrected.

This a test page before repositioning:







this it what happens after repositioning the div 200px to the right:







You see what happens?! Even the text in the button is not rendered well!

Then resize the window:

And voila... all is fine....

For an working example click here. (don't forget to set the zoom level of the page)

What does that mean?
This makes for example drag&drop in IE7 within a zoomed page almost impossible.

The solution?
You tell me. I am still looking, i have tried a lot of options. The weird thing is that I haven't found any mention of this problem on the net. All the well known libraries don't seem to have a solution. I have checked YUI, mootools, pkk's new drag&drop script and backbase.

So if you have any idea let me know as soon as i find something I will publish it here.

added 14-8-2007 17:21
okay i have something that works... it is really ugly and needs to be improved (broswer detection, pagezoom detection, values relative to page) but it is a start:

function shakeItUp(){
document.getElementsByTagName("body")[0].style.height="10000px";
window.scrollBy(0,6000);
window.scrollBy(0,-6000);
document.getElementsByTagName("body")[0].style.height="auto";
}

After repositioning your element just shakeItUp()

click here for an working example

Logging in the console of firebug without errors in IE

In some cases the console in firebug is really helpfull. For instance when you are debugging mouse-events. The downside of using "console.log()" is that it triggers errors in IE. But there is a really simple sollution for that problem. Include the folowing line of code in one of your js scripts and no more errors in IE:

if(!console){var console = new Object();console.log = function(){}}

This snippet is tested in IE7 and IE6

update 13-11-2007: or use firebuglite: http://getfirebug.com/lite.html