Thursday, January 10th, 2008
>People like to moan about IE, and often don’t have anything to back it up. “IE sucks” doesn’t count.
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?
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 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.
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.