Bootstrapped startup saves over $100K by dropping IE
techcrunch.com
techcrunch.com
tl;dr: if you build a tool which solves a significant and recurring pain point for creative professionals, you can get away with not supporting IE.
The article does not provide much insight into building a consumer-facing application--this is the equivalent of a company using an intranet app which is IE6-specific.
This is less about supporting this browser or that browser and more about making sound business decisions and putting our users’ needs first. We’d like to think they would rather see requested features over support for a browser they don’t use.
You can make up a new title if you want, but if you put gratuitous editorial spin on it, the editors may rewrite it.
So no, HN is not strict about the title.
Is this the case?
I thought the one of the explicit rules was to remove "Insert number ways/apps to increase productivity" and similar enumerations from titles. I also thought there was a general rule of thumb to remove hyperbole?
"AirBnB: Crimes committed against a host"
to:
"Violated: A traveler’s lost faith, a difficult lesson learned"
The rational at the time was that the change was done since the original title didn't match that of the linked blog post -- see pg's comment[2]. The counterargument being that the original title helped increase awareness of an important story that would have been harder to accomplish with the generic title.
You can make up a new title if you want, but if you put gratuitous editorial spin on it, the editors may rewrite it.
Is spin.
It drives up links due to an emotional reaction. If your linking to a post called 'lost sheep' and you could change it to 'efficient distributed counting' because that's more descriptive and without spin. But, 'lost sheep (distributed counting)' is more in the spirit of HN IMO.
I know codecademy doesn't support ie7 and ie8.
http://www.computerworld.com/s/article/9217279/Google_to_dum...
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.
Sure, in IE6, even the PNGs weren't working properly, but, talking layout, IE7+ is mostly a question of 5-10 additional rules (on small scale websites) and IE8 actually works without any (mostly), save for a css3 features like border-radius, etc.
As for the design, having less visual effects and no rounded corners doesn't have to be a problem – most of the designs work without it rather well (not to mention 4ormat's design doesn't use plasticity, gradients and shadows that much)
This article would gain much more credibility if it mentioned at least one or two technological obstacles that take you more than 30 minutes to sort out.
I'm not saying there [on the 4ormat] isn't technical solution that could be this expensive to debug on IE, but none is visible on 4ormat page and nothing less obvious is mentioned in the article, thus diminishing article's credibility;
You know, instead of something awesome like 'we implemented geolocation, offline aps and 20-years-too-soon-UI, so we ditched IE', they are doing 'Hurr Durr bad IE can cost up to totally out of my ass pulled $100.000'.
This is the lowest quality article I have ever read for a product which virtually no-one knows (except the minute techcrunch ecosystem and out of pocket VCs) trying to trash a product which is actually used at least 5 orders of magnitude more often by 5 orders of magnitude more people.
Trashing IE was fun once, but the world has grown up in the last couple of years.
Also, that's a theoretical 100k saved now until the Windows tablet market and Windows v.next peak grows (which it will as it always does) at which point it'll cost 200k to sort it out. I worked at a Microsoft monoculture org for a number of years and that's what happened when other browsers had to be supported (Firefox, Chrome, Safari). Save now, pay later.
Welcome to the 2012 version of an IE6 only web site...
IE is deserving of the trashing it receives.
Errr... no. Active X was a tiny part of the problem. IE's problem was to support basically any quality of markup thrown at it, when other browsers couldn't. Then developers rely on this, which pushes their sites into IE-only zones. As time passes it gets progressively more difficult to extract a site out of this tar-pit.
It amuses me that the arguments for not supporting IE echo the same arguments IE-only advocates were using as a reason not to support other browsers a decade ago.
No one is using the same arguments for not supporting IE. People are saying browsers should adhere to the standards, which is totally different.
I'm not saying preemptively design for it, but if you preemptively exclude its predecessors and your path will be frought with many less turds to not step in i.e:
In 2 years: "Oh shit we did it all in Webkit and Gecko features - The growing 20% of Windows tablet market doesn't support it - we're going to have to rewrite or ship an app both of which are costly".
If Windows tablets take off (and that still seems like rather a big if), you'd hope they have a vaguely compatible browser.
Doesn't look like that they are User-Agent sniffing, so that means that maybe they are detecting features. That's kinda the right way of doing it - except for their failure to adhere to progressive enhancement best practices.
But feature detection isn't "No Internet Explorer support here" approach. So the story seems at odds with the actual behaviour of their site.
Now what happens when an Internet Explorer - either on the desktop or tablet, or phone, passes the feature detection in place on this site? You don't get the "Go Away!" message, but instead you get an insufficiently tested experience which exposes the lack of attention on quality - that's something that's going to turn away an audience geared to wanting to see quality.
If you are going to publicly stop supporting an entire browser range, make sure your developers don't leave obvious gaps in that non-support. Maybe here's one place where User-Agent sniffing actually complements the actual requirement.
Webkit is just another form of monoculture.
What is v.next?
If you are catering to creative professionals, who are going to be using huge apple monitors and macs (66% of the site's users are on a mac), ignoring IE isn't going to be a big deal. Even many of those ~4.5% of IE visitors might be on IE9 /10 which are pretty decent browsers. I am not here to support IE, i hate it like every other developer who builds stuff for the web. Also, compete.com tells their approximate UVs for February was around 13k. Ignoring a small number of users here is not going to have a huge impact. If your are site/app with millions of users, then it will be a big deal.
PS: If you are building a hipster social network or a video post processing tool, ignoring IE is going to save you significant time but if you are catering to e-commerce/finance or any other common demographic even thinking about ignoring IE isn't wise at this point.
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).as...
[1]: http://msdn.microsoft.com/en-us/library/cc351024(v=vs.85).as...
I can grasp what you're referring to. Bleeding-edge features are tough to support in large part because of Internet Explorer's slow release cycle.
However, the decision has still been made to jump onto a runaway train. All users should be treated the same. Choose an approach that doesn't pick favorites.
BTW, when you refer to code that isn't "browser-specific", do you mean compliant to web standards? Or to the minimum working set between all browsers? Aren't most of the IE hacks people use "browser-specific" to IE?
Regarding your aside, I'm referring specifically to a generalized approach based on observations and not assumptions. I don't consider something trivial such as `event || window.event` browser-specific; it's a strategy used in accordance with multiple event models. You might be surprised to know that Microsoft created the blueprint for the DOM 3 event model (via attachEvent, etc.). They also were the first to use `innerHTML`, `innerText` and `Element.children`.
I'm pretty sure if Gruber/daringfireball.net dropped all IE support, his traffic decline would be close to 0.
On the other hand, if codeguru.com did the same, their traffic would probably drop off close to 75+%.
If your budget is tight or skills limited, focus on your target market first and make that experience the best you can. Though, that pretty much applies for browser support as well as many other things.
We could get away with not supporting Chrome and Firefox though as I doubt anyone would notice.
I can imagine that look so well...
65% of their traffic is from Mac users, so this sounds like a good decision given their audience.
Almost without fail, fixing stuff for IE takes as long as it does to just build the feature in the first place (so 4 hours to do a layout then another 3 or 4 to get it working properly in IE), with CSS/html layout that number has dropped as IE6 has been phased out, but I find that its actually moved over into doing js stuff in IE8 and 7.
There's no reason not to have multiple browsers quickly available - modern computers have sufficient processing power to run multiple applications simultaneously these days.
That's what I have been doing but would like to get away from this as some employers frown on it.
It all depends on your market!
If they had an existing web presence we'd get their logs and figure out about how much traffic they'd lose by dropping IE. Few were willing to pay for it.
(And I was happy to cut my headaches down by an order of magnitude)
Speaking as someone who can tame IE, I can categorically state that I don't want to. I'd much rather have that time back so I could do something much more fun.
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.
Now factor in support costs. I can picture it now:
Customer: Uhhh your app sucks it's so slow.
Support: Hmm looks like you're using IE6. We've worked really hard to make our app function in every browser, however if you'd like the best possible experience then please upgrade.
Customer: What's a browser?
The best solution is to use chrome frame. The installation can be made seamless and if your app is worth using then your customers wont mind the extra 60s it takes to install.
Slow speed of execution in IE might well be considered a vast improvement compared to the current state of affairs in regard to the potential customer's standpoint - i.e. IE not working at all.
Again, "change your browser" is a poor way to convince the customer that 4ormat.com is worth using given that the customer has already responded to the call to action.
Indeed, one might argue that there's no excuse for failing to inform the potential customer that IE is not supported before the call to action is clicked - obviously 4ormat.com is capable of testing for browser versions.
Slow speed of execution in IE might well be considered a vast improvement compared to the current state of affairs
Unfortunately the general public doesn't think like that. To the average Joe your site is slow therefore it sucks.
I can't imagine supporting IE 9+ would take that much money. But then again, I don't run a startup.
IE7 is pretty good and aside from a few glitches and IE specific stuff
IE6 is pretty good and aside from a few glitches and IE specific stuff
Isn't that the point
It's a cost-benefit analysis. Messing about with words by stretching the what you can reasonably describe as "few glitches and IE specific stuff" to try and draw a false equivalence doesn't change the actual analysis.
IE8 is way too painful. IE9 is starting to go from "huge pain" to just within the realm of possibility.
IE10 is a different story. Maybe.
[1] http://arstechnica.com/business/news/2012/03/browsing-behavi... - as of Feb 2012, IE8 had ~25% and IE9 had ~15%, source: Net Market Share
I totally see that IE6 & 7 are not worth the dev effort, IE8 is probably border-line, but IE9 is a good browser and people seem to be vastly exagerating how much work goes into getting IE9 to look and work like other browsers (i.e. not very much).
So not supporting IE9 seems a bit lazy to me, and I have to say, a little "religous" (they seemed to have ruled out IE10 already without doing any research into why). Also find it strange that they actively block it rather than just warn people about it being unsupported.
However, I will cut them slack because the target market are creatives, and it's an admin site rather than a consumer level site, so probably few IE users here. But others here seem to be extending this idea to the public web, which seems like a mistake...
People know there's something uncool about IE, even if they don't know why. And it can be replaced in 5 minutes.
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).
Having recently developed an HTML5 single page web app, I can assure you that this statement is utterly false.
In general, though we do have to spend time tweaking things between Chrome, Firefox, and Safari, IE8 and 9 still account for a significant portion of time spent getting things to work cross browser. For me, that time is so significant that I too completely ignore IE unless someone specifically asks for support.
Point is, IE, even in its latest form, is still not at the same level as the competition. I'm aware of all the reasons why I shouldn't ignore it but I do so in protest, not laziness and I hope one day a significant portion of the design community gets on board with it. If the web breaks for IE users maybe then Microsoft will make it behave sanely and try to get people to upgrade. Though I must say that the one thing I applaud IE for is it's box model. It is far more intuitive than the official spec.
Live with the features that work properly. Don't jump on every new bandwagon like gradients and then go ape shit when it doesn't work.
To be honest, it's not like all that shit really improves a product if it does something useful already. TBH IE6 can shift out a product that improves lives and earns money fine without being a pain in the arse if you accept its feature set.
We already live with the features that work properly but why can't we criticize features that dont work properly? When a spec changes we can't expect old versions of browsers to support it, that's fine. But when a spec changes and a new version of a browser comes out claiming to support it but really doesn't then we have every right to criticize it.
When IE9 came out Microsoft raved about how advanced it was and how we would get to play with all the new css3 features, etc. but that wasn't true. It was a big leap forward from version 8 but still not up to snuff compared to other browsers.
We certainly can create products that are incredibly useful even in older browsers but it's ludicrous to say we should just live with the limited feature set of IE. we're talking about the web here. A place where technology moves so fast that paradigms shift in a matter of months, not years. When every other browser on the market has been reliably supporting X features for several years now but one holdout still doesn't implement it like any of the others at all I'd say we have the right to criticize it.
Your tone makes me out to be like someone who just discovered web design and is using it like people used to use the blink tag in the 90's. That's not the case. This isn't about bandwagons nor is about the CSS3 features I mentioned. I only used those because they came to mind first. I'm very aware of design elements that are overused and those that need to be used with caution. You need to remember that functionality is only a piece of the puzzle. Backend design and front end design both play critical roles in making the user happy. Good design is about surprise and delight and since most browsers support it, we should be able to use parts of the new CSS spec now but IE is still holding us back as it always has. There are good reasons to use these features and not all people who use rounded corners and gradients are using them gratuitously like you imply.
Here are my reasons for wanting to use them: I want to cut down on the use of images for design (I can literally cut 90% of my image use by using css3). I want to speed up page load times. Stop depending on JavaScript as much (related to load times too). Finally, I just want to surprise and delight my users. Give them a beautiful experience. What I build may do its job but if its interface is boring and a chore to use then I messed up my job.
So should we all just "support the working features" of the lowest common denominator despite the fact that there's a ton of great features that are widely supported elsewhere already? Please don't be a design snob and look down your nose and assume anyone using css3 is jumping on some bandwagon lest you miss the point entirely.
As the parent and a a person with 16 years (yes that many years!) of experience managing and putting together well known corporate web sites and web apps, I'd say that yes you should.
The web is about being open to everyone regardless of the technical limitations.
This particular application is aimed at a narrow category of professionals, none of whom are likely to be using IE, or at least tied to using it. It would thus seem like a bit of a waste of effort to support it, given that it's more troublesome to support than WebKit and Gecko, and also given that Microsoft has promised that IE's standards support will improve, so it'll probably just work on IE10 anyway.
yeesh
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!
There also just aren't that many users showing up to our site using IE. That graph in the article is straight from Google Analytics for our main landing page.
WWW - as envisioned by Berners Lee - is getting worse.
> Berners-Lee identifies universality as one of Web’s key principles, providing people with the freedom to link to anything, regardless of hardware, software, or Internet connection.
I pay my rent with money, not with good intentions by some guy who has been granted a nighthood.
That said I assume a fairly standard webpage is rendered decently in Opera so I wouldn't block it (as I would haave done to IE if it had had the market share of opera).
As for Opera, should they support any oddball browser engine out there with it's particular quirks?
Two words for you: "opportunity cost".
If you just ignore it in testing, fine.
But if you actively block it then you are evil and no one should copy you.
If it happens to work in IE, then fine. If not, tough Rocco's.