Category Archives: micro tutorial

Storing JavaScript objects in html5 localStorage

There is a rising new age of HTML5, which comes with very nice features as video tag and localStorage. What localStorage is? In fact we have been waiting for long time to have something that give us the power of storing more and more on the client side. That’s because the net is becoming larger and therefore heavy.

Imagine if you have the possibility to store large JSON returned from an AJAX call on the client. That’s now reality with the localStorage object in HTML5 and it can be accessed with something like this code:

localStorage.setItem(key, value);
alert(localStorage.getItem(key));

Can we store entire objects?

Yes there is a way extending a bit the logic of the code above. The localStorage in fact stores only strings, but what about arrays and objects. You can additionally use JSON global objects and its two methods – stringify and parse:

var a = JSON.stringify({name:'obj'});
alert(JSON.parse(a));

Do browsers support all that?

Of course … not! localStorage is supported by Firefox 3.5+, Chrome 2+, Safari 4+ and MSIE 8+. The solution is not to rely on browser version, but to check for object existence, and than to combine both techniques:

localStorage.setItem('a', JSON.stringify({ name : 'obj' }));
alert(JSON.parse(localStorage.getItem('a')));

How to detect a variable existence in JavaScript?

Preface

After reading one of the latest posts from Stoyan Stefanov’s blog – phpied.com I stumbled upon an interesting construction in JavaScript describing how to check an object property existence. I’m going to cover this case using as an example the console object, which comes with the Firebug enabled, and I think it may be very useful, just because this object is widely used, but doesn’t exists over all the browsers, even under Firefox when Firebug is disabled. This construction is known as the IN statement and it looks something like that:

property in object

which I’m going to cover later in details.

How you detect a variable existence?

There are three main ways to detect the existence of a property I see in my practice.

1. The most widely used:

if ( console ) { ... }

2. The second and more professional one:

if ( typeof console != 'undefined' ) { ... }

3. And finally the third and most unknown:

if ( console in window ) { ... }

Of course two of them are wrong! Which one should be changed?

Is everything working correctly? No!

Lets see how they are working. First of all I’m going to test all of them on Firefox 3.6 either with enabled and disabled Firebug, just shouting with old school’s alert().

Now the first one using the IN statement:

if ( console in window )
   alert('object exists!');
else
   alert('object doesn\'t exists!');

With Firebug disabled the answer is … nothing! No alert! That’s because the syntax is wrong. There’s an error within the IF statement. We should modify a bit the first row like that:

if ( 'console' in window )
   alert('object exists!');
else
   alert('object doesn\'t exists!');

Now everything’s OK. With a disabled Firebug the answer is: “object doesn’t exists!”, and after enabling it, normally the “object exists!”.

Lets move on the next example:

if ( console )
   alert('object exists!');
else
   alert('object doesn\'t exists!');

With Firebug enabled the answer is as we expect: “object exists!”, but after disabling it yet again – nothing?! Why’s that? Because the console object doesn’t exists anymore and the IF statement doesn’t return true or false, but simply crashes. How to modify the code? Simply by adding a window.console instead of console.

if ( window.console )
   alert('object exists!');
else
   alert('object doesn\'t exists!');

Than the answer is: “the object doesn’t exists!” after what we expected!

The third method is the mostly used, just because it’s completely clear what’s the goal of the IF statement:

if ( typeof console != 'undefined' )
   alert('object exists!');
else
   alert('object doesn\'t exists!');

In both disabled and enabled Firebug the answer is as expected!

Now the IN statement may be used if not for the console, but for checking the existence of a property of within an object.

JavaScript optimization. Lazy loading.

Javascript files are too big!

Yes that’s the reality and when they become more and more bigger the web pages becomes to be irresponsible. The bitter reality is that you load any functionality that slows down the first user impression, but is needed only when you click on a button and so on. That’s a problem because you can load only that chunks you need in the beginning and than after a few seconds to load everything else. Some web applications have more than 100K of javascript which become really bad.

Separate logic

What you can do is to separate the logic into one or more files. Even when the user thinks everything is on the page and he can interact with the application and than to start to load the rest of the functionality.

That’s a pretty good technique. Nobody can start interacting on the 5th second of the load process. Usually the user looks at the interface starts to explore the app and after approximately the 10th second he start interacting with the page.

Lazy loading

There are various techniques of loading JavaScript on demand. So I wont cover it, but that pattern of loading it latter when needed is really powerful.

Optimizing OpenLayers. Speed up markers load time!

Icons in OpenLayers!

They chain of classes used to construct and make one single marker in OpenLayers is a bit difficult to follow, but isn’t impossible. There are three main classes in three files:

Markers.js
Layer/Markers.js
Icon.js

That’s why after tracking the code in them I noticed the library’s using appendChild in a line like that:

this.div.appendChild(markerImg);

The problem is that if you’ve a loop with probably hundreds of iterations this is really slow. What I intent to do is to return only the generated code as string, or instead of returning the element, I can return the string. Than concatenate it after the loop’s over.

That will be way faster!

OpenLayers extreme optimization. Cut, compress and deploy!

Make it really faster!

Following several posts I wrote recently, this one will describe you a simple and robust tutorial how to optimize OpenLayers. My goal is pretty simple. I’d like smaller library but still with everything must work correctly. The fact is that OpenLayers comes with more that what I need so I’m going to exclude some files from the build process.

Step 1

This procedure I found here, and what I made is to copy/paste the whole list described there. The problem is that immediately the application stopped working, but in the same time I could catch what errors were stopping it and simply I was able to include again those files needed by my application.

Step 2

Even when I excluded everything from the library, there are some files I don’t need but that enter the resulting build. That’s because they depend on classes I need and the builder is simply adding them. The solution, even stupid enough, is to comment them all.

Note that on every step you need to check if the application is still fully functional. That’s a bit annoying, but it comes on the price of faster app.

Step 3

Change the compiler! Actually now OpenLayers is using JSMin, but I personally use Google Closure Compiler with it’s default level of optimization. Thus the resulting OpenLayers is 312K and still fully functional. After GZip it becomes even smaller and the load time is pretty good.