When will IE8 (and IE7) die?

As time moves on, IE6 can pretty much be taken off the watch list (if you missed the obit, check out http://ie6funeral.com/). And IE7 is very close to that1. But IE8 is still problematic.

And that brings me to the meat of the post. The last chunk of work I did on my site was some fancy search enhancement which involved a bunch of Javascript and Ajax. I wrote lots of tests. Everything felt good. I pushed it out. My cohort (who’s really good at breaking stuff) immediately found issues with Internet Explorer. So I fire up a VM and find out that, in fact, on IE8, something is failing hard and basically making the search unusable. After some digging, it boiled down to String.prototype.trim. Not supported in IE8. Wow. I guess I shouldn’t have been so surprised. I was initially going to overwrite trim only if it hadn’t been defined, with something like

  if(!String.prototype.trim) {
    String.prototype.trim = function() { ... }

But as I did a little reading (still not believing that IE8 didn’t have trim for strings) I found this post http://blog.stevenlevithan.com/archives/faster-trim-javascript. As it turns out, the default trim is kind of slow. Though I generally avoid overriding “native” types prototype methods, in this case, I was pretty confident to move forward.

String.prototype.old_trim = String.prototype.trim
String.prototype.trim = function() { return this.replace(/^\s\s*/, '').replace(/\s\s*$/, ''); };

I preserved the old trim method on the outside chance that I would care. But since it seems to be rolling in production now, I’ll probably rip that out and let it roll.

I realize with the recent(ish) browser proliferation (especially with mobile in the mix), we’ll probably always be doing some customizations for specific platforms/browsers, but for some reason, IE has always felt the most painful. I haven’t yet dealt much with IE9/IE10 issues. Hopefully they’ve gotten a little closer to Firefox and Chrome who, together, seem to be holding the market share2

1 w3schools reports 2% of traffic is IE7. StatCounter also seems to report something at 2% or less. Sadly, on my most trafficked site, we get about 9%.


After the comment from Steven Levithan, I decided I’d better check my math. I setup a perf test on jsperf and noticed I’d put my foot in my mouth. Native out shines the “faster” javascript implementation by at least as good and typically faster by a lot (it depends on the string and what it has to trim). So I take back what I said. The right way here is to define trim only where it’s needed – as I mentioned in the first code snippet.

Thanks, Steven. Learning more stuff every day.

2 StatCounter shows IE and Chrome both around 30% and Firefox at ~25%.


2 thoughts on “When will IE8 (and IE7) die?

  1. IE8 was released 2009-03-19, and String.prototype.trim wasn’t added to JavaScript until ECMAScript 5, which was published 2009-12-03. The gentleman doth protest too much, methinks. Note that my post you linked to that compares various trim implementations is quite a bit older–from June 2007. No browser included a native String.prototype.trim at that time, nor for quite a while after.

  2. You are probably right that I complain too much. Thanks for giving a little more history on the Javascript.trim. I suppose I develop with the modern browsers in mind and I just wished that the older versions would simply die out so I didn’t have to code for the lowest common denominator. And yes, this is just more complaining.

    I appreciate the comment. Cheers.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s