Why we don’t support Internet Explorer
We’ve already talked about some of the technology choices we’re making as a company. And while our choices on the back-end can hardly be labeled as mainstream, the most difficult choice we actually had to make was related to the client-side as it directly affects our users. Obviously, Javascript on the client is a given, and we love it. However, as most web developers know, the differences between browsers are enormous and developing for all of them is almost impossible (Try using Netscape 4.7 today, if you’re curious.). Still, current conventional wisdom dictates that you should support recents versions of Internet Explorer (Usually, this means Internet Explorer 6 and newer. However support for Internet Explorer 6 is slowly declining, as it’s dropped by major sites like YouTube, Orkut and products like Basecamp.), Firefox and the WebKit based browsers (basically, Safari and Google Chrome). We, however, have decided to drop Internet Explorer support entirely (Note that what we’re discussing here is browser support for our application. The content that resides inside the application will always be available to any web browser, whether it’s a text-based browser with no Javascript support, a low capability mobile browser or Internet Explorer 6. This is based on the principe of graceful degradation.).
In general, the trade-off you face when choosing which platform to develop for is between development time and a larger potential customer base that’s associated with the platform. Looking at the web right now, Internet Explorer still leads the market by a large margin (Wikipedia has a nice summary of various sources with browser usage statisics.). So even if it seems annoying that you have to work around some CSS bugs or still write Internet Explorer specific event handling code for a web site, the payoff in user reach will usually still be worth it. Modern Javascript libraries such as jQuery or Mootools lower cross-browser development time even more by abstracting away lots of differences between browsers, tipping the equation even more in favor of Internet Explorer support.
So why did we choose to ignore the most used browser on the planet? It’s because we decided that in our case, the development costs would simply not be worth it. Obviously, this assessment is very specific for the type of application we’re building. We didn’t just base this on a hunch, we actually have quite some experience in this field: most of us have worked on products like Xopus before. Xopus is an awesome, browser based wysiwyg XML editor. It consist of more than 120,000 lines of client-side Javascript code. A non-trivial part of that is code that completely works around standard Internet Explorer behavior because of its bugginess or complete lack of support. This isn’t about your father’s unsupported CSS selectors or the lack of addEventListener. We’re talking about stuff like having to write your own cursor becausecontentEditable becomes basically useless when working on complex documents. The amount of bugs that are related tocontentEditable, text ranges, drag and drop and the Document Object Model in general are staggering. Most JavaScript projects, including some popular libraries, don’t even deal with these advanced aspects of the browser at all.
Now obviously, the other browsers aren’t all free of bugs. Which brings us to the second problem with Internet Explorer: lack of real progress and transparency. Even if you consider relatively easy and popular features (such as support foraddEventListener), it’s hard to understand why they haven’t been implemented yet and if there is any timeline at all to implement them. That makes the probability of low visibility improvements and bug fixes in the rendering or selection code practically zero. The contrast with the open development of Mozilla and WebKit is huge, where almost everything is publicly discussed and with a focus on constant improvement of the rendering engines and pretty clear timeline.
The current state of the web is actually very exciting right now, if we ignore Internet Explorer for a moment. Thanks to HTML5 there is a lot of progress allowing us to make almost desktop class applications, with support for things like drag and drop from the desktop, background processes and offline support (To be fair, Internet Explorer 8 does provide some offline support.). All of this should greatly improve the user experience with web applications and bridge the gap with desktop applications. No amount of code or smart engineering will allow us to bring that level of experience to browsers that lack these features.
Does this mean that no complex web application should support Internet Explorer? Obviously, it depends on many factors. There are large differences between applications that are targeted to tech-savvy users (where Internet Explorer is quickly becoming a minority browser) or to large organizations (where Internet Explorer 6 is still widely used). We’re a small team and we have to prioritize our development goals aggressively. Large teams with lots of resources are in a different situation altogether. That being said, we were pleased to see that the Google Wave team also chose to drop Internet Explorer support and having Google develope the Chrome Frame plug-in.
Finally, although this might seem less important than the above considerations from a business perspective, there is the loss of friction and return of enjoyment in developing web applications again. Not developing for Internet Explorer means that we can do amazing things with CSS, use new Javascript features in our codebase, and in general rediscover the excitement of the possibilities of the web. And that makes us love web development again.