Skip to main content

Running out of Lipstick

Over the past several months, I've spent some time fixing lots of jQuery event bugs related to Internet Explorer 6, 7, and 8 in preparation for the upcoming jQuery 1.7 release. Most of these were jQuery bugs in the sense that we didn't put enough extra lipstick on the pig to make it seem as attractive and standards-compatible as modern browsers. One phenomenon that interested me about these bugs was that they had all been reported in the past 18 months, but had been in jQuery for several years. So if that is the case, why were they just being reported now? I have a theory.

If you were a web developer five years ago, you had to really know the quirks and inconsistencies of the major browsers of the day, primarily Internet Explorer 6/7, Firefox 2/3, and Safari 2/3. Libraries like jQuery were created to help developers deal with those problems, but nearly all developers were well aware of the issues that were being normalized within the library. That usually meant their own battle scars prevented them from going into territories where they'd been burned before, so jQuery's valiant-yet-imperfect attempts to fix IE were good enough in most cases.

Today we're seeing a whole new generation of web developers. They write standard HTML, jQuery, and JavaScript with an expectation that all browsers obey the standards. They're developing complex pages and even full-blown applications using Chrome Developer Tools and Firefox with Firebug, often on their Macbooks. Late in the process they spin up a VM with Windows to test in IE6/7/8 and find that something breaks due to subtle differences in the way those older versions of IE disregard the standards. So they file a bug with jQuery, and we add more lipstick.

As the older IEs become less mainstream yet still important, it's probable that IE-related jQuery bugs will continue to come in as developers discover more ways that their standards-based hopes are dashed. If it's feasible we'll fix them, but that doesn't excuse any web developer from having a basic understanding of the quirks and pitfalls of IE. There will always be things that jQuery can't fix--eventually we're going to run out of lipstick.

The good news is that the rewritten IE event support in jQuery 1.7 closed many bugs and actually reduced the size of that code by nearly half, so the world is paying a much lower price for it. Only time will tell if that code meets the expectations of developers who expect strict standards compliance, even from browsers released in 2001.

Comments

Spot on, Dave. Love the analogy. Even though we can't dismiss these browsers for still many years in the future, it's refreshing to note the comparison of the workflow you just described to the norm of 5+ years in the past, where it seemed like 50% of a developer's time was spent supporting IE6 vs. the rest of their time with other browsers. Because they had to pass through the thorny fiery way before they had those scars, and that took time.

As long as these older versions of IE are in common use that number will be non-zero, but we've come to a point where we compound the investment by pouring it into a shared co-op effort. If it weren't for that, we'd be dealing with all the surface issues repeatedly (as many did for many years), but now we're able to dig deeper and deeper to fill those tiny cracks.

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 getting out o…

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 the jsperf tests out …

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 it, you …