[jeresig]

I'm not sure Zepto could be defined as "better" considering that it only implements a small subset of the jQuery API. In the browser world you can't get away with implementing a small subset of a specification, it'll be consider broken and people won't use it.

I'm not arguing against multiple implementations. If Mozilla were to switch to WebKit, rewrite its DOM implementation to be 20x faster, and then release that -- that would be absolutely stupendous! Much in the same way that the Chrome team created a new JavaScript engine that was much faster than Safari's JS engine. I am arguing that the writing is on the wall for the common parts of a browser. A browser vendor's time will be used much more efficiently by collaborating with each other on the implementation instead of writing a number of separate implementations.

[pcwalton]

"If Mozilla were to switch to WebKit, rewrite its DOM implementation to be 20x faster, and then release that -- that would be absolutely stupendous!"

Rewriting WebKit's DOM implementation to be 20x faster wouldn't be possible without rewriting WebKit. The DOM implementation is one of the most central parts of any rendering engine. We're working on doing that (Servo), but not by building on top of WebKit for precisely this reason.

"Much in the same way that the Chrome team created a new JavaScript engine that was much faster than Safari's JS engine."

They did that by replacing JavaScriptCore wholesale, rather than building on top of it. This was only possible because JavaScript is a standard, not defined by JavaScriptCore's implementation. If JSC had had a monopoly and the Web started relying on JSC's quirks, then V8 might never have happened.

[goldfeld]

In as much as I consider jQuery a kitchen sink approach, anyone who tries to trim it down to the core (and dropping old browsers which need lots of ifs and elses) may well be better in my opinion.