Hacker News new | ask | show | jobs
by stutter 5156 days ago
You don't have comments on your blog, so I'll comment here:

IE testing is "hard" on a Mac because of the vm requirement, yes. However, that's not even my main issue. If Microsoft facilitated having VMs of each windows installation + browser version available for that OS to developers, it'd still be "hard" but at least they'd be helping. IE only runs on Windows, so if you want to test for Windows you have a bunch of sub-par options, or really expensive options, or..illegal options, pick your poison.

That's not even my biggest complaint about it, though. I have two main complaints.

First, the development tools available to Internet Explorer are absolute butt hole. Javascript is considered a second class citizen, and is nearly impossible to debug efficiently. The amount of "oh lets try this for shits and giggles" that is required, to see if it will fix a random IE issue is absolutely astounding. I typically find my solutions to IE issues by complete accident, and upon reflection say to myself "well..that's the most stupid thing I could have thought of - so no wonder that works." Not simple, stupid.

It feels like Microsoft deliberately takes the stance of making it HARD to develop software for Internet Explorer. I don't know if this is purposely their philosophy but maybe they're diluted enough to think it helps turn out higher quality applications. It doesn't, what it produces is a horrible user experience designed for the lowest-common denominator. And the worst part about it is that most of your end-users use IE. So, what it results in is crappy, old feeling, slow web applications and an influx of user complaints about things not working or taking too long (because the javascript engine is about as slow as the Ruby interpreter).

Second, the IE user base is so incredibly fragmented across versions. And it's not like the difference between chrome 13 and chrome 18 where some css3 features don't work, or websockets is slow, or whatever. The difference is that entire feature sets are missing, or work differently. In one version CSS box width includes margin and in the next, it doesn't. That's a pretty significant change; it completely ruins the entire flow of your site and you have to account for "special" cases of old browsers. Except, your "special cases" of old browsers are 30% of the internet population.

Supporting IE is a time sink, but not just because it's "hard" to set up Windows environments, but because Microsoft actively tries to make it hard for developers to code, test, and debug applications in Internet Explorer. Or doesn't make an effort to alleviate the pain; either way it's active effort in creating more suck, imo.

Disclaimers: I've been developing on Mac for 4 years and haven't used Internet Explorer as an every-day browser in 7 years. IE8 made some improvements to JS debugging (SOME) and is vastly better than 6 and 7. IE9 might be amazing, and IE10 might be the best browser in the world - I don't know. All I know is that debugging IE takes almost as long as building the application did in the first place. Until that problem is solved, IE will still suck and still get a lot of hate from the development community. Microsoft has a giant mountain to climb to get their reputation back to "neutral" in the web development community.

5 comments

> If Microsoft facilitated having VMs of each windows installation + browser version available for that OS to developers

Which they do, they've been offering complete VM images with various combinations of Windows and IE for some time, the current offering is XP + IE6, Vista + IE7, Win7 + IE8 and Win7 + IE9: http://www.microsoft.com/en-us/download/details.aspx?id=1157...

While the images are for VirtualPC, I've yet to have any issue importing them in VMWare or VirtualBox.

> IE8 made some improvements to JS debugging (SOME) and is vastly better than 6 and 7. IE9 might be amazing, and IE10 might be the best browser in the world - I don't know. All I know is that debugging IE takes almost as long as building the application did in the first place.

IE9's devtools are significantly better than IE8's: more feature and much more stability. They are nowhere near WDT/Firebug yet (or even Dragonfly), but they are a huge improvement over the POS that IE8's devtools are.

> Which they do, they've been offering complete VM images with various combinations of Windows and IE for some time, the current offering is XP + IE6, Vista + IE7, Win7 + IE8 and Win7 + IE9

I've used the IEVMs project on github to install these VMs before; it failed. I'm trying it again as we speak, maybe it's a viable solution, maybe not.

> IE9's devtools are significantly better than IE8's: more feature and much more stability. They are nowhere near WDT/Firebug yet (or even Dragonfly), but they are a huge improvement over the POS that IE8's devtools are.

Obviously the problem here is that IE9 represents 25% of the currently in-use IE browsers and has (to quote rey bango, http://blog.reybango.com/2012/05/08/hey-paydirt-your-site-wo...) 35% world-wide Win7 marketshare, which as I saw somewhere (maybe arstechnica) only has 50% marketshare. So you're looking at ~17.5% give or take for other versions of windows running IE9, call it a conservative 25% adoption for all IEs across the web.

TL:DR; IE9 has a ways to go before it's new amazing developer tools are valued significantly. Until then, we're still stuck with IE6-8 ):

You make valid points; and the VMs available on their site should help testing availability. It's too bad that the debugging is still second-class and torture ):

> I've used the IEVMs project on github to install these VMs before; it failed. I'm trying it again as we speak, maybe it's a viable solution, maybe not.

The official ones work. I'm actually installing the IE7 version as we speak, IE8 and IE9 are running fine in VirtualBox.

> I've used the IEVMs project on github to install these VMs before

I don't know about that, downloaded them straight from Microsoft's website.

> Obviously the problem here is that IE9 represents 25% of the currently in-use IE browsers

Note that IE9 can be switched to IE8's engine (there are differences with the official IE8 but not that much, so most of the rough work can be done with IE9's devtools even using the IE8 engine).

> IE9 has a ways to go before it's new amazing developer tools are valued significantly.

I did not say IE9's devtools were "amazing", because they are not (unless your only comparison basis is IE6 devtools or pre-firebug Firefox devtools that is). But they are significantly better than IE8's (let alone 6/7)

IE9's debug tools are hands down the best at this point in time. Although Chrome's is cacthing up, pound for pound you will be far more productive in IE9s debug tools then firebug, dragon fly or any other at the moment. I think there is just too much bias at play here.
I have downvoted you because that statement is so absolutely wrong.

I know because I am debugging a stupid, stupid IE only issue and I have to use a combination of Chromes debugger and judicious use of the console/repl in IE.

You can't even inspect an element that was added in code in IE.

wha? Hit the tiny html refresh button ctrl-b select away.
I sincerely hope this is a joke.

If it isn't, can you demonstrate where IE9 is objectively better than Chrome or Firebug? Because I can do the opposite. As a quick example, IE9 won't let you inspect elements inside of an iframe dynamically generated with JavaScript.

I've got a simpler one: you can't inspect an element on the console, it's going to print the first 10 properties (as a string, so you can't actually see their value when they're an object or an array) then it tells you to add the object to your watch (in a sub-tab of a different tab) to explore the rest.

In fact the console in general is still garbage, they improved support for the console API but still only handles barely half of it (no group/groupEnd, no time/timeEnd, no count, no trace, ...); the console does not understand (and is useless for) DOM objects (let alone jQuery objects); console API calls refuse to link to their source line; ...

Then there's the DOM inspector which will fail to display JS-generated DOM[0] and provides no way to edit the DOM live (beyond attributes, woot, attributes) (let alone put inspectors/breakpoints on DOM changes) and provides no way to see what events are bound on a node, or the network log which is a mess of useless tabs and the last network log to not know about JSON, or the javascript source/debugger which provides no way to jump to a given line (let alone a given function) and takes pain to split all useful information across 5 different tabs to ensure it's never possible to eyeball the situation you're in.

And that's 5mn into opening the thing. God, I can hardly believe somebody would state IE9's debug tools are good, they're not even remotely a match for Dragonfly, let alone Firebug or the WDT/CDT.

[0] super awesome when combined with applications which generate all of their DOM via code.

IE9 can easily handle your quick example. Check out http://jsfiddle.net/c8rN3/ then hit f12 bring up the developer tools. In the HTML tab click the tiny refresh button then hit the select element by click and select an element within the iframe.
> IE9 won't let you inspect elements inside of an iframe dynamically generated with JavaScript.

What the hell are you doing with iframes? Sounds like a hack job.

I'm adding an iframe to the page dynamically using JavaScript?
Irrelevant and besides the point.
Just to say I'd not come across the MS created VM images, so thumbs up for making my life a lot nicer!
Has it occurred to you that at least you're legally allowed to virtualise Windows+IE for web development testing? On the Windows side of things, devs aren't even allowed to virtualise MacOS! And you complain about lack of options for Mac developers! Pot calling the kettle black?
Point conceded.

Though, certainly a +1 for choosing Mac as your primarily development environment; as it can run all the other operating systems you'd care about (:

True, though many of us feel very comfortable developing on Windows. Seems unfair that we should pay the Mac hardware tax just to test with Mac browsers when Apple could provide OSX on a VM, license-restricted for testing purposes or similar.
Safari testing on Windows is "hard". For whatever reason Safari on Win can produce different outcomes than on Mac. Further I don't even have the option of running OS X in a vm unless I settle for a hackintosh.

"First, the development tools available to Internet Explorer are absolute butt hole"

Yes the build-in dev tools are not on par with the other browsers but I wouldn't say that Visual Studio is butt hole. I don't use it myself but as I understand it is generally acclaimed to be one of the best IDEs. If you don't want to run VS which I perfectly understand then go with MS Script debugger. It would probably bring down your number of "shit giggles"

"It feels like Microsoft deliberately takes the stance of making it HARD to develop software for Internet Explorer"

It feels like Apple deliberately takes the stance of making it HARD to develop software for Safari qua not providing vms.

"Supporting IE is a time sink, but not just because it's "hard" to set up Windows environments,"

I can provide the same argument for any system which I am not familiar with.

"but because Microsoft actively tries to make it hard for developers to code, test, and debug applications in Internet Explorer."

From what my MS developer coworkers say they are actually quite pleased with how much MS gets involved in their development community. But that's just anecdotal I guess...

"I've been developing on Mac for 4 years and haven't used Internet Explorer as an every-day browser in 7 years"

Well maybe it is time to learn it again then. Lots of things have improved. What do you know - you might even make life easier for yourself...

> Safari testing on Windows is "hard". For whatever reason Safari on Win can produce different outcomes than on Mac.

FYI, all browsers can and do. That happens on Firefox and Chrome as well (though maybe less regularly)

I'd be curious what the market share of Safari is for Windows. I'd say it was so niche that it might not be worth the bother...
> I'd say it was so niche that it might not be worth the bother...

From what I understand, it's there more as a testing tool for developers using Windows than for any sort of market share, even on OSX Safari does not enjoy a tremendously high marketshare even though it's the bundled browser.

I'm not a html/css frontend developer so I don't need to test on IE too often, however, when I do I use Virtualbox with some different windows installations. Works like a charm.

I have no experience with the development tools in IE8+ (I've been a Mac user for a while now), but I've been told they're pretty descent. I completely agree though, debugging in the older IE's is hell...

But the thing is, the user couldn't care less whether a developers work is easy or hard, the user wants a good experience. And thats the job (most) frontend developers chose, if developers don't want to do that, they shouldn't be a frontend developer.

I used to hate getting websites to work in IE6, which is why I don't do html/css anymore (I became a Flash dev, so I'm switching again). If frontend devs don't like their job, they shouldn't blame Microsoft for making "crappy browsers" or a "though enviroment", they should find another job.

Thanks for taking your time to comment on my post, even while I don't have a commentform on my blog (couldn't find a descent commenting solution for Octopress).

I agree that saying it's "too hard" is a cop out. But Microsoft doesn't provide the proper tools, that's not a cop out. I don't want to support IE6, but I know that if I don't put effort into it - customers will complain. When customers complain, someone complains to me. When people complain to me about dumb crap (like IE6 taking too long to load or "it just spinning") I get angry, then I have to waste time finding a fix \:
RE: comments on blog: Use disqus. Drop an html tag and a script tag on your page and you're pretty much done. http://www.disqus.com/
Hmmm In IE9 you can switch browser mode to previous versions (back to IE7).

Seems a lot of people on HN are still stuck X years ago when things sucked and they refuse to look at things as they are today, just like you state in your "IE9 might be amazing [...]" comment. That just calls into question, though, your comments on how hard it _is_ to develop for IE. All you have said is how hard it _was_ to develop for IE.

Anyway, I don't buy the whiny bit of "I don't want to do it because it's hard to do." Seems like a cop out and more aimed to justify prejudices.

You can, but then you're not testing IE7, you're testing IE9 in IE7 mode. That's a condition which may be worth testing in some circumstances, but it's not the same as testing IE7 properly.
Yeah I actually had to learn this the hard way. Clients complaining about things not looking right in IE7/8 when I tested using IE9 in IE8/7 mode. You need the actual browser to be sure you've tested everything.