Cross Domain AJAX Calls and Iframe Communication How To

I set out to write a short tutorial about cross domain ajax calls and communication between iframes using url hashes (fragments), but I found this great tutorial by Michael Mahemoff covering the subject inside and out.

It is important to note that the code on his demo uses window.location.hash, although it seems this practice should currently be avoided because of a known open bugs in the way Firefox URI-decodes document.location.hash when getting its value (could be considered an expected behavior and not a bug, but still different than any other browser). Facebook’s code uses substring on pathname, and it seems to work cross browser. Facebook also have on their wiki a nice visual explanation of how it works:

Until the HTML 5 postMessage is widely adopted, we will have to keep using this somewhat of a hack, but it works, that’s what’s important.

Upgrading Mootools 1.11 to 1.2 Is Between Hard and Impossible

When it comes to client side, Javascript frameworks are one of the first things that accelerates your development of web applications. Before knowing about the existence of Javascript frameworks, I was coding raw Javascript, in strict functional programming, trying to solve the never ending war of cross-browser compatibility with every new line of code.

And then came along frameworks like Scriptaculous, JQuery, Dojo, and Mootools. These frameworks all tackle the everyday problems of Javascript (cross browser issues being the most important part), build and force an object oriented way of programming Javascript, and create easy to use classes for complicated tasks (like evaluating JSON responses from XmlHttpRequests). On top of that, they add cool and customizable graphics and effects for web UI.

History has its way of determining what framework you eventually use. They are all really similar, and when you’re just in the stage of picking your framework, it usually comes down to the one that has an example in its documentation that is most relevant to your current problem and seems that it solves it with the easiest code. Sometimes though, it’s just a matter of what framework is showcased better, and which has the coolest graphics.

In my case, it was Mootools, and I really can’t remember why. I started using it when it was in version 1.11, and I have been truely happy with it (except for a really nasty bug with https protocol and Internet Explorer). Mootools by version 1.11 was already a robust library, and didn’t require much more development. But of course that open source projects progress and develop, and have to catch up with new browsers and new technologies, and then Mootools released version 1.2.

It’s been already 6 months or so since it was released, and I still haven’t upgraded. And it’s not that I didn’t try — I have tried already 3 times I think — but the upgrade process from 1.11 to 1.2 is probably the hardest upgrade I’ve ever encountered. Version 1.2 is not backward compatible with version 1.11. There are compatibility packages, and several attempts of the community to build on top of these packages, but they never seem to cover all the compatibility needed. There are always a few lines of code you wrote using 1.11, that even with cmpatiblity packages, 1.2 will just break on.

Now don’t get me wrong, I am addicted to Mootools. They say that its core is stable, and they’re right. I just hope that I will never be forced to try again to upgrade to 1.2, or that there will be an easy drop-in way to get code written for 1.11 run on 1.2.