Skip to main content

A year with Modern.IE



For a little over a year I've been working with Microsoft on the modern.IE site. This week the site is celebrating having saved developers one million hours in browser testing. Some of the savings come from the free pre-configured VMs with real copies of the different IE browser versions. Just about all the popular VM software is supported on several different platforms. There is no substitute for using the real browser when it comes to compatibility testing, and these VMs are one way to do just that with minimal hassle.

Further time saving comes from Browserstack. It provides convenient in-browser testing of just about any type of browser or device. Modern.IE offers a free three-month membership to Browserstack for IE versions. There are Chrome and Firefox plugins that make it really easy to quickly try out your latest designs on any version of IE, even if they're served off your local computer. Very slick.

Most of my work on the project was done for the online compatibility scan, available directly off the home page but also downloadable for local use. It scans the HTML, CSS, and JavaScript of the site to see if there are things that may work in one browser but not in another. This includes things like outdated JavaScript libraries, missing CSS prefixes, browser sniffing, missing doctype, or use of ActiveX controls. It also suggests features that might improve the experience for Windows 8 users, such as high-quality favicons.

The scanner project is open source, written in node.js, and hosted on GitHub. This tool is meant to be useful to your web development diagnosis and debugging, so open an issue in the repo if you find problems or have suggestions.

For even more information, you can run your site through Compat Inspector via Sauce Labs to find code specific to older versions of IE that might cause things to break with modern IE versions. To use this feature, just click the "Scan for code no longer supported in modern IE" tab once the initial scan is done. On that same results page you can also get screen shots of how the page appears in various browsers, as another quick check that the layout is functioning properly.

Quite often I'll hear developers say, "All these versions of IE are a pain and make my job harder! Why are there so many versions and why can't I just run this on a Mac where I do my development?" There are so many versions of browsers, not just IE, and yes that is the burden of the web developer. The Android 2.3 browser is just as much of a pain to today's web developers as older versions of IE, and that will get worse before it gets better. New phones are still shipping with that ancient Android browser, but at least the market share of older IE is shrinking.

As for why you can't run IE on your Mac, let's turn that around and ask why Windows-based web developers can't run Safari to do testing. Apple doesn't make VMs available to do that the way Microsoft does here. Fortunately, Browserstack does support many versions of Safari. Perhaps Apple will make free Browserstack testing available for Safari. No matter what, though, responsible web developers should test on every browser they expect the audience to use. Microsoft has done what they can to make that easy.

Comments

Post a Comment

Popular posts from this blog

Tragedy of the WebKit Commons

With Opera announcing that their future products will be based on WebKit, the Internet is abuzz with discussion about what that means and whether it's a good thing. Looking at it as a jQuery developer, it's a good thing if it gets WebKit participants to fix bugs and update older implementations. I can't be optimistic without some evidence that things are really going to change. We don't know how many of Opera's core developers will move to WebKit development, but the press release isn't encouraging:  "The shift to WebKit means more of our resources can be dedicated to developing new features and the user-friendly solutions."  I suspect they want some cost savings by eliminating Presto technical staff, or -- in the most optimistic case for their employees -- refocusing existing staff on the parts outside WebKit core that make browsers different. Opera did  land their first WebKit patch  so they wanted to make a statement that they weren't gettin...
13 comments
Read more

Please Stop the jsPerf.com Abuse!

According to many of the tests on jsperf.com , jQuery is slow. Really slow. The jQuery team gets bug reports from web citizens who've discovered these egregious flaws via jsperf and want them fixed. Now, jsperf.com can be a great tool when used knowledgeably, but its results can also be misinterpreted and abused. For example: Why doesn't jQuery use DOM classList for methods like .addClass()? There are at least three good reasons. It doesn't make any practical performance difference given its frequency of use. It complicates code paths, since classList isn't supported everywhere. It makes jQuery bigger, which makes it load slower for everyone, every time. But this jsperf shows classList is much faster! How can you say that? Well it's possible that test is running afoul of microbenchmark issues , and not measuring what it is supposed to measure due to the increased sophistication of today's JavaScript compilers. This is a big problem with a lot of t...
7 comments
Read more

You Might Not Need Babel

Babel is great, and by all means use it if it makes it easier to develop your application. If you're developing a library on the other hand, please take a moment to consider whether you actually need Babel. Maybe you can write a few more lines of utility code and forego the need to pre-process. If you're only targeting some platforms, you may not need anything more than plain old ES6. At the very least, make sure you know what Babel is doing for you, and what it's not. Some developers believe that Babel is protecting us from a great demon of code complexity when, in truth, browsers and node are pretty easy to deal with on their own. Let's take a look at some of the strategies for not needing Babel. ES5 is pretty okay: In the days when we used tables for layout and the debugger was named alert() , we would have been so grateful if JavaScript had the features that ES5 has today. If you truly need Babel you are not only a weak programmer, but also an ingrate. Face ...
3 comments
Read more