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%.

jasmine-jquery now has JSON Fixtures

On my current project, I found the need for some pretty large data structures to test some of our growing Javascript code base. We’re using jasmine and jasmine-jquery. `jasmine-jquery` gives us the ability to easily pull in HTML fixture data on which we can run plugins etc. But there was no way to get JSON fixture data easily into the test framework. Instead of writing huge chunks at the top of the spec file that read

var test_data = [
   blah blah blah

var more_complex_test_data = {
   blah blah

I decided to add that functionality into jasmine-jquery. And my pull request was accepted in no time.

Now with jasmine-jquery, you can add to your jasmine specs (these are in CoffeeScript, but you get the idea) :

describe 'MyNewThing', ->
  beforeEach ->
    fixture1 = getJsonFixture('fixture1.json')
    @testable = new MyNewThing(fixture1)
  it 'does the right thing with data' ->
    expect(@testable).to ...

Thanks to Travis Jeffery for merging in the pull request.

Keep testing!