Can jQuery Put Pressure On WebKit to Fix Bugs?

Posted Sunday, February 17th, 2013 at 12:45 pm

If you didn’t already know that Opera Software decided to toss its Presto rendering engine in favor of WebKit, just stop reading this post right now and go catch up on the past week of news in the world of web development and browsers. Don’t worry, I’ll wait.

Assuming you did already know that, you should check out jQuery Foundation President Dave Methvin’s reaction, “The Tragedy of the WebKit Commons“. He says “jQuery Core has more lines of fixes and patches for WebKit than any other browser. In general these are not recent regressions, but long-standing problems that have yet to be addressed.” He goes on to suppose that “Opera probably doesn’t have [much] incentive to fix the common bugs… — especially when jQuery continues to cover up these mistakes. Instead, Opera will want to focus on… features, all while people complain about jQuery’s “bloat”.”

It’s a reasonable worry, given some of the other things Methvin notes about how long some WebKit bugs have been around. Really, go read his entire post, too — it’s only 5 paragraphs long. And it means you don’t really need to read Stephen Shankland’s news article about it on CNET News — though his summation of it as a JavaScript expert saying: “WebKit, get your bug-ridden house in order” is amusing.

The real reason I bring up Shankland’s piece is because of a comment on it by one SteveW928, who points out that “In an odd way, JQuery is enabling the problem” — much as Methvin noticed that “jQuery continues to cover up [WebKit’s] mistakes”.

But the cool part — the real reason why I’m writing this — is the bit where SteveW928 goes on to say:

While, as a user I’d hate to see it happen, the best way to get this fixed would be [for] JQuery to pull the work-arounds and then, somehow, properly point the finger at the WebKit folks. (emphasis added)

I had to add that emphasis, and particularly on the word “somehow”, because I understand why that isn’t at all easy. (It’s the same reason Microsoft has so much special-case code in IE for Quirks mode rendering.) If jQuery simply declines to paper over a bug in WebKit, users won’t think “WebKit is screwed up; it doesn’t do Thing X right”. Instead, it’ll be: “jQuery’s broken; it doesn’t work right in WebKit browsers”.

But here’s a suggestion for what jQuery could do: Make two versions available — one with WebKit fixes and one without ’em. And let people see what the size difference is between them both.

Obviously, no one in their right mind will actually deploy a version of jQuery that doesn’t work with WebKit browsers. But that doesn’t have to be the point. Maybe by showing how much of its code is devoted to working around WebKit’s bugs, jQuery can effectively “name and shame” them — and bring focus to the need to improve the codebase.

In fact, they could do one for each major browser… let us all know just how wonky each rendering engine actually is. Comparing file sizes on the download page would be far easier than downloading each un-minified version and grepping for comments.

Post a Comment

Your email is never shared. Required fields are marked *

*
*