Top 10 reasons why I hate Internet Explorer (Warning: more ranting by me!)

As a web developer, there are a few mantras that I live by. The first, since it's not my primary job, is that web development needs to be fun. The second is that virtually anything is possible on the web, given enough time to figure it out. And the third is that any and all incarnations of Microsoft Internet Explorer are the scourge of the world.

Now, I understand that this third mantra seems a little harsh, so let me try to soften tone a little bit. I hate Internet Explorer. And after spending the last two days trying to make something that should have been simple work - again - in Internet Explorer, I thought it was finally time to tell the world why. Well, the top ten reasons why, anyway. So, here they are, in true Letterman style.

10. With a rapidly dwindling share of the browser market, Microsoft's attitude that the internet is Internet Explorer (or, rather, that IE is the internet) is the epitome of hubris. No product is the penultimate, much less Internet Explorer.
    


9. Standards? We don't need no stinking standards! We are the standard! Since Internet Explorer 6, Microsoft has included a "standards" mode in IE that was supposed to conform to W3C HTML standards. Strangely enough, though, neither IE6's nor IE7's rendition of these standards - yes, we'll talk about that in a moment - came even close to actually fulfilling the standards by which every other browser on the planet lives.
   


8. 6 years. Yes, after feverishly developing the thing in the late 90's so Microsoft could crush Netscape and lay siege to the entire browser market, that's how long IE6 sat gathering cobwebs before Microsoft decided to dust off their browser, give it a facelift, and release IE7. In 6 years, we went from Windows ME to Windows XP, and very nearly Windows Vista. There were three versions (maybe more) of Microsoft Office released, and broadband went from a tiny sliver of connections to the majority. 6 years. In most industries, 6 years without a new product mean you are out of business.
   


7. Convoluted Javascript namespace. In the 90's, it was supposed to make life easier. But that was before the dawn of the broadband era and complex, web-based applications. Back then, it was quick and easy for developers to be able to reference HTML elements directly by their id attribute, but now it is increasingly common to need variables with the same name as some of your attributes. How many times have I built an application, only to find out that there was something else on the page that conflicted with what I just wrote! (For the record, I always preferred the Netscape DOM that required you to walk down level by level. The document.getElementById method is a great shortcut for this that still doesn't confuse the namespace).
   


6. ActiveX. What in the world is that? Things that should have been in the browser in the first place, but Microsoft thought it needed to put its own name on? And while we're on the subject of ActiveX, what is up with Msxml2.XMLHTTP and Microsoft.XMLHTTP? Couldn't they make up their mind? I guess "breaking the internet" is bad unless it means you get to put your whole name on it?
   


5. Crash. Back in the NS4 days, Internet Explorer seemed relatively stable. But relatively is still not stable! Indeed, Javascript should not be able to crash your browser!
   


4. Windows. I understand that Microsoft argued in its antitrust suits that the web browser would become an integral part of the operating system, but they clearly didn't believe it since they never developed their web browser with their operating system. To restrict an application to one particular OS is ridiculous. When that OS is Windows - think Vista - it's downright insane.
   


3. Horrifying scripting environment. There are at least three components here. First is the fact that some code that runs in one version explodes disastrously in another. Second is the utter lack of real developer tools. Yes, I know there are some third party resources out there, but compare them to the likes of Firefox's error console (not even Firebug, which blows them all out of the water), Safari's Developer menu, Opera's developer plugin, and you'll find IE wanting every time. And then you add in the insanely unintuitive nature and structure of things. For instance, an acquaintance of mine (who by the way runs http://www.mibbit.com - a great web-based IRC client that provides translation on-the-fly using the Google AJAX Language API) noted today that the recommended method for obtaining the position of the cursor in a text box is to (1) insert some unique text, (2) grab the value of the input, (3) find the index of the unique test, and (4) remove the unique text. What? Add in a totally whacked event model, an irritating tendency to do things you didn't tell it to do (e.g., resizing an element that you didn't even touch), and an inexplicable penchant for not doing things you did tell it to do, and you end up with nothing less than a web developer's nightmare.
   


2. 3 totally different rendering modes, at least. No, that's not a typo. Internet Explorer 6 has two rendering modes: quirks and standard. You have to force it into standards mode with a doctype declaration. Internet Explorer 7 has its own quirks mode (which we'll consider the same as IE6's), plus IE6-esque mode (where it rendered standards-based pages as IE6 would) and then its own standards mode. As if that isn't confusing enough, the last version of IE:Mac, which still persists in some dark, dark corners of the world, had another totally different rendering model. And now, the news is that IE8 is coming with two different "standards" modes - one to conform to IE7, and the other that will be closer to the real W3C standards (but still not there!). I guess, for Microsoft, "standards" is an oxymoron. Unless, of course, the standard is non-standard.
   


1. It could probably go under horrifying scripting environment, but this is so criminal that it deserves its own spot - at the top of the list, no less. Cryptic and/or patently insufficient error messages. How many times have I been working on a page only to be stopped cold by a scripting error in IE. The only message I get from IE, though, boils down to, "You have an error on line xxx." The box does provide a file name, but it is always filled with that of the page itself, regardless of where the error actually fired. This is a huge problem when modern sites can often include 5, 10, 20, even 50 Javascript files, all of which may have a line xxx. It does, on occasion, include an error message but that can range from something as unenlightening as "Object expected" to something as absolutely maddening as, "Unable to complete due to error 80020003." And it's even worse when you realize - about the first time you try to debug something with all of this information - that even that line number you received was wrong. This isn't a once-in-awhile type thing like it is with other browsers and debugging environments; it's a more-often-than-not type of thing. In my world, this one problem alone contributes to more time (and hair) lost than just about any other hurdle I have to deal with.
   

So there you have it. The top ten reasons why I hate Microsoft Internet Exploder Explorer. If you're a developer, I'm sure you've found your own reasons to hate it, too. In fact, even my non-developer friends are realizing that it's a terrible, terrible browser, including some that are otherwise staunchly pro-Microsoft.

This list is absolutely not exhaustive. If I had more time (and you had more patience), I would include things like filters, horrifying inadequacies in CSS rendering, and a number of others. But for now, this will have to do. And the adventure continues...

What I learned on today's adventure:

1. Internet Explorer stinks
2. Any computer infested with Internet Explorer should be hauled off to the dump
3. Development is a nightmare in Internet Explorer
4. Internet Explorer's market share can't go down fast enough
   

How to get all the results available from your Google AJAX Search API application

If you haven't heard of it yet, the Google AJAX Search API is a pretty nifty little doo-dad. Basically, it allows you to add Google search functionality without having to divert visitors from your site, hack the Google infrastructure, or even deviate from your own formatting rules. It works like this: you build a control of some sort that will process user input; form a request URL; and get information, including web, local, news, video, image, blog, book, and even patent search results via JSONP. Pretty slick, if you ask me, but one of the questions I often receive regarding the API goes something like this: "It's a cool concept, but how can I get more results?" You see, using it, you can currently only get up to 64 results (less for local and blog searches), and you can only retrieve those in blocks of 8.

So for today's adventure, I thought we could explore getting as many results as we possibly can from the Google AJAX Search API. But right off the bat, there is a disclaimer: I'm not going to tell you how to get around the limit of total results you can retrieve. The AJAX Search API is designed to provide rudimentary search functionality for the users of your website or other application, not for SEO, data mining, or even deep searching. And it does that intended task admirably. To try to bypass the total results limit is a violation of the service's Terms of Use and, I believe, generally unnecessary when using the API as intended.

Rather, what we're going to talk about is getting all the results that they will let us get in one fell swoop.

So, how do we do it? Well, first things first; we set up our searcher as normal. Because the default google.search.SearchControl is obfuscated, we're going to have to use a RAW searcher. If you don't know how to do this, you'll want to check out the documentation at http://code.google.com/apis/ajaxsearch/documentation/.

Once that's done, there are two methods of the searcher object that we're going to take advantage of: .setSearchCompleteCallback() and .gotoPage(). Details for both of these methods are provided in the class reference.

Essentially, the process, broken down into its component steps, is going to go like this.

1. We set up the searcher's completion callback
2. We execute a search query
3. The query returns, executes the completion callback
4. The completion callback checks to see if there are more results
5. If there are more results to get, calls gotoPage(...);
6. Otherwise, finish processing the results

So, are you ready for this? Here's the code, commented up so you can see what's going on.

// Initialize the searcher object, in this case a WebSearch.
window.gs = new google.search.WebSearch();
gs.setResultSetSize(google.search.Search.LARGE_RESULTSET);

// Set the search complete callback. Notice that we're using the searcher itself as the context. This is going to allow us to use this in the callback to refer to the searcher.
gs.setSearchCompleteCallback(gs,function(){

// Set a handle to the cursor object that we're going to use repeatedly
var cursor = this.cursor;

// Create a new property on the searcher that we can stash results into so they don't disappear when we go to the next page.
if(!this.allResults || cursor.currentPageIndex==0){this.allResults = [];}

// Add the new results to the other results
this.allResults = this.allResults.concat(this.results);

// Check to see if the searcher actually has a cursor object and, if so, if we're on the last page of results. If not...
if (cursor && cursor.pages.length>cursor.currentPageIndex+1){

// Go to the next page.
this.gotoPage(cursor.currentPageIndex+1);

// Else, if there is no cursor object or we're on the last page...
} else {

// Loop through the results and...
for(var i=0; i<this.allResults.length; i++){
var result = this.allResults[i];


// Plug them into the document where we want them.
document.body.appendChild(result.html.cloneNode(1));
}
}
});


Check it out in action here.

And there you have it! All 64 results from a Google AJAX Search API WebSearch, in one shot.

What I learned on today's adventure:

1. I can use the Google AJAX Search API to get up to 64 search results for use on my site or in my application.
2. How to use searcher.setSearchCompleteCallback and searcher.gotoPage to get all available results in one fell swoop.

I hate Flex/Flash. Really, I do. (Warning: This is me ranting!)

So, for today's episode of Adventures in Web Development with me, I thought I would talk for a moment about just how much I hate Flex and Flash development, and why. Let's start off with how much. I hate Flex development about as much as water hates oil. (And believe me, after a little incident this week involving two toddlers and a whole value-sized jar of petroleum jelly, water and oil don't go together.) And I hate Flash development about as much as ice hates a blowtorch. Yup. I pretty much don't like it at all. You want to know why? Well, let me count the reasons:

1. It's a pain in the rear to have to code and code and code, then export/compile, debug, code and code and code, export/compile, debug, etc. Coding is frustrating enough at times; the introduction of the compile process, along with the painful debugging tools available, makes this absolutely unbearable. Of course, part of the reason I had such a hard time here is because I wouldn't spring for the higher-end development tools, but that actually brings me to reason number two!
2. Outrageous pricing. While the Flash player is free, and Adobe calls Flex an open source deal, the only official IDE's, Flex Builder and Flash Pro cost, literally, hundreds of dollars. I'm cheap. So I guess I get what I pay (or don't pay) for, but I really don't think it should cost me US$250 for the "open source" platform, let alone US$700 for the "Pro" IDE. And by the way, the next one is definitely related to this one.
3. All documentation assumes you have one or the other Adobe IDE. I love the Perl mantra that there is more than one way to do things; Adobe and everyone else who develops Flash applications apparently believes there are exactly two ways of doing it: Flash Pro and Flex Builder. It is quickly frustrating when all the tutorials talk about using tools in those applications.
4. The documentation is outright terrible. Generally speaking, the web is a great place to find resources for programming. That is not the case when it comes to Flash. Is there stuff out there? Absolutely. In fact, there are so many blog posts covering so many topics that it might seem strange for me to say that the documentation stinks. But the reality is that the presence of those blog posts actually speaks to the quality - or lack thereof - in the official docs. And frankly, when you leave documenting your stuff up to independent bloggers, the majority of which are trying to make a living building Flash apps, you're bound to end up with a lot of junk. Case in point: for the last several weeks, I've been building an application that I thought was completely ready. It ran beautifully until it had to parse an image feed from Picasa. Then it choked. Why? Because you have to reference xml elements with their fully qualified name when dealing with multiple namespaces. More specifically, you have to declare a QName variable. Then you have to go looking for your nodes. You can't combine the two steps into one line like you can with Javascript or any other respectable language. But of course, no one ever tells you that!
   
5. The whole plug-in thing. When I bought my first laptop, it was with the express purpose of not having to plug it in to anything to get the thing to work. I want my browser to work the same! Plug-ins take up space on my HDD and eat up my RAM. My browser should be able to do just about everything I need to do, and in fact most browsers do with a little finesse. But we'll talk about why I hate Internet Explorer in another post (or posts). For now, suffice it to say that I resent having to take the time and everything else needed to run a plug-in to get things done.
6. It shouldn't take me thirty days to figure out how to do something - anything - in an application. When I started the whole learning process, I initially downloaded the Flash Pro trial version. For thirty days, I tinkered with it, but made very little headway. I know; it's probably because I'm a little bit busy and a little bit slow on the uptake, but I've talked to others who have had the same problem. So it can't be all me!

Okay, so there you have it. Six reasons why I disdain Flash, Flex, and everything that has to do with them. If you disagree, well, I guess that's your prerogative. But as the apostle Paul said in Philippians 3:15, "If on some point you think differently, that too God will make clear to you."

What I learned on today's adventure:

• You can't be cheap all the time; if you are (like me), you can expect to make up for that with a little - or a lot - more blood, sweat, tears, and often money at some point down the road.
• Even when companies make wonderful "open source" overtures, you can expect that they will remember that they have a product to sell.
• Adobe's Flash development documentation stinks.
• When developing AS3 applications, at least when it comes to E4X and XML objects, you can't nest calls to QName (e.g., xml.descendants(new QName(nsUri,nodeName));). You have to separate the two calls.

Check out my guest post on the Google AJAX APIs blog!

http://googleajaxsearchapi.blogspot.com/2008/11/styling-searchcontrol-guest-post.html

So, I've had this thing for awhile...

So, I've had this blog for awhile now, but I've never really used it. So I thought today that I would change that. I'll use this blog to talk a little bit about my adventures in web development and such things. Thoughts and comments on being human and/or a pastor will go on the other blog that I've had for some time and never actually utilized: http://jgeerdes.wordpress.com. So, there you have it. And here we go!