Skip to main content

Haters Gonna Hate

@jeresig on Twitter: Whenever I come across people who really hate me and my work it takes every ounce of energy to try and ignore them and move on. So hard.
I was saddened to come across this tweet by John Resig a few days ago. I know at least one of the people who has made--and continues to make--the attacks he speaks about. This person seems to have held deep hatred for John and jQuery for years. It's really unfortunate, because the attacker seems to be a smart and technically astute person. But he's also a bully.

This bully's attacks tend to focus on two things: the quality of jQuery's code, and the quality of jQuery users. On the first point, it's telling that early in the project's life this bully created some tests that showed problems with jQuery. John asked whether we could use that code in jQuery's unit tests, and the answer was NO WAY. He leaves his own vitriolic form of jQuery "code reviews" around the Internet, but never makes constructive comments that might actually help jQuery improve. Helping people get productive things done does not seem to be his goal at all.

Anyone can find problems with jQuery and things that could be improved. The jQuery team has lists of issues in our GitHub repositories if you are short of them. Since the jQuery Foundation is powered primarily by volunteers, we'd love to have more people who are willing to help fix things and improve the documentation, for example. That would be a productive and constructive way to make jQuery better for everyone.

When the bully turns to jQuery's users, it's all about what horrible programmers they are and how bad their code is. He'd probably be happier if jQuery was an obtuse library that was unusable without a four-year degree in programming. Instead, jQuery is easy enough to use that many non-programmers can get something going after a short time. That's a bad thing? Everyone has to start somewhere. Don't blame jQuery if some people decide that their amateur efforts are good enough--and perhaps they are. If not, they can learn and get better over time.

From the very start, jQuery's design and philosophy was pragmatic. It made hard things easy. It fixed browser bugs. It provided a plugin architecture for people to share their code. It coexisted with the libraries that already existed, so people could try jQuery without having to abandon what they'd already done. It continues to do all of those things that John Resig envisioned eight years ago, and more. The bullies who attack John and jQuery are just harvesting a bumper crop of sour grapes.

So John, let me tell you this: There's no reason to let anyone make you feel like your work on jQuery was bad. Take a look at the Internet today. jQuery is everywhere, people choose it of their own free will as the best thing out there. The lessons jQuery taught are helping to drive the next generation of web standards, and it's a foundation component for many higher-level frameworks. Many of the people who you recruited to join that little jQuery mailing list in 2006, me included, are still working to ensure that jQuery keeps serving developer needs for years to come. You did good.


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

Please Stop the Abuse!

According to many of the tests on , 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, 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

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