Technology Tales

Adventures in consumer and enterprise technology

TOPIC: INTERNET EXPLORER

An inappropriate use of JavaScript

3rd July 2007

I have seen a web application that displays thousands of records in a scrollable table (please bear with me, there is a decent reason for this). From the appearance of the table, it would be reasonable to assume that the table is generated by the server and output directly to the screen, but this isn't the case. What actually happens is that the server more or less outputs JavaScript code that is then executed. This takes the form of large arrays that are slotted into the DOM as the contents of the required table by a JavaScript function. With the large amounts of data involved, this means that the browser fully loads the client CPU while the JavaScript processing takes place, something that takes up to a minute to complete. Admittedly, the browser is IE6, but this was all on a PC with a 2.53 GHz Pentium 4 and 512 MB of memory. Getting the server to deliver standards-compliant (X)HTML for what is needed in the first place seems a much, much better approach to me.

IE6 and JavaScript performance

22nd June 2007

Having been exposed to an application at work that uses a lot of JavaScript, I fully appreciate what some mean when they discuss IE6's inefficient handling of JavaScript. After seeing a web page taking an age to reload and your CPU taking a hammering because of JavaScript processing, the penny does tend to drop...

Needless to say, this very much impacts the world of AJAX-driven web applications with their heavy dependence on client-side JavaScript. While IE7 does come to the rescue, there remain plenty of IE6 users still out there, and this is reflected in website statistics. This demonstrates a certain level of inertia in the browser market that not only afflicts the uptake of IE7 but also the likes of Mozilla, Opera and Safari. It also means that anyone developing AJAX applications very much needs to continue testing in IE6, especially if the product of their labours is for wider public use.

An example of such an application is Zimbra, an open-source web application for messaging and collaboration, and the people behind it have generously shared the results of their browser performance benchmarking. They did comparisons of IE6 vs. IE7 and Firefox 2 vs. IE7. IE6 easily came out as the worst of these, while Firefox 2 was the best.

The next question to be asked could centre around the type of code that is processed inefficiently by IE6. While I wouldn't be at all surprised if a list emerged, here's one: using Microsoft's proprietary innerHTML object to update the DOM for a web page format. Having a quick trawl on Google, this came up for mention as a cause of memory leaks. It is also a Microsoft innovation that never got taken up by those overseeing web standards, hardly a surprise since a spot of DOM scripting achieves the same end. It may be faster to code than any alternatives, and it does have some support from other browsers, but it does seem to have got a bad name, so it should be avoided if possible. That said, it would be interesting to see a performance comparison between innerHTML and DOM methods in IE6.

Exploring AJAX

7th June 2007

When I started it, my online photo gallery started out simply as a set of interlinked HTML pages. Over time, I discovered frames (yes, them!) and started to make use of JavaScript to make the slideshows slicker. In those days, I was working off free webspace provided by my ISP and client-side scripting was the only tool that I had for enhancing functionality. Having tired of the vagaries of client-side scripting while the browser wars were in full swing and incompatibilities reigned supreme, I went with paid hosting to get access to tools like Perl and PHP for server-side processing. Because their flexibility compared to JavaScript was a breath of fresh air to me, I am still a fan of the server-side approach.

The journey that I have just described is one that I now know was followed by many website builders around the same time. Nevertheless, I have still held on to JavaScript for some things, particularly for updating the DOM as part of making the pages more responsive to user interaction. In the last few years, a hybrid approach has been gaining currency: AJAX. This offers the ability to modify parts of a page without needing to reload the whole thing, generating a considerable amount of interest among web application developers.

The world of AJAX is evidently a complex one, though the underlying principle can be explained in simple terms. The essential idea is that you use JavaScript to call a server-side script, PHP is as good an example as any, that returns either text or XML that can be used to update part of a web page in situ without the need to reload it as per the traditional way of working. It has opened up so many possibilities from the interface design point of view that AJAX became a hot topic that still receives much attention today. One bugbear is efficiency because I have seen an AJAX application lock up a PC with a little help from IE6. There will always remain times when server-side processing is the best route, even if that needs to be balanced against the client-side approach.

Like its forbear DHTML, AJAX is really a development approach using a number of different technologies in combination. The DHTML elements such as (X)HTML, CSS, DOM and JavaScript are very much part of the AJAX world but server-side elements such as HTTP, PHP, MySQL and XML are also very much part of the fabric of the landscape. In fact, while AJAX can use plain text as the transfer format, XML is the one implied by the AJAX acronym and XSLT is used to transform XML into HTML. However, AJAX is not limited to the aforementioned technologies; for instance, I cannot see why Perl cannot play a role in place of PHP and ASP, both of which can be used for the same things.

Even in these standards-compliant days, browser support for AJAX remains diverse, to say the least, and it is akin to having MSIE in one corner and the rest in the other. Mind you, Microsoft did introduce the tools in the first place only for them to use ActiveX, while Mozilla created a new object type rather than continue this method of operation. Given that ActiveX is a Windows-only technology, I can see why Mozilla did what they did, and it is a sensible decision. In fact, IE7 appears to have picked up the Mozilla way of doing things.

Even with the apparent convergence, there will continue to be a need for the AJAX JavaScript libraries that are currently out there. Incidentally, Adobe has included one called Spry with Dreamweaver CS3. Nevertheless, I still like to find out how things work at the basic level and feel somewhat obstructed when I cannot do this. I remember perusing Wrox’s Professional AJAX and found the constant references to the associated function library rather grating; the writing style didn’t help either.

My taking a more granular approach has got me reading SAMS Teach Yourself AJAX in 10 Minutes as a means for getting my foot in the door. As with their Teach Yourself … in 24 Hours series, the title is a little misleading since there are 22 lessons of 10 minutes in duration (the 24 Hours moniker refers to there being 24 lessons, each of one hour in length). Anything composed of 10-minute lessons, even 22 of them, is never going to be comprehensive but, as a means for getting started, I have to say that the approach seems effective based on this volume. It has certainly whetted my appetite for giving AJAX a go, and it’ll be interesting to see how things progress from here.

Vista incompatibilities starting to appear

6th February 2007

Windows Vista is only out a week and the incompatibilities are already rolling in. Yesterday, it was iTunes that hit the headlines, with Apple making an announcement on its website. More importantly for the likes of me, dues to its effects on my work, SAS has announced that Vista compatibility will not be assured until it launches SAS 9.2. This is not exactly a surprise because they have been advising against using Internet Explorer 7 with their products as they have not carried out their validation. Given that this company is cautious about operating system support anyway, it may be that SAS 9.1.3 runs on Vista without their having validated it to the standards that a large enterprise user would expect. Now, the BBC’s Robert Peston writes an open letter to Bill Gates in his blog following a lost weekend with a laptop running Vista. His problems were hardware related.

There is one surprising thing about all of this: test versions of Vista have been out since last summer, with OEM ones available since November or thereabouts. Why have other software and hardware vendors not being looking ahead for this sort of thing? SAS’s advice regarding IE7 is in the same vein and even more surprising. Though I realise that there is only so much that can be done with a non-final version or, for that matter, in two months, some forward-thinking surely could have been employed. While I know that full legacy compatibility is a big job, it does look as if someone sat on their laurels. Or else, they are not allowing the release of Vista to upset their development and launch schedules and, given that Microsoft’s offering is evolutionary rather than revolutionary, they might well have a point. I think I’ll sit on the fence for a while longer…

  • The content, images, and materials on this website are protected by copyright law and may not be reproduced, distributed, transmitted, displayed, or published in any form without the prior written permission of the copyright holder. All trademarks, logos, and brand names mentioned on this website are the property of their respective owners. Unauthorised use or duplication of these materials may violate copyright, trademark and other applicable laws, and could result in criminal or civil penalties.

  • All comments on this website are moderated and should contribute meaningfully to the discussion. We welcome diverse viewpoints expressed respectfully, but reserve the right to remove any comments containing hate speech, profanity, personal attacks, spam, promotional content or other inappropriate material without notice. Please note that comment moderation may take up to 24 hours, and that repeatedly violating these guidelines may result in being banned from future participation.

  • By submitting a comment, you grant us the right to publish and edit it as needed, whilst retaining your ownership of the content. Your email address will never be published or shared, though it is required for moderation purposes.