Comments for How IE7 Can Avoid Irrelevance
My email address is alex@dojotoolkit.org. I look forward to continuing the discussion.
Personally I'd rather see them going with standardized technologies then their own, but I'd settle for any fix.
The most important point for javascript developers currently IMHO is:
"Today, allocating more than 5K objects or so brings JScript to its knees. Object allocation cost needs to be O(1)"
There is no real work-around for all these complex object-oriented javascript APIs.
Looking forward to hearing from you.
After trying one of later Vista builds I realized that close to no work has been done regarding DOM bugs and missing DOM features.
Don't get me wrong, I also want the CSS bugs fixed but IE is bound to go the Netscape way if noone starts fixing IE-the-platform.
Erik, please God you're wrong.
However (and whilst I appreciate that this is a preview of IE7 Beta2 and not actually IE7 Beta2 itself), those of us custom-hosting the Windows web browsing platform - and all of our OEM customers - are becoming understandably concerned that some seriously problematic issues arising from new IE7 features that were flagged to the IE team as much as four months ago don't appear to have been addressed yet.
We have to be assured that the 'real' Beta2 will show some genuine progress in that respect.
You're presuming that all future dynamic web apps should/will be built using JavaScript. Why not Flash or something similar? That bypasses the multi-browser compatibility hurdles entirely.
I'm not presuming that dynamic web apps in the future should be built with HTML+JS, just that they will. You see, once you abandon HTML, CSS and JavaScript you're no longer developing a web app, you're developing an app that happens to use HTTP as a way of negotiating content transfer and the browser as a nice plugin platform. That's not a web app.
My point isn't to be glib, it's that the web succeeded because it was text on the wire that could be inspected by everyone and easily produced. Love it or leave it, that's an advantage that Flash just doesn't have. Open by default beats closed by default, not perhaps instantaneously, but in terms of rate of improvement. Losing "textuality" is something whose cost is felt at every part of the development and deployment cycle. HTML, CSS, and JavaScript aren't going away.
Now, I know all about MTASC and the new tools that are opening up Flash as a programming platform, but that doesn't change the fact that it's controlled by a single vendor and only renders in a single client.
The siren's song of closed platforms has been with us as long as the web has. I expect that will always be the case, and I sincerely hope that Adobe will continue to make Flash accessible to scripting in the browser. But the apps I work on, the one's that will continue to define the web, will be built with some combination of HTML, CSS, and JavaScript.
Regards
- Memory leaks need to simply disappear
- Fix the cache+gzip bugs
- Either revive (and start to fix) VML or give it an SVG-Tiny+DOM facade
These 3 suggestions make sense and would be nice-to-have, though none of them are the disasters you make them out to be.
However, the rest of your suggestions either make no sense or have absolutely no relevance to IE:
- Give us getters/setters in JScript or give back watch()
IE never had watch(), Netscape did - and still has, as part of all its DOM 0 proprietary extensions. Getters would be nice but would require a thorough upgrade of the JScript engine itself. In that case I would prefer to see the ECMAScript 4 compliant core of JScript 7 inside IE, as is currently used in JScript.NET. IE already has the equivelant onpropertychange.
- Fix the event object. Pass it in to DOM handlers by default. Also, offsetLeft and offsetTop are so ambiguious as to be useless. Give us currentTarget.
Wow, talk about mixing subjects. Eradicating the global Event object and passing it directly to DOM handlers by default will break a lot of old code, not to mention that it would have to be a completely new Event object that conforms with the W3C DOM ECMA bindings. offsetLeft and offsetTop are actually so meaningfull that all other modern browsers implemented them as well. Instead of currentTarget IE simply uses srcElement/toElement. Put simply, the non-W3C event object in IE only requires one line of additional code to work interoperably with the W3C event object using something as simple as object detection. There's no pressing need to change this.
- Bump the limit on the number of concurrent HTTP connections if those connections are initiated after onload (either via XMLHTTP or other methods)
The number of concurrent HTTP connections after onload is the same as before onload. Bumping it up will break the HTTP standard. IE behaves the same here as all other browsers, allowing local system administrators to break the HTTP standard if they so desire but defaulting to obeying the sensible HTTP standard.
- Today, allocating more than 5K objects or so brings JScript to its knees. Object allocation cost needs to be O(1)
Clean up your code, use proper prototyping, remove your DOM-binding closures and stop using eval. I've got no problems with either performance or memory when creating more than 100K objects in JScript.
- Give us a persistent, string-keyed, local cache in the MB range (5-10MB/domain seems a good start)
IE already has this with the userData behavior, even allowing you to store complex XML documents. No other browser has an equivelant.
- Fast DOM queries. CSS selectors or XPath, we donât care. Just give us a way to say âget us all DOM node objects matching thisâ?
Google for "ie xpath" and you'll find a host of XPath implementations for IE, or simply write your own CSS selector - my own getElementsByClassName is less than 800 bytes.
- A way to toggle the box model on a per-element basis without switching doctypes. The CSS 3 box model spec seems a good starting point
We can start bitching about the lack of per-element box model switching when other browsers even start considering whether to implement this feature as well. In the meantime, both IE and all other modern browsers will let you switch box models on a per-document basis, which means you can use an IFRAME as a dynamically positioned container with ease. Alternatively, use a box model script which will automatically implement the changes for you or simply start writing W3C box model compliant code - IE6 has no problems with this.
In all, you have 3 nice-to-have suggestions and 10 irrelevant ones. I doubt this list is a defining factor in making IE7 irrelevant.
Haven't seen your name much since I stopped doing security for a living.
As for your comments:
I'm very well aware that the HTTP spec defines a 2 connection limit. That doesn't make it any more useful. Low-latency data transport to the browser is something that ties up a connection and multiple windows using the same technique can essentially "hang" the browser today. We need a better solution.
The 5K object problem isn't code. It's data. All the code I write uses "proper prototyping", etc. That your apps aren't large-scale enough to hit this limit is no reflection on the quality of JScript as an implementation.
Last time I tried userData, it was buggy. It's a good start, but it needs significant work for larger data sets (IIRC).
As for "getElementsByClassName", it's not the implementation that's the issue, it's the speed. Recursive DOM traversal is brutally slow from script, in part, because the JS object facades aren't created until the controls are visited the first time by a script. The browser already has a list of matched nodes for any selector in the document. Forcing us to jump through even 800 bytes to do the same thing (slowly) and w/o the benefit of a live collection is dumb.
As for the box model, you're wrong about other browsers. Opera provides "border-box", Safari and Konq provide "-khtml-box-sizing" and Mozilla exposes "-moz-box-sizing". These all allow the specification of border-box sizing on a per-element or per-sub-tree basis. IE is significantly behind in this regard.
What you consider "irrelevant" seems to be mostly informed by a lack of experience dealing with large data sets in the browser and deployment-time optimizations for large-scale apps. I realize that some of the things I'm requesting are (today) esoteric, but they are certainly not unheard of and they are growing ever more common.
As always, it's great to hear from you.
Regards
Implementing getElementsBySelector or XPath on top of DOM using JS is just slow (even when using a static snapshot).
JScript 7 - I'd rather have JScript 5.7 which is compatible with JavaScript 1.6. Using JScript 7 in the browser would be pretty useless since no other vendor support this and it is a step in the wrong direction (JScript 7 will never be compatible with JS2, or the other way around if you prefer).
Passing the event object to event handlers would not break anything. Removing the global event object might though, but no one suggested doing that as far as I can tell.
function myFunc(myObj) { var mySrc; if (myObj) mySrc=myObj; else mySrc=event.srcElement;
mySrc.style.whatever=whichever; }
/* Sometimes called like so: */ el.onmyevent=myFunc;
/* And sometimes like so: */ myFunc(mySource);
No, this isn't graceful or well thought out code, but it's out there. And starting to pass the event around will certainly break existing code (this is most likely why MS decided against doing it when they could have easily added it once they added attachEvent, which does pass the event object).
Alex: I just submitted this comment and after submission was told that I was missing some required fields. Using the back button destroyed my comment. I realize this has more to do with your choice of blog software than with you. But I'd fix it to use client-side validation. Without fiddler and re-submission I would have lost my comment.
OK, IE has several irritating bugs but my point is, FF has some irritating "features".
How about first off - browsers need to conform to DOM Level 1,2,3
Certainly to say "IE already has this with the userData behavior, even allowing you to store complex XML documents. No other browser has an equivelant" is a good bragging rights game, but how about I ask this differently:
Because you are implementing these items which are then IE specific, you are saying to the developers: here are some neat toys, but now you have to write 2x as much code to support other browsers. And developers can't simply ignore a population of browsers and exclude them.
Aspire to the DOM model, IE should use the DOM model. And the consumers (ie. me) will see when you are not and try to hold you accountable to that.
Jack - the reason why 'not available in FF' is because Mozilla, Firefox, Safari, Opera, etc... follow the DOM with regards to the Event object, and IE does it totally different. Thanks to IE we get to write two sets of code.
FYI - I'm a asp.net developer who works with Microsoft products. So, it's not about 'Microsoft' here, it's about following the DOM, achieving DOM level 1,2 and aspiring to DOM level 3 rather than the continual injection of proprietary browser API's.
No SVG - no use. This is the open standards era. SVG is the best open standard for web graphics. Don't tell me it's possible to write mobile phone firmware that renders SVG, but MS has not been able to do so in 6 years. They are purposefully (and for their own gain) not supporting it, and many other open standard technologies. They are not coming to the table, because it doesn't suite their agenda. It has nothing to do on whether they can or can not support SVG and other great technologies. I think it's time to stop supporting browsers that don't play by the rules.
To me it's simple. I'm writing basic versions of my sites to support IE, and real sexy ones that use open standards. If users want to use the good looking sites with slick functionality, then they need to use Opera, Firefox, Safari or any other browser that knows the game.
Stunning post Alex!
Stop being so pompous Thor. Anyway, you've got your money on the wrong horse my friend.
Interesting times!
AJAX request executes but then gives nothing for the onComplete, can't even get an alert there and no errors pitched :-/ No I have to download a 300mb package to debug javascript in IE (VWD, ok I did get the SQL Server debugger too) when firebug is all of 400K?
I used to have more patience for IE but now hold it in the same regard as NutScrape 4.*
Would rather just see IE die than continue a few more years of half assed measures and pointless grief.
Bill should give up the charity work for a year and just focus on making some decent software instead of dysfucntional bloat ware.
Add on to that some of the other 'little' problems MS creates. For example, I'm writing a dojo application, works great in Firefox, but I get a simple error in IE7. Yes I unchecked 'Disable debuggin' but still can't debug. I use the menu to 'Find more add ons' so i can, but that takes me to IE8 add-ons. Am I using IE8?? No. Ok so we'll search for some on google, and when find some they have to be paid for!
MS has to change alot if they want to slow their loss of market share.
http://www.microsoft.com/downloads/details.aspx?FamilyID=2F465BE0-94FD-4569-B3C4-DFFDF19CCD99&displaylang=en