Slashdot Mirror

← Back to Stories (view on slashdot.org)

Startup Skips IE Support, Claims $100,000 Savings

Posted by timothy on from the what-about-being-platform-agnostic? dept.

darthcamaro writes "Guess what — you don't have to support Microsoft's IE web browser any more to build a successful website. In fact, you might just be able to save yourself a pile of cash if you avoid IE altogether." (Here's the story, from a few days back, in Canada's National Post, about the frugal financing of social startup Huddlers.) Evidently, no one complained about the lack of IE support either. I'd like to read more details about what $100,000 worth of IE-specific development would buy, though; not being dependent on IE sounds great, but loses some sparkle if it means requiring Chrome or Firefox.

9 of 273 comments (clear)

  1. They skipped IE support on their ADMIN pages by gabebear · · Score: 5, Insightful

    They support all browsers when not editing content(the way most people use this site)... this article is also rather old

    1. Re:They skipped IE support on their ADMIN pages by Xest · · Score: 5, Insightful

      It sounds fucking stupid anyway.

      "No one complained about lack of IE support"

      Yes, that's probably just because they fucked off to your competitor who made even more cash than you because they did support the 33% or whatever of the global population that is still using IE.

      Besides, modern IE isn't exactly that difficult to support. Most browsers are much more forgiving and less picky than they were just a couple of years ago so if it displays right in Chrome/Firefox, chances are it does actually work just as well in say, IE7+ anyway.

      I don't like IE, but not supporting it is still just plain fucking stupid as you a) throw away a sizeable portion of potential customers, and b) It's not hard to support recent versions (which is the bulk of usage) now anyway. The $100,000 savings thing is either a big fat troll, or they have some either really really incompetent developers, or really really overpaid developers. If it costs you that to support most IE users when you already support say Firefox, Chrome, Safari etc. then your site and/or team is horribly broken.

      We support all these browsers as well as Blackberry, Android, iOS, WP7, Symbian to boot, and I can't see how if you've been sensible about your use of templating/stylesheets/javascript libraries like jQuery etc. you could possibly spend this much on IE support unless you're trying to support as far back as like IE3 or something. It implies they're willing to pay the equivalent of say, a standard front end developer $50k a year to spend 2 years on IE support which is frankly fucking insane.

      I suspect this story is just a rather long winded way of saying "We don't like Microsoft, down with IE" rather than something that has any basis in fact, which is also a shame really, because if they'd just come out and said that - i.e. exactly what they meant - then I'd have been able to just reply and say "Yep", instead.

    2. Re:They skipped IE support on their ADMIN pages by TheNinjaroach · · Score: 5, Insightful

      Besides, modern IE isn't exactly that difficult to support. Most browsers are much more forgiving and less picky than they were just a couple of years ago so if it displays right in Chrome/Firefox, chances are it does actually work just as well in say, IE7+ anyway.

      I wish this lie would simply go away.

      There is something fundamentally broken when your web browser requires non-standard markup in order to display standards-based markup.

      --
      I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
    3. Re:They skipped IE support on their ADMIN pages by Vanderhoth · · Score: 5, Insightful

      As a web developer I can tell you you're correct. I have CSS and jQuery that work perfectly with FireFox, Chrome, Opera and Safari. Then I have special case CSS files for IE 6, 7, 8 and general case IE. Other browsers rarely need special case rules and never at all require special case rules for every version of the browser.

      I deal with a lot of scientific data and dynamically generate graphs and plots based on variables selected in forms written in PHP. Almost guaranteed when I develop something in IE, it won't displayed correctly in FireFox, Chrome, Opera and/or Safari. If I develop something in FireFox I can't say I've ever had a problem with Chrome, Opera, or Safari, but it almost never works in IE and special case rules need to be written.

      Just as an example, I have a page where a user determines the type of species they're looking at by answering questions. My organizations web standards group provided me the jQuery and CSS for the feature. The questions are contracted links in a tree like structure and are formatted as "Does the species have XXX?" or "Does the species have YYY?". When the user clicks on a link the section expands and asks another question until the user gets to the linked name of the species they're looking for, which takes them to a page with more information on the species.

      The page works fine in FireFox, Chrome, Opera, and Safari, but doesn't work the same way in any IE browser. The progress enhancement solution for IE is to have all elements in the tree automatically expanded. The fact that this doesn't work in IE is a real pain in my ass. I demoed the page in FireFox and the content owner liked how it worked, but he uses IE and wasn't happy when I told him it didn't work the same way in that browser. So now he expects me to go through all the jQuery code and CSS to make it work the same way in not just IE, but every version of IE, which I'm not doing because 1) I've been told I'm not to modify features provided by the web standards group in order to ensure our web content complies with Web Content accessibility Guidelines 2.0 and 2) when the web standards group provides me with updates for jQuery features like this I'd have to go and re-update all the code again.

    4. Re:They skipped IE support on their ADMIN pages by Alex+Zepeda · · Score: 5, Informative

      You're kidding, right? IE8 lacks: Rounded corners, SVG anything, more robust font support, most HTML5 goodies (enhanced form support for things like validations and placeholders), text on canvas, CSS media queries, javascript optimizations like nested arrays and getElementsByClassName. IE8 is definitely a primitive browser.

      IE9 is much closer, but it's still pretty bad. AFAIK it still doesn't support rounded borders + gradients and it has a number of problems with its SVG support. Others have linked to caniuse.com, but I'll point you in the direction of D3's issue tracker>.

      If you're doing a dead simple site, sure IE8 not too bad. If you're trying to take advantage of "new" features, you're pretty much SOL (even with IE9).

      --
      The revolution will be mocked
  2. Re:Here's the memo the interviewees missed by SJHillman · · Score: 5, Funny

    You obviously haven't spent much time on Slashdot or Facebook.

  3. It's shennanigans by crazyjj · · Score: 5, Informative

    First of all, the summary has it wrong. The company is 4ormat, not Huddles. And read this article for an explanation of how this claim is just a publicity stunt. It works just fine in IE (ironically, the only browser it doesn't work in is Opera).

    --
    What political party do you join when you don't like Bible-thumpers *or* hippies?
  4. Re:Useless by Anonymous Coward · · Score: 5, Interesting

    I'd like to read more details about what $100,000 worth of IE-specific development would buy, though

    Boring pixel perfect rendering to make the artists happy. Blah.

    This. So very this. I'm involved in a web project right now where both IE support AND pixel-perfect rendering are apparently vital (it took us about a month to convince the spec designers of the concept of "your fonts are not the user's fonts" and "Illustrator is NOT a web design tool"). We're actually expected to maintain pixel-perfectness in an automated testing environment. Seriously, half our development time has been wasted trying to figure out how to test this with an art department breathing down our necks with pixel-measuring tools for a web application.

    So you can see why I posted anonymously.

  5. Re:Useless by n5vb · · Score: 5, Insightful

    And the original concept of the Web was specifically not intended to do pixel-perfect rendering of anything. HTML was specifically designed to mark up flexibly depending on the dimensions of the window space, and use local fonts on the client rather than supply fonts from server side, so getting pixel perfect rendering of a site is essentially fighting a whole pile of client-side unknowns that may vary widely even between instances of the same browser rendering engine that are doing exactly what they were designed to do based on the HTML spec (although because everyone wants their site to "pop" and grab viewers' attention and all that other marketing BS, the spec itself is now starting to drift toward pleasing high-end art departments .. ::eyeroll::)

    And remember that JavaScript was originally part of MS' "embrace, extend, extinguish" strategy, and the open standard it evolved into differs subtly from the version MS still implements in IE. (And that aspect of IE integration can be a massive rectal pain loaded with horrendously screwy little gotchas.) So if you do anything major on client-side, including pretty much anything even vaguely resembling Ajax, you're stuck with two parallel development/testing cycles, one for IE, one for pretty much everything else. I actually abandoned IE support on one site I was building because I just didn't have the time to mess with it.