Being a maintainer for jQuery is like being part of history. I didn’t create the project, but I certainly helped get it to where it is now. Some stats suggest that jQuery is used by 73 percent of the 10 million most popular websites. It’s still growing, and it feels good to contribute to and help steer a project that’s so popular. Just knowing that I maintain something that influences the whole ecosystem and affects developer discussions for web standards is rewarding.
I don’t come up with big ideas to create a project from scratch. Instead, I like to dive into the existing stuff and fix and modify things so that it works with newer features. I like it when I find a simple fix that improves performance of jQuery greatly, as I know this will save many CPU cycles all around the world. Diving into jQuery edge cases helps me learn more about web browsers as well. jQuery is a Document Object Model (DOM) library so many surprising behaviors are caused by what the browsers are doing; researching that helps me in projects that don’t use jQuery. It will sound funny but I also love removing code! I like to find workarounds that are no longer needed and remove them, simplifying the library.
jQuery is not necessarily a “hot” library, and if you think about the modern project, more popular frameworks like Facebook’s React, Google’s Angular, and Evan You’s Vue.js might come to mind first. It’s partially because a lot of people focus on single-page applications and complex projects, but the web is much larger than that.
Trading academia for front-end programming
Software was always around when I was growing up because my dad was a programmer. I made some attempts at programming in Haskell during grade school, and participated in both mathematical and computer science Olympics in Poland. At Warsaw University, I focused on theoretical topics and planned to pursue something between mathematics and theoretical computer science, like automata theory and the study of abstract machines.
But the academia style of work wasn’t really a fit for me. In 2011, I wanted to find a job—and though I wasn’t particularly focused on finding front- or back-end work, a friend from high school had a front-end position open. I had some background from my studies, but no real practical programming experience, so I mostly learned on the job.
We were using jQuery in a project at work, and at that time, they released a jQuery 2.0 beta: This was a version dropping compatibility with IE 6-8, making the library much lighter. Since my work project only supported IE 9+, I was excited to try it out to gain all these size and performance improvements.. A lot of things broke, so I submitted an issue and it was partially fixed. When I loaded the new version, it was still broken and something clicked: I felt like I could fix it myself and knew exactly how. I prepared the pull request (PR), and it was merged. It was quite fun.
I discovered more issues and submitted more PRs. I’m the kind of person who really wants to thoroughly understand the issue at hand, and not just accept that something works as is.
When I started seeing these bugs in jQuery, I just had to look at the code and discover how to fix the issue. It was fascinating to see how such a popular library worked internally. It came down to my curiosity of wanting to understand everything underneath the hood.
After about a month, Dave Methvin, who was the jQuery lead back then, invited me to officially join the team and attend the 2013 jQuery Conference in Portland. I was really excited. I had never thought that I could be on a team of such an influential project. I appreciate the community’s hospitality, which started with Dave.
Finding the root of issues and modernizing infrastructure
When I joined the project, it was still under the jQuery Foundation, which eventually morphed into the JS Foundation. Recently, we merged with the Node.js Foundation to form the OpenJS Foundation.
The core team who participate in regular jQuery team meetings, discuss important issues, and make decisions are Timmy Willison (the lead), Dave Methvin (the previous lead now in charge of the jQuery Migrate project), Richard Gibson, and me.
My biggest focus is generally on jQuery itself. I recently spent a considerable amount of time updating jQuery UI to work with recent jQuery, and I’m almost finished. One of my motivations for doing the UI updates is I can see first hand how painful some jQuery or jQuery Migrate updates are. Thanks to that work, I was able to make some modifications to Migrate that will make existing projects much easier to update to recent jQuery.
Recently, we used the GitHub UI to submit advisories for security issues in certain jQuery versions. There’s a lot of focus on cross-browser compatibility and fixing deep cross-browser issues, which suits my approach to coding. We don’t just detect the browser and apply a fix: We detect whether the current browser has the bug by testing it (we call these “support tests”), then apply a workaround as needed. That means if a browser fixes the bug, the internal support test starts passing and the workaround stops being applied. I like writing tests and thinking about how to optimize the fix/workaround so that it doesn’t cause performance issues for other browsers.
One of GitHub’s main advantages is that everyone is on it. We really saw that when we moved our bug tracker to GitHub. For many people, creating an account on the jQuery-specific bug tracker and submitting an issue after learning how its UI works is a significant barrier. But almost every programmer is on GitHub, so they already know that UI, which I think decreases the barrier to entry. The old bug tracker and the contribution process were a bit mysterious in the past. It didn’t have a central place like GitHub.
In the core project itself, there’s a big goal to modernize our infrastructure. It was created many years ago and we didn’t have enough people to continue work on it, so it got rusty. It’s a lot of work to maintain and easier to outsource. Obviously, that brings the risk of a particular service dying, and then you have to spend time migrating to something else. But in many cases, it still requires less work. Today, there are likely a lot of in-between options. But it’s worth remembering that even if you have a lot of people involved in the project, over time, the interest may wane, and you’ll be left with all this infrastructure and no one to maintain it.
We’re thinking about outsourcing more of ours, but it’s not easy because it’s so customized. Infrastructure is not easy to maintain as it's hard to find volunteers and it's scary to give new people access to such important systems because it’s such a vulnerable place. If you have access to the jQuery CDN, you could break a lot of files and inject malicious code, for example. That’s why we’re also talking to the OpenJS Foundation—which is providing us with the investments we need to modernize the infrastructure. A group of us from various jQuery projects meets bi-weekly to discuss how to approach the problem. There’s more accountability and less risk.
Making the case for programming during your day job
Balance can be tricky sometimes. I’m fortunate that my employer gives me four hours each week to work on open source. My previous company also gave me a few hours. I was offered to spend some company time each week on open source by my employer back then, and I negotiated that to be included in my future positions, too, including my current Sumo Logic one. I know it’s not for everyone, though, and sometimes you need to be in a certain position to request this. I would also mention that OSS work taught me a lot and made me a better programmer. So if an employer is able to sacrifice a few hours to allow their employees to contribute to open source, they’ll learn a lot and that knowledge will flow back to company projects. Win-win.
There are many aspects to a project like jQuery: Some require deeper thinking and some are more relaxed. For stuff that requires more time, those four hours really help. And sometimes I also work in the evening. In the past when I was heavily involved in AngularJS, it had a high volume of GitHub notification to get through that it was not feasible for any individual to watch the repository and read all the issues and PRs. But jQuery has much lower traffic, so it’s more manageable.
When you’re working on a big open source library like jQuery, you really need to be careful and considerate. You need to recognize that any changes you make may affect many use cases, and even if a hack would work for your particular project, it might not hit the edge cases. So you need to take all of that into account. The focus on ensuring high-quality code and documentation for such a high-visibility project makes me a better programmer.
I think that there are a lot of advantages and opportunities for personal development when you work on open source. It gives you a different perspective on programming. And in many cases, it helps the employer because they’ll have a better employee.
Connected to jQuery through an engaged community
Because jQuery is so popular, there are a lot of funny incidents that come about. People will be experimenting with GitHub and submitting test PRs and not actually realize they just sent a notification to 3,000 people. Some submit an issue for one bug and that’s it. Some fill in the important details for us to fix. We often have to ask follow-up questions to get more details. Sometimes, we have no choice but to close the issue and direct the person to first try to debug their issue at other venues like Stack Overflow.
In most cases, former jQuery team members are still doing very impactful work, like Paul Irish on the Chrome team. Some of our past team members are not so active anymore, like Julian Aubourg, who previously implemented and maintained the Ajax section. When we modify things related to Ajax, he often comments on GitHub.
People like to stay involved and in the loop. Even when I was in a time crunch for my Master’s Thesis, I kept contributing to jQuery. It’s nice to keep that connection, and engage with a community that built such an impactful project together.