If you’re familiar with the new jQuery version 1.4. released recently, I’d suppose you’d like to get its fresh cheat sheet.
Such has been published on http://labs.impulsestudios.ca/jquery-cheat-sheet or you can find it here.
As my blog deals a lot with one of the most used JavaScript libraries – jQuery, it’s my duty to say that version 1.4 is released. That comes with a bit change of the jQuery site – http://jquery.com.
In breve OpenLayers is a open javascript library that gives you the power to integrate, work and develop map based web applications as is Google Maps.
The problem is that the library supports so many protocols, controls and tools that you probably never use in your application and because of this the size of the resulting, compressed javascript file is around 700K, which is too big for any javascript file at all. That makes your site slow and the user experience is really awful!
The solution is to cut that functionality that you don’t use, which is not so easy. You’ve to be careful doing this, just because you can crash you application by removing something that seems to be useless but in fact isn’t.
I’ve used this technique and managed to make the resulting javascript file up to 400K. And this is really simple – just add the files your application don’t need to the .cfg file you use for compression. Usually this fils is in the /build directory of OpenLayers.
Even more – I’ve seen some other developers managing to reduce the size up to 300K and that’s more than twice which is really very good result.
The other thing I’d like to do with that library is to explore with care the code inside and to optimize anything I can. There are too many style reflows in some classes and that’s what’s visible on the first look. I suppose there are much more things to optimized in it.
I’ll start doing my research and optimization and I’ll let you know what happens in numbers!
The question is: should I use always jQuery in some large jQuery project? Imagine you’re developing a large scale web application where the JavaScript part of it is supported by jQuery. In my case that was the reality. In fact in every, even very big, project there are “pages” where you don’t need much of JavaScript. Such pages can be the “about”, “info” or whatever static page there is.
Well the question is, should I again include the hole jQuery if I need only to toggle the visiblity on a DIV element? Let’s assume you’ve very long text, cutted in the beggining with the “more” link somewhere after the intro. That’s very common, isn’t it? So by clicking on the “more” you toggle the visibility of the rest of the text. Well of course it’s absurt if I include the entire library just to make this.
The right answer by me is to use pure JavaScript, something like that:
document.getElementId('id').style.display = 'block'
That will do the same job without to block the “fast” in other way page!
To start with some example let’s assume that there is one DIV element with 100 A tags inside. If you assign event to every A tag that as you may know slowes down your browser. That’s a problem because sometimes that can happen, even with more than one hundred A tags. Imagine you’ve a map with one thousand markers, which are A tags. Attaching events slowes down the browser, because every of these A tags bubbles the event that has been fired. And that makes your CPU to make thousands of calculations. Of course you can avoid this problem with a simple technique. Just attach one single event on the container DIV element. Thus you can check if some child of the DIV element has been the target of the event. This makes the browser to breath. Continue reading jQuery live() vs bind() performance