My guess is that jQuery targeted and solved a problem that was bigger for a broader base of people doing JavaScript development: the DOM API (and some other browser APIs) was both pretty awkward and inconsistent.

Prototype.js seemed to be targeting the problem of providing a familiar class system, standardizing some functional features, and some utility functions. It was something else, and I loved experimenting with it and reading the source, but ultimately, I think fewer people were finding this to be their pain point with the language or that using it made them significantly more productive.

Of course, considering the fact that they seem to solve different problems, it may be an interesting question why they were fighting for mindshare in the same space.

I never looked that close, but I thought that prototype extended the base objects with the prototype property? If this is the case, then it wasn't a great idea. Meta programming is acceptable when you control the compiler or spec of the language, but as ECMA specifications move forward, and those functions are added, you'll get conflicts. And you can't control what browser is interpreting your javascript.

Maybe I just didn't understand it well enough.

Because Prototype does what the name says, i.e. pollutes the prototype chain. Also, Prototype tries to monkey 'classical inheritance', whereas jQuery encourages chaining, which obviously people like more.

I think it was because of the lack of documentation. Back then prototype had none and jQuery had a lot. They had a rich site and prototype had a single spartan page.

I was referring to the underlying code in jquery.js and all the hacks required to make it work in most browsers.

You do have a good point though