I've recently had to write a "pop-up" (javascript simulated modal box) invitation for surveys to be automatically embedded in certain (over 2,000) relatively small sites.
These sites share a common web analytics javascript snippet, just like Google Analytics and the goal was to seamlessly integrate this facility. The integration was not the first version but the second, the first being archaic, simplistic, unmodular and hard to maintain. However there was something good in it (I'll post a joke at the end of the post) : the client-side part was written in ActionScript / Flash. The pm however pushed (literally) the idea of having a DHTML part (HTML/CSS + JavaScript that is) instead of the Flash since it won't require the clients to have the Adobe Flash plug-in installed.
At first this seemed a GREAT idea since it would be lighter, faster and it would allow more clients / visitors to be able to receive the invitation. Only javascript was required but the whole tracking snippet was already written in javascript so it wouldn't mean any more requirements for the visitors.
Of course we looked at several pre-made "modalboxes" such as Lightbox and ModalBox. At first the PM chose ModalBox since it was fancy, has smooth animation, a click outside the box or an ESC keypress would dismiss it and so on. Things seemed to go well in the beginning but there were three javascript library dependencies.
In the first tests I would just hardcode three script elements and feed the apropiate src attribute values. Things went perfect. However I remembered that the whole thing this invitation was served was from a javascript already embedded on the webmasters' sites. And the business requirement was to not have to bother the webmasters to alter in any way their sites.
Alrightee, I thought, we'll just "documen.write" them dynamically. There came the first screw-up. The libraries will load perfectly, serialized, if they were statically referenced in the HTML markup but NOT if they were document.written. A library could be loaded before the previous (and on which it depended) was loaded.
At first I combined all of them in one big file (~180k = prototype, scriptaculous/effects, modalbox and the custom code), then gzipped it and so on. Gzipping was not much of a cinch since the last one, the custom code one was different for any of the 2,000 sites. So I cached them in RAM (ASP.NET MVC / HttpRuntime Cache / Custom ActionResult).
This seemed to work ok until I've tested with sites that already have a prototype reference in code. Seems that loading prototype when it already is crashes the javascript. Dohhh!!!!
Of course I just thought how much nicer a flash version would have been since there is less chance of having flash elements collide with each other. But no, the pm is just in love with his DHTML.
Well, let's fix this fucker... I went back to a non-combined form and at the end of the first library (prototype) I would load the next and so on through callbacks. Rewrite the whole client-side just days before the deadline. Included check to see if any of the libraries was already loaded and skip the loaded one(s). This went great until I hit sites that had too old versions of prototype and/or scriptaculous. Bummer.
I couldn't unload the old version and load the new one because I simply couldn't plus it could have broken site functionality. Well-well-well. I designed rules such as "if IE 6 or older and prototype older than 1.6.0 don't serve the invitation" - since, again, it would crash the javascript execution. I came up with so many exceptions that they became almost impossible to maintain/grasp/etc.
In a desperate attempt since the deadline was extended I searched for another modal box out there to fix the whole damn thing and came upon Facebox. In parallel a colleague of mine offered to help and started to write a modal box from scratch to avoid the dreaded javascript library references that would cause conflicts between the site's javascript and our own javascript code.
Did I mention how much I hate javascript? The nasty, dynamically typed, typo-prone, slow interpreted shit...and implemented in a thousands ways across several browsers and versions. Jeez..
The facebox was another re-write in the last day of an other deadline extension and that was last friday and saturday. No, working in weekend because of the pm's folly is NOT fun. Not one byte, not one bit even! Turns out several sites were crashing (btw when I say crash I don't mean a literal process crash with dump report and so on but stopping the javascript execution and such) on IE 6 and sometimes on 7 and 8. Turns out IE and only IE stops the whole page from loading if you alter the body of the document if it is altered by a script which is NOT a DIRECT descendent of the body element.
This reminds me of Tanya Stephens - It's a pity lyrics (the song is here), specifically "It really fuck me up because me check fi you so much".
This IE crap of behaviour is documented in the Knowledge Base. But still the suggested solutions mean altering (only statically!!) the site's content which I CAN'T since I don't own the site. So I am screwed up once again. The facebox is already jQuery dependent (more conflicts with MooTools and so on) and has the bad habit of appending at the end of the body. Some sites place our analytics script in a div in the body so the execution will literally bring down the page.
In the meantime I called up on my colleague who developped the custom modal box from scratch with no dependencies and with his help and another's colleague we were able to integrate it, HTML/CSS fine tune it and debug it. We also implemented the "click outside" and the "press ESC" for dismissal. After working one day from 9:00 (AM) to 22:00 with no lunch break.
By the way, did I tell you how much our pm loves to tell us how the company "rewards result and not effort"? He is really a ... character (he might read this).
I think I finally nailed it for the most of the scenarios (5 browsers, 9 total versions and 2,200+ sites) and tomorrow might be the big day. Keep your fingers crossed for me people 