How IE Mangles The Design Of JavaScript Libraries
Date : 2008 01 10 Category : Tech & Development
AjaxianPeople 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.