Two rivals lost to the one with better documentation

jQuery won a technical near-tie. The deciding factor was a website.

The field before 2006

In the middle of the browser wars' long hangover, three libraries were fighting for the same constituency: front-end developers who were tired of writing browser-specific code by hand. Prototype.js, released by Sam Stephenson in 2005 and shipped inside Ruby on Rails, had real momentum — Rails adoption dragged it onto servers whether developers asked for it or not. MooTools arrived shortly after, in 2006, built around a class system that felt closer to classical object-oriented languages and attracted developers who wanted structure. jQuery launched the same year, introduced by John Resig at BarCamp NYC in January 2006, and on raw capability the three were genuinely close. All three smoothed over DOM inconsistencies, all three handled events and Ajax, all three made the case that JavaScript was worth writing.

The technical differences were real but narrow. Prototype extended native objects directly — Array, String, Function all acquired new methods — which felt elegant until it didn't, when a third-party library expected a plain array and got one wearing extra clothes. MooTools did the same and compounded it with a dependency chain that assumed you'd want its entire class infrastructure whether or not you did. jQuery kept its hands off the natives. Everything lived on the $ function; you opted in to nothing you didn't call. That restraint mattered, but it wasn't decisive on its own. Plenty of capable libraries have died with clean architectures.

What the documentation actually was

Prototype's documentation was, for years, incomplete. The project's own site listed method signatures without explaining when you'd reach for them or what they'd do to your code's assumptions. MooTools was better organised but assumed familiarity with class-based patterns that a significant portion of working front-end developers had never been trained in. The mental model required was not explained; it was expected.

jQuery's documentation site explained itself. Every method had a description, a list of arguments with types, and at least one worked example. The jQuery API documentation organised functions by what you were trying to accomplish — selecting, traversing, manipulating, handling events — so a developer who didn't know the library's vocabulary could still navigate to the right place. That sounds ordinary now. In 2006 it was rare enough to be an advantage.

The difference compounded through community. When documentation is clear and explorable, questions get answered faster on forums, blog posts stay accurate, and the tutorials people write for each other build on a shared foundation. jQuery's ecosystem of third-party explanation grew faster than Prototype's or MooTools', not because more people were writing about it by coincidence, but because the primary source made secondary sources easier to write.

By the time Can I Use began turning browser support into something you could cite, jQuery was already the library that new developers encountered first and organisations trusted longest. Prototype's Rails coupling kept it alive in that context well into the 2010s, but its presence outside Rails withered. MooTools' adoption never scaled beyond communities that already thought in class hierarchies. Neither library had made itself easy to start.

The lesson the ecosystem took — unevenly and slowly — was that documentation is not supplementary to a library's design. It is part of the design. A method that a developer cannot find or cannot understand from its description does not exist for that developer. jQuery's approach to explaining itself was not separate from its technical decisions; the same instinct toward approachability ran through both. The $-sign API and the searchable docs page were expressions of the same preference: make the reader's first hour as frictionless as possible, and the second hour will take care of itself.