People who know me professionally are fully aware of how annoyed I get when trying to build web applications that are truly cross-browser compliant.  In my current position, I do a lot of web programming in PHP, HTML and JavaScript.  HTML is a no-brainer and PHP (when using AJAX) is usually very straightforward.  Making it all look pretty with the bells and whistles that make the web application work well for the users takes a lot of Javascript and a lot of time.

So, I get very frustrated when I spend a lot of time getting something just right only to find out that when I try it out in another browser it doesn’t work right.  It renders wrong, or where one browser was willing to forgive a small HTML problem, another browser just dies.  For instance, I had a coding issue that caused an extra closing BODY and HTML tag at the end of the document.  For some reason, in IE8 that caused the browser window to hang and the process to hog 50% of my CPU.  It’s the little wierd stuff that can make for a very long morning.

Since I use a lot of JavaScript, speed is important.  I mainly develop using Chrome, since it’s clean and fast, with very little extra stuff to get in my way.  I keep it free from plugins and extensions so that I don’t slow it down any.  It’s JavaScript engine is nice and fast, and Chrome as a whole generally does what is expected.  If I have a problem that isn’t obvious in Chrome, I pull up Firefox to take a look, since it’s helpful sometimes to nail down a difficult problem by looking at the error messages from a different browser.

My biggest headaches, however, have been with Internet Explorer.  Because of some legacy vendor web apps, we have people in our company with IE6, 7  AND 8.  They can’t be upgraded or they’ll break other things.  When I developed my web app with lots of JavaScript, I didn’t know that IE6 and 7 are basically worthless in this area.  They’re just horribly slow.  Code that executes in 4-5 seconds in Chrome would take over 30 in IE7.  IE8 is better, but still pretty slow in comparison to other modern browsers.  IE9 is rumored to be vastly improved, but it’s not going to be available on WindowsXP, so that’s not a solution.

So, I decided to do some testing.  The results show what everyone already knows, which is that IE8 is just sadly lagging behind the rest of the pack. What’s interesting to me, though, is that Firefox is starting to fall behind as well, especially in speed.

If JavaScript performance and compliance is an issue, stick with Chrome, Safari or Opera.

Bookmark to:

Oh, how I loathe having to deal with Internet Explorer.

My big web application that I’m always working on was recently released to our internal users in it’s version 2 state.  That meant everyone got to use the new modal windows that I had implemented.  Why modal?  Well, I was trying to avoid using any pop-up windows for the usual reasons – pop-up blockers, losing the pop-up behind the main window, etc….  I also wanted to learn some new techniques, and being able to program modal windows seemed like a cool thing to know.

Well, the users weren’t as receptive to the modals as I’d have liked.  I think if I’d have had a lot more time to spend on them to improve their usability, it would have been fine, but time isn’t something that I have in my job.    So, version 3 is being developed to replace the modals with pop-ups.

One of the first things I needed to do was to re-code the Javascript so that when the user clicks on a report, instead of it loading into a DIV and then displaying the DIV, it opens another browser window and writes the report into that window.  No problem, easy to do, and eliminated a LOT of the modal code that I had written.  Chrome looked good, so did Firefox.  Not so much IE8.

I’ve known for awhile that IE6 and IE7 don’t handle Javascript very well performance-wise.  I use a jQuery plugin called Tablesorter to make my tables sortable and to zebra-stripe the rows.  When users with IE6 or IE7 ran large reports, they’d often have very long wait times as the Tablesorter did it’s thing.  IE8 was a big improvement in that area.

This time, however, something was wrong.  Tablesorter was working well in Chrome and Firefox, but in IE8 is was just crawling.  Simple sorts were taking close to a minute and the zebra-striping was being done one row at a time, so slow that they could be seen.  I checked and double-checked my code, but was stumped.

Well, I’m happy to report that even if I don’t quite know WHY it has a problem with it, I found a way to fix it.  In my original code, I would launch the window, write HTML (including the table) to the window, and then I’d execute the tablesorter function using a jQuery selector referencing the table ID and the pop-up window document reference as the scope.  So, essentially my javascript was executing in my main window but was modifying the DOM of the client window.  It would do it, but was incredibly slow.

After many different ideas, I settled on this.  I launch the window and write to it just like before, but now I include a SCRIPT tag in the header pointing to a javascript file.  Inside that file I use the $(document).ready() to trigger Tablesorter against the table when the DOM has loaded.  Since the javascript is running inside the client window and also accessing the client window’s DOM, the speeds are back to where they should be.

I’m assuming the whole problem has something to do with how IE8 passes the memory references back and forth between window instances, but I can’t be sure.  I did a lot of searching on the net to try and find anyone explaining this, but had no luck.  Maybe someone will read this article and explain it to me.  All I know is that Chrome and Firefox had no problem at all.

Bookmark to: