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 \:
> 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 ):
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.
Profiling PHP with PHP is kind of humorous, I'll concede. But it can certainly help alert you to slow-running pages, queries, and steps. Which should at least give you a starting point or prompt you to dive deeper with a stronger/more robust tool like xdebug+kcachegrind.
Thanks for checking out the library and providing feedback though, I appreciate it!
I also use XDebug + kcachegrind, but I wouldn't consider that a 'quick' way to identify slow-ups (mainly because of how my set-up looks).
I'll agree that manually creating steps around code you suspect to be an issue could be a pain in the rear, but it's not proven to be too terrible here.
Also, the profiler still shows you total execution time for the page regardless of adding profiling blocks. We also speak with our databases through a single class, so we can easily wrap query calls with the query profiling methods and identify slow queries.
Anyway, your points are completely valid. Thanks for looking it over and sharing your feedback in a constructive manner. It's nice to be able to leave my flame suit at home. heh.
Both are valid points (editing code in order to profile), and you're absolutely right regarding blindly adding profiling wrappers "just because." You can certainly do that, but it's likely to be far too granular in a lot of places. The profiler attempts to hide the insignificant blocks so as to not make the output too noisy.
We use this profiler integrated into our in-house framework, so it's built-in to things like database access and action execution, with all the config/set-up separated. It took about 20 minutes to add the core set of blocks, not too bad; but I can definitely see and understand exactly where you're coming from.
Though according to the manual short_open_tag is true by default, this is a valid point. The safer way to write this would have been to open all tags with <?php instead of <?. I'll update that.