The 14 days of jQuery

A story of industry transformation and the commodification of innovation.

It has been 13 years since the 14 days of jQuery celebrated the release of jQuery 1.4 in January 2010, arguably the major-version pinnacle of the library that shaped the frontend development world for years to come. In 2005, it was magic; in 2010, it was an industry. And in 2023, it has essentially no role on the modern web that it helped create.

It’s fascinating to me to consider whether jQuery was a necessary step on JavaScript’s trajectory: no one would argue today that people should be building large JS apps with jQuery as their sole core, but people had actual disagreements about this back then. Companies and people were internet-famous for their jQuery plugins. There were t-shirts and whole conferences about using jQuery, and whole web sites about how to not use it at all. Ads for frontend devs were written in pseudo-jQuery. A company that called itself “The jQuery Company” proposed to create a jQuery certification. Once I ran a conference and enticed earlybirds with a copy of the jQuery source, signed by John Resig himself.

It was a time, and I don’t rule out that you had to be there. Thirteen years later, I have some questions:

• Do you end up with React without jQuery? Was that whole Backbone and Marionette thing another necessary step or a distraction? Why did it take so long for a framework to gain broad adoption? Why didn’t MooTools win? Where would the innovative YUI have landed if Yahoo! hadn’t collapsed right about then? Why was Dojo DOA except at enterprises?

• How did the apparent simplicity of jQuery — get some elements and do something with them — impact who found their way into the industry? Do CSS capabilities evolve the way they have without the gateway drug of jQuery drawing design folks to try development?

• Could jQuery have had so much success without Github establishing the ideas of social open-source coding? Did jQuery’s success slow or speed the acceptance of front-end engineering as a real thing?

Of course we can’t answer any of these questions, but I find myself thinking a lot about that time these days, and I’m realizing that the echoes I hear aren’t just in my head. This whole data-driven but human-informed focus on developer productivity is in its own primordial soup stage. The ingredients are there somewhere for transformative outcomes, but evolution still needs to do its thing. We haven’t even agreed on what to measure, or how to define “good.”

Indeed, I’m pretty sure we’re not even at the jQuery analog of the journey yet, though not for lack of lots of companies trying. Anyone who’s paying attention knows that the status quo can’t hold, but no one has quite figured out how to put all the ingredients together, in a repeatable way, to get to a breakthrough outcome.

If past does turn out to be prologue in this case, here are some things I think we can anticipate:

• Standards will emerge and evolve. jQuery effectively eliminated a large set of browser differences, at a time when the browser vendors themselves (which did not, at the time, include Google!) had no interest in doing so. SPACE, DORA, and others attempt to define the shape of this “standards” space, but true interchangeability of these standards across tools and companies seems far off. It’s not really clear who’s motivated to standardize them, but it seems like that’s an eventually important part of progress.

• Tools will change who participates in the conversation, and thus the solution space. One of the most powerful things about jQuery was how it made frontend development accessible to a group that was eager to participate but unsure where to start. Similarly, there are people in organizations with great ability to organize change or make targeted improvements, but they often lack information to help them know where to focus.

• Tools with low barriers to entry (and value) will dominate the conversation even if other tools are “better.” The web was the main channel for promoting jQuery, and it was also the runtime environment for the library. This led to some awe-inspiring demos that you could run right from your browser, without setting up anything at all, without even installing Flash. The path from intuition to outcome was short: get some elements, do something with them. Tools with high demo value and a short, clear, intuitive path to value will advance the conversation independent of whether those tools are “good” or whether their approach is sustainable.

• Early movers will benefit, even if they choose wrong. In the late aughts, any choice you made to use a JavaScript library like jQuery or MooTools was more than likely to be better than what you’d do otherwise. Even if you chose wrong, you probably made some progress on the problem of JavaScript being kind of impossible. It’s arguably easier to undo decisions re devprod metrics and goal-setting than it is to undo code and architecture and library choices, which should only encourage experimentation and exploration.

• There’s a risk of accidental permanence with any solution. jQuery’s tentacles in a codebase got deep very quickly: there were essentially no boundaries between visual and business logic, and it was effectively impossible to detect when two bits of jQuery-based code would execute at cross purposes. Of course we know better now, but of course actually we don’t. Keep a clear line of sight on what functionality is core and what is for the purpose of metrics, keep the two separate, and be skeptical of a solution that requires extensive investment in new code on your end.

• We don’t know what we don’t know. People were building interactive user interfaces long before jQuery, and long before the web, but web development still had to go through its own discoveries and struggles and epiphanies and regrets. People have been thinking about productivity since the introduction of the assembly line, and the devprod space will continue to learn from those who came before, but hopefully only the right things.

---

If you’ve made it this far, I might as well share that the reason I’m thinking about this stuff is that 1) I can’t help it, it’s my brain; and 2) on Monday, I’ll start a new and very different job from any I’ve ever done, at a small, early-stage company that’s focused on developer productivity. Stripe to startup is going to be a journey unto itself, but I’m still giddy that someone wants to actually pay me to do what I’ll be doing. More soon.