Nate's Stuff

For the last few months I have been testing out IE8 and for the last few months I have been testing out Google Chrome.  I actually reviewed Chrome in a previous post and concluded that there probably wasn't any real reason to migrate from what your are using already.  I think I may be changing my mind.  The more I use the software the more I am convinced that IE8 is going the wrong direction!  After reading an article in Redmond Magazine (I believe the title to be sarcastic).

The basic premise of the article is that the web is looking for small incremental change, not catastrophic change.  I don't entirely agree. We don't want our web applications to break too badly, but at the same time we want massive change and innovation in our browsers.  We want light, fast, safe, and secure.  It's not that I have any problem with any features planned for IE8 per se, it's just that I can see they are not spending time on my first two requirements -- fast and light!  I do have a problem with one of their features as I select text periodically when reading it and some new feature gums up my reading routine. 

Basically, my experience with IE8 can be summed up with this statement-- Slow and Unusable, even for Beta.  I much prefer IE7 to IE8.  So if any of the IE8 team end up reading my blog, my message is this:  You still have plenty of market share and plenty of time to do this right.  You do not want to rush to release something that is going to reduce market share.  Take a page from the Firefox book, a page from the Chrome book, and write a few of your own pages.  Lead, Follow, or Get Out of The Way!

In case the team has run low on new and exciting innovations I spent a day and a half thinking of some really cool features that would get me excited about IE again. 

Innovations:

• Use V8 (or roll your own version of managed JavaScript -- I don't care, but make it faster!)
• Allow for any code engine to execute against the DOM like JavaScript.
• Write the browser in managed code for performance and safety
• Re-work the plug-in model to operate from an interface and run these plug-ins in such a way that they can not kill the browser or even the current page
• Make it easy to make plug-ins!
• Allow the interface to be skin-able
• Allow users to see what is happening with resources used; which plug-ins and pages are causing problems.
• Multi-thread the browser; I.E. Never (and I mean never) block the UI thread!  JavaScript should not be run on the UI thread.
• Allow for C#  script; while not entirely useful for wider deployments it can be useful for enterprise apps.
• Get fully standards compliant (this doesn't seem that difficult); although I don't entirely agree with all of the standards.
• Update the "Find" dialog! FOR THE LOVE OF PETE, REFINE THE FIND DIALOG! Update: I had forgotten that they actually did replace the find dialog with a Firefox-looking dialog that I liked much better.  I don't remember if it had a highlight all (as I uninstalled it a week or two ago), but if it doesn't -- it should. 
• Update the download dialog.  It should, at the very least, support:
  • Download Resume
  • Start the download--then ask me where I want to save it. 
  • Allow users to create some kind of convention about the default save path of a file.
  • Allow more than 2 concurrent downloads per domain or at least allow the user to easily set that setting.  I know this is a standard, but overlook it! Update: According to a rather abrasive and defensive person on the IE8 forum it supports 6 simultaneous downloads; I wonder if it's possible if IE7 emulation mode made a difference?  If not it could simply have been the server, the network, etc. 
  • Allow downloads to be queued.
  • Allow downloads to be throttled.
  • Don't block downloads!  Allow the user to set a policy if they want to block executable downloads, but even if the download is blocked, don't make the user have to refresh the page to get it to download!
  • Don't kill the download after the save file dialog. Is this a bug?
• Maximize the screen real-estate, but keep the basic stuff visible.  Hiding the menu's in favor of a toolbar was a bad idea.
• Store the cookies and history in a Relational Database rather than a ton of files.  Firefox uses SQLite.
• Allow the history to be quickly searched.
• Show more informative error screens.  Was the browser unable to resolve the DNS?  Was it not able to connect?  Did it get an error code and if so, what?
• Re-Do browser integration for 3rd party applications.  ActiveDocument STINKS!
• Allow book-marked pages to be fully downloaded and updated.  Also the user should be able to "save their bookmarks to the web"
• MAKE IT FAST AND LIGHT!
• Continue to innovate!   There is no reason to make a browser that is the same as any other.

UPDATE

I kind of walked into this one by posting a link to this post on the IE8 blog.  I was immediately "ripped into" for two of my inaccuracies (noted above) and was left with a comment that concluded that my opinion was uninformed and somehow irrelevant.  This person may or may not actually be from the IE8 team, but he did speak somewhat authoritatively on the subject.  Besides two of the noted exceptions above he (along with many others, even at Microsoft) though the notion of a managed browser was ridiculous.  Because I listed performance as a potential benefit of managed code he pointed out that there isn't anything that can be done in Managed code that can't be done in native code.  So I guess that means that IE8 has it's own memory manager which can move blocks of memory around in an efficient manor and can re-size existing blocks in the heap?  Seeps pretty unlikely as this would mean they would have to give up pointers in C++ and that is really, really, really unlikely.  They must also have some way of preventing all code-based security exploits so apparently we won't see any patches for IE8 once it has been released.  Humm, nice to know!

Incidentally, I have started a series of blog posts that compare relative performance between managed and unmanaged code.  At the time of this writing I have only the first post but I have written experiments for the next two and I can say at this point that where C++ wins, managed code isn't far behind; whereas where managed code wins, it wins big!  My experience is that hard-core C++ programmers really hate managed code, usually listing performance for the reason.  I suspect that the real reason is they are loathe to give up 'total control', especially when it comes to memory management.

I doubt my comments had any effect on anyone -- let alone anyone in charge.  So I hope MS doesn't pull another Vista!

Links:

• http://interactiveasp.net/blogs/natesstuff/archive/2008/09/02/google-releases-web-browser-quot-chrome-quot.aspx
• http://redmondmag.com/columns/article.asp?editorialsid=2861
• http://blogs.msdn.com/ie/archive/2008/11/10/november-chat-with-the-ie-team-on-thursday.aspx