Thursday, January 10th, 2008

How IE Mangles The Design Of JavaScript Libraries

Category: Browsers, Dojo, IE

>People like to moan about IE, and often don’t have anything to back it up. “IE sucks” doesn’t count.

Alex Russell, on the other hand, has written about how IE mangles the design of JavaScript libraries such as Dojo. His list both shows us the methods to the madness, informs us on the issues, and hopefully wakes up the powers that be to make sure that this items are fixed in IE 8 :)

Array’s Can’t Be Usefully Subclassed (test case)

Arrays without a working length property are nearly useless, and JScript mangles the design of toolkits as a result.

I think it’s safe to say that both Dojo and jQuery would subclass Array directly to save code, were it a reasonable thing to do.

Where Art Thou Getters/Setters?

Instead of providing the natural property-oriented behavior, it forces class authors to write getSomeProperty/setSomeProperty method pairs on their classes should they want to do anything when values are gotten or set. The resulting code feels a lot more like Java than JavaScript, which is usually a sign that something is horribly wrong in a browser.

I have some hope that we could see getters and setters for JScript in the near future. It won’t matter much, though, unless the JScript team ships their new engine to all IE versions when they release IE 8. Not bloody likely.

Performance

Kudos are in order to the JScript team for fixing their long-b0rken GC heuristic and pushing it out to everyone…but it’s the tip of the iceberg.

Performance is one of those areas where differences in implementations can tightly circumscribe what’s possible despite exacting spec conformance. On this front, JScript’s raw VM-level execution time leaves a lot to be desired, but the true travesties really show up when you hit the DOM for computed style information or try to do anything reasonably complicated that involves string operations.

Across the board, from DOM performance to raw JScript execution speed, IE is a dog, and the odds are good that whatever toolkit you’re using spends a lot of time working around that reality.

Doctype Switching

Instead of giving devs fine-grained layout system control, IE makes it all-or-nothing. The global flag approach backs toolkit developers into doing script-based layout calculations or “just throw it in another div” solutions where we’d really rather not. Both are slow and both may be required since it’s completely impractical to dictate to users which doctype they’ll be using. While any app may be able to be disciplined enough to not care, toolkit developers must work everywhere. Hilarity ensues.

I fear this is going to get even worse with IE8 as the IE team looks to implement some of HTML 5 and hopefully many of CSS 2.1’s clarifications. The sooner they abandon the global switch, the better…but I’ll wager it’s pain they just don’t feel. Building a browser is a very different pursuit from building portable apps to run inside it.

HTC’s Can’t Be Inlined (Even With Hacks)

Modern browsers have built-in widget systems. On IE, it’s HTCs + Viewlink and on Firefox it’s XBL. Even a cursory reading through the docks for both is enough to illuminate the gigantic overlap. Alas, no one is yelling at them to standardize and the result is a terrible mess in which both sub-optimal formats limp along with nearly zero Open Web usage.

So why do I single out IE for whipping here when XBL is just as lame and similarly b0rken with regards to single-file embedding? Well, on Mozilla, you have a lot more “outs”. I strongly suspect that you can use “data:” urls to generate and evaluate component definitions for FF, which would enable compiling down from a single (more sane) format in the running page environment. IE prevents any such useful code-loading approaches.

Related Content:

Posted by Dion Almaer at 1:04 pm
7 Comments

++++-
4.1 rating from 51 votes

7 Comments »

Comments feed TrackBack URI

Very good article. I always had reason to hate IE because of it’s DOM implementations alone. If IE became standardized most JS libraries would be able to significantly reduce their weight. That’s something everyone benefits from

Comment by tj111 — January 10, 2008

I’m all for a Firefox plug-in for IE. That would fix it for good.

Comment by Diodeus — January 10, 2008

Let’s not forget IE’s crappy document.createElement implementation.

You cannot assign a name attribute to a node that you create using document.createElement without doing an unholy document.createElement(““).

You also can’t set the “checked” value of a radio button created using DOM methods prior to inserting it into the DOM.

And don’t even think about modifying the DOM before IE is done building it, unless you want an “aborted operation” which results in a completely busted page, i.e. worse than a 404 or 500.

Little maddening things like that is why I tend to yell “IE sucks!” at the top of my lungs at least once a day, and feel completely justified in doing so.

Comment by arapehl — January 10, 2008

Ummm, that was supposed to be document.createElement(<a name=”foo”>)…

Comment by arapehl — January 10, 2008

And let’s not forget the fact that DOM objects in IE doesn’t extend the Object object! That’s why you cannot add methods to, say, the Element object.

Comment by vramdal — January 11, 2008

@rapehl: Unless I’m mistaken, you shouldn’t be making those kinds of calls anyway – it’s non-standard/IE-only at best.
http://developer.mozilla.org/en/docs/DOM:document.createElement

Comment by Schill — January 11, 2008

And definately don’t forget trying to code around it’s horrible memory leaks.

Comment by SiteSmart — January 11, 2008

Leave a comment

You must be logged in to post a comment.