Bootstrapped startup saves over $100K by dropping IE

As a web developer who deals with IE issues everyday, I can testify that this is worth it for those who can get away with it. If you are a startup that targets anyone creative or "new" end users, or if you have a significant web application, I'd highly consider it.

There are people who say that an experienced web developer can work around IE issues -- and they can. The problem is, the juice just isn't worth the squeeze. Let me explain. The cost to make your application support IE is enormous. And I'm not just talking about the cost to make it work and feature complete in the browser. I'm talking about the cost that you could be working on other products or features that drive the business -- the stuff that really matters and delights users.

Beyond preventing you from focusing on what matters, there's also a significant amount of technical debt that has to be inherited with every IE hack you add to your code base, and in some cases supporting IE can mean saying no to certain product features that otherwise could have been possible. This means that IE is actively inflicting damage to other browsers and is in effect lowering all your users -- even if they have a good browser -- on to a least common denominator experience.

IE also hurts your customer service and support personnel. Troubleshooting IE specific issues and quirks is painful, random and at times non-deterministic. You'll likely be consulting arcane MSDN articles published in the early to mid 2000's, and in general frustrating customers and developers alike. It can affect your entire organization, keeping everyone busy working around the issues -- from your front line customer service people, to product managers and developers. It's simply amazing what damage the browser can and does do to a web company.

I also agree that IE, in any version thus far widely available, is an albatross. In Microsoft's defense, I haven't used IE10 for development purposes nor do I target it (that's because almost no one uses it and access to the browser is hard to get outside of developer previews). But even IE9 is simply too little, too late. And in too little I mean it still doesn't get all of CSS3 right (I still have to create hacks around various issues and have only marginally more confidence compared to IE8). Not to mention the fact that users must be on Vista or Win7 means many Windows users will be stuck on IE8 for years, making it even more irrelevant. By the time IE9 has finally reached critical mass, the other browsers will likely be light years ahead (Chrome major version 30 by then??). This issue with upgrade path and slow speed of innovation is cause for great concern with developing anything on IE.

Developer tools in the IE browsers are also less than stellar. Microsoft has invested large amounts of effort and time into its Visual Studio line of tools and it shows. They are generally high quality and provide an excellent developer experience for working and debugging code. In stark contrast, IE Developer Toolbar, F9 Developer Tools, and Microsoft Script Debugger seem like after thoughts. The experience is subpar in almost every category compared to working with Firebug in Firefox, built-in Firefox debugging tools, and the amazing WebKit inspector and remote debugger. In addition, the tools and usage of them is fragmented across the different IE versions (a different combination of tools is needed per version to debug issues and inspect the DOM). As far as I know, remote debugging isn't widely available for IE, in any version.

Why has this happened? I largely feel that Microsoft's lack of focus on the browser and web standards over the past 10 years, and instead it's focus on Visual Studio and .NET have led them to a serious game of catch up. The browsers themselves are inadequate, the developer tools are not high quality, and the upgrade speed and innovation path takes years. Add all this together and it's a recipe for continued issue and pain with IE - in any version. Incremental improvements may be made, but they are just that. There will always be a game of catchup to be played, along with a new bag of hacks to implement and associated organization pain.

So if you can, do it! Drop IE! Your developers, employees and customers will thank you!

I can sympathise with this. We only support Firefox for our CMS editing interface, and then, only test in the latest version.

This is a somewhat more extreme version of the OPs decision but we also started work on Decal when the only browser with a JavaScript debugger was Firefox[1].

The interesting thing is we've deploying Decal ourselves for quite a while and only now just starting to try and open it up as a platform for other designers.

We have never had a client object to having to use Firefox to manage their content, however in running people through our "Decal 4 minute challenge"[2] we've found a huge amount of resistance amongst designers themselves.

This leaves us in a tricky predicament: we want designers to sell the system to their clients who, in our experience, don't care about using Firefox to manage their content, but in order to engage/on-board those designers in the first place we have to get past that initial hurdle (as it turns out, 4 minutes is way too long and we're refining that on-boarding process down to a target of about 30 seconds).

[1] http://www.decalcms.com/page/Support/#whyFirefox

[2] http://www.decalcms.com/page/4_minute_challenge

These "developers" would have saved company X a fair bit of money by actually researching IE. Microsoft has graciously provided a massive amount of documentation covering most Internet Explorer variants and their quirks (via MSDN)[0].

One of the main problems in web development today is the creation of browser-specific code; "IE6" in particular is a scapegoat for poor code. I found that once I studied MSDN and wrote no browser-specific code that IE 8 became elementary to support. IE 7 soon followed. IE 6 & 5.5 were close behind.

For CSS, the key is understanding that every page does not need to look the same. Furthermore, reading MSDN's CSS compatibility grid[1] provides more insight.

For JavaScript, the key is simplification. Using DOM 0 events over fancy DOM 3 events yields big gains. Avoiding selector engines will also yield gains.

I'm getting very tired of incompetent web developers and their browser elitism. Do your homework.

[0]: http://msdn.microsoft.com/en-us/library/ms533050(v=vs.85).aspx

[1]: http://msdn.microsoft.com/en-us/library/cc351024(v=vs.85).aspx

Choosing not to develop for IE makes perfect sense if you're building an app. Here's my own little anecdote:

In the last 4 months or so I've written around 10k loc for a JS app. and probably 3x that many lines of combines CSS and HTML. Number of hours troubleshooting differences between Firefox and Chrome? I'd say about 8. So one developer day's worth of work to sort out some minor issues with vendor prefixed css. I've gotten to the point now that I routinely go days without testing in FF, and when I do fire it up.... everything just works.

My estimate that supporting ie6+ would have put my progress back by about 2 months. On top of that is the ongoing technical debt of continuing to support IE.

I don't want to say goodbye to potential IE customers and that's where Chromeframe comes into play. Chrome frame is AMAZING. Takes about 60s to install. Allows you to create your own install procedure i.e Your_Site -> Install_Chromeframe -> Your_Site. Doesn't require a browser restart and no admin rights needed. Wow.

Of course if you're just building a regular website then sure suck up the few hours it takes to make it work in IE and bill 2x for the trouble.

"not a single person has ever contacted us requesting support for Internet Explorer."

While that may be considered evidence of potential customers switching browsers just to use 4ormat.com, it may also be considered evidence that potential customers using IE are very much put off by being told to use another browser.

Just running the numbers on a back of envelop:

The company was founded in 2008.

Not supporting IE has saved $25,000 per year.

12 months x $7 per month = $84 per user.

330 lost users = $25,000 +/- per year

10,000 responses to the call for action * 4% using I.E. = 400 visitors who are much more unlikely to use 4ormat.com because the call to action doesn't work. Their negative experience is much more likely to lead to negative network effects than positive ones.

Even worse the lost revenue scales as the customer base grows, but the work to support IE is roughly fixed and is relatively modest.

$25,000 is 4% of $625,000 a year. Above that, the company is losing money (on the back of an envelop). With four founders, one would expect that 4ormat.com's revenue is projected to exceed that or has already.