A great debate about YUI3/jQuery

Translator's note: We often see various comparisons between different JavaScript libraries/frameworks, but this direct conversation between the YUI3 architect and the father of jQuery is very rare, and it is also so exciting that I can't help it. Translated for the benefit of all readers, I hope it will inspire colleagues who are interested in developing "libraries/frameworks".

The father of jQuery answers "How does YUI3 increase its influence?"

Original text: http://www.quora.com/How-could-YUI3-improve-its-image-compared-to-jQuery-MooTools-etc/

Question: Compared with jQuery and Mootools, how does YUI3 improve its influence?

Author: John Resin (father of jQuery)

Translator: Bachi

YUI3 has surpassed YUI2 and is on par with jQuery . So how can YUI3 improve its influence? Regarding this question, some answers seem to be a bit off-topic. The question is "how to improve the influence of YUI" (a good question), but most of the answers are attacking jQuery.

I answer this question from two aspects:

1. How should YUI be improved so that more people can use it?
2. How can YUI improve its competitiveness with jQuery?

I have to admit that compared to other JS libraries, YUI is really great. Whether it is code-level work, a lot of excellent documentation , demos , blog articles , video tutorials , etc., it is really outstanding. Other JS libraries don't pay much attention to these aspects, and I think these contents are the most important components of a successful open source project. However, YUI has not been more successful in occupying the market, which I have always been puzzled by.

Here, in order to facilitate your understanding, I will make a few assumptions:

1. The current YUI3 version is "good enough"
2. YUI documentation and forums are also complete enough to attract more users to use YUI3.

Based on this, I will make some brief comments:

1. Scattered domain names should be consolidated into one, as others have pointed out, maintaining too many sites is often counterproductive and thankless.
2. Multiple code bases should be merged into one code base. Yes, people are still using YUI2, but the API of YUI3 is very different from YUI2, and YUI will only succeed on YUI3 in the future (the YUI team stubbornly maintains YUI2 will not help YUI "more successful")
3. There are so many ways to introduce YUI that it should be narrowed down to one. People should start with YUI().use (assuming they really want to use YUI in depth). Just keep one important point on the homepage: YUI should be introduced like this, <script src="http://yuilibrary.com/yui-min.js"></script>, which makes it much clearer.

Simply put, the YUI project should retain an overall direction. If the focus is too scattered, it will backfire.

Today, if YUI were to compete directly with jQuery, the way YUI and its sub-projects operate would need to change. Because the current way the YUI project operates is contrary to YAHOO 's working methods. Given the extremely poor operability of the current management approach, the YUI project is an unfortunate casualty.

Originally, we should use SimpleYUI to start our YUI program. Take a look at jQuery. Its API is simple and practical, and people build most sites for these charming features. So when we visit yuilibrary.com , we should expect that there is only one way to use YUI, which is simpleYUI (the name should be changed to something more concise and natural).

Source: taobaoued