A brilliant debate on Yui vs jquery [translation]

 

Translator's note: we often see various comparisons between different JavaScript libraries/frameworks. However, this direct conversation between YUI3 architects and the father of jQuery is very rare, and it is also a sudden burst of excitement, which is really hard to help, the translation is intended to inspire readers and inspire those who are interested in developing "libraries/frameworks.

  The father of jQuery replied, "how can YUI3 improve its influence ?"

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

Question: How can YUI3 improve its influence compared with jQuery and Mootools?
Author: John Resin (father of jQuery)
Translator: peakchi

YUI3 has already exceeded YUI2 and is aligned with jQuery. How can YUI3 improve its influence? Some of the answers to this question seem to be out of the box. The question is "How to Improve YUI's influence" (a good question). However, most of the answers are attacking jQuery.

I will answer this question in two ways: 1. How should YUI be improved so that more people can use it? 2. How can YUI be improved to improve jQuery's competitiveness.

I have to admit that, compared with other JS libraries, YUI is indeed very good, whether it is code-level work, a large number of excellent documents, demos, blog articles, video tutorials, and so on, it is really outstanding. Other JS libraries are not very careful about these aspects, and I think these contents are the most important part of a successful open-source project. However, YUI has not successfully occupied the market, I have been puzzled about this.

Here, for your understanding, I will make a few assumptions: 1. The current YUI3 version is "Excellent enough", 2. the YUI documentation and Forum are also well-developed, it is enough to attract more users to use YUI3.

Based on this, I will make some brief comments:

1. Scattered domain names should be merged into one. As others have pointed out, maintaining too many sites is often counterproductive and thankless.

2. The multi-code library should be merged into a code library. It is good that people are still using YUI2. The APIs of YUI3 are quite different from those of YUI2, in the future, YUI will only succeed on YUI3 (the YUI team stubbornly maintains YUI2 and won't help YUI "more successful)

3. There are too many YUI introduction methods, so we should reduce them to one. People should get started with YUI (). use (assuming these people really want to use YUI in depth ). Only one key point is retained on the homepage: YUI should be introduced in this way. <script src = "http://yuilibrary.com/yui-min.js”> </script> is much clearer.

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

Today, if YUI is directly competing with jQuery, both yui and its subitem operations need to be adjusted. Because the current YUI project operation method is different from YAHOO's working method. YUI project is an unfortunate victim to the poor operability of current management methods.

Originally, we should use SimpleYUI to start our YUI program. Let's take a look at jQuery. Its API is simple and practical. Many people aim at these fascinating features to build most websites. Therefore, when we access yuilibrary.com, we should expect only one method to use YUI, that is, simpleYUI (this name should be changed to a more concise and natural name ).

In fact, the YUI website should not provide zip files. I even don't think that you should download the YUI file in a customized way. The official jQuery website only provides a separate jQuery file, which is used by all users, including mobile users. This is too simple, and the document is very simple. blog articles are also simple. Everyone can easily participate in jQuery discussions without any difficulty.

YUI (). use sandbox and asynchronous Script Loading Method are very handsome. I highly recommend this method. I would rather press all my code segments into a compact "SimpleYUI" and load scripts from YUI CDN as needed.

I especially want to refactor the official Yui website so that people can quickly find the components they want, including those provided by the community. I will re-customize the home page so that visitors can see the simpleyui at a glance, and then select some cool components from the Yui component library under the Home Page, and direct the user to access Yui Gallery (or not called Yui Gallery, Yui gallery sounds more like a plug-in library designed for Yui ).

Therefore, we can see that the Yui project still has many structural problems.

All along, Yui projects have a large full-time and paid development team. This is a unique advantage of Yui, which makes other JavaScript library projects very coveted. I would like to say that this is really true. It is because of this that Yui has benefited a lot as a whole. But it also has some serious consequences. The fate of Yui is in the hands of Yahoo. This is not what we want to see. Because Yui is independent and open-source, Yui should be isolated from Yahoo.

As far as I know, there is no non-Yahoo Yui community. Many non-Yahoo developers have contributed a lot of good code to Yui, but they do not have the permission to submit, which is a serious problem. On the other hand, jquery's success has benefited a lot from the feedback and help of developers, and we have gained a lot of nourishment from the community. Now, let's take a look at our code library and code contribution model.

Migrating code to GitHub is a beautiful first step (because there is no version control, the project will die sooner or later). However, the methods that people contribute code are scattered and scattered, obviously, git is our best choice as an open and flexible open-source version control tool (compared to Yahoo's well-regulated version release ). On yuilibrary.com, it is almost impossible to initiate a pull request-like operation because it has its own code Submission mechanism and is very prone to conflicts. We need git to break into the developer's habits of coding and embrace git so that you can use it with ease.

Today, the biggest problem in the YUI community is that "YUI has been formed", or YAHOO is contributing code to YUI. A truly open-source project should have a complete community ecosystem, only when Yahoo stops supporting YUI can community developers build a YUI development environment with peace of mind and contribute code to YUI. If this problem persists, the bottleneck cannot be eliminated. We should make a quick effort to solve the problem, fix the root cause of the YUI problem from the underlying structure.

We need to establish a non-profit organization with YUI 100% copyright and allow unofficial developers to take charge of project operations, this has an extraordinary significance for the development of YUI and the improvement of its vitality in the community.

If you want to provide the ultimate improvement plan, I think these two points should be:

1. Simplicity is beautiful. It simplifies your code, your site, your documents, and your library files. A more concise code can be read and used by more people.

2. the open-source community is the key to the sustainable development of YUI. It will bring more feedback and enthusiastic developers. The influence of YUI has a subtle influence on everyone in the open-source community, yahoo should not be its only maintainer, but should come from a broader open-source community.

In addition, I have noticed that many of the replies here are pessimistic. Don't forget that jQuery's popularity has just begun, jQuery and YUI are available almost at the same time (they released the official version in January and February respectively). jQuery has maintained its simplicity and ease of use, therefore, the number of developers is far higher than that of other JS frameworks. In fact, simplicity is more challenging than complexity, which has always been a problem that YUI cannot understand, but should be reflected on.

  Zakas response

Original article: http://www.nczonline.net/blog/2010/11/03/response-to-john-resigs-comments-about-yui/

Question: Responding to John Resig's comment on YUI
Author: Nicholas C. Zakas (YUI3 architect)
Translator: peakchi

Just this morning, someone asked Quora [NOTE 1] a question: "How can yui3 improve its influence ?", This question is very interesting, and the reply below is also very interesting. One of my most interesting replies is from John resig, the author of jquery. His interpretation is very unique and provides a roadmap for creating a huge and dynamic open-source community of jquery. I just disagree with many of them.

Before the discussion, it should be noted that I work in Yahoo and I have always contributed code to Yui, although I am not a member of the Yui Development Team, therefore, my opinion does not represent Yahoo and Yui development teams. I just personally reply to John resig to share my views. Furthermore, I respect John himself, the jquery team, and the jquery community developers very much. Therefore, please do not take my point of view out of context and give a special understanding.

First of all, I admit that scattered sites are indeed a problem with Yui. More than one person has ever wondered whether to access ydn or yuilibrary.com? This is the first problem that Yui must solve. Similarly, John's advice on simplifying the boot information on the home page of the Yui document is also quite good, which is a good idea.

John's next section describes how Yui is competing with jquery. I posted a brief comment on Twitter: "I don't think there is a dead-and-dead competition between them ", I don't want to turn Yui into another jquery. Both libraries have their own advantages and have a low degree of coincidence. Jquery is more suitable for small websites. After all, it is very simple and accessible to the public and everyone. Therefore, jquery has a large set of designers, but I don't want to use jquery to build the Yahoo homepage. For scalable Web applications, Yui is indeed better. I don't believe that a single product can satisfy the diversified needs of all users. Jquery is indeed imaginative in its focus, and I would rather focus on solving complex web applications.

My comments on John disagree with the following:

"YUI projects have always had a large full-time, paid development team. This is a unique advantage of YUI, which makes other JavaScript library projects very coveted. I would like to say that this is really true. It is because of this that YUI has benefited a lot as a whole. But it also has some serious consequences. The fate of YUI is in the hands of YAHOO. This is not what we want to see. Because YUI is independent and open-source, YUI should be isolated from YAHOO ."

I have heard of this kind of point of view, which I have never understood and disagree with. Open-source communities seem to have always circulated such a point of view, believing that there is only "Pure autonomy ", rather than relying on a company's project, it is truly "Open Source ". Let me extract my previous chat record:

XX: I like YUI very much, but the annoying "Y" makes me very uncomfortable.
I said: What makes you uncomfortable? Who are full-time engineers holding Yahoo? Or are you not familiar with YUI testing on YAHOO, which has one of the world's most visited websites?

In my opinion, YUI is so valuable thanks to Yahoo. The YUI development team and other yahoo r & D teams fought side by side. This experience has created today's indestructible YUI products. Not long ago, I just joined YUI team engineers to apply YUI3 to the YAHOO homepage. How many JS libraries do you dare to say you have the opportunity to test on top 5 websites around the world? How many JS libraries dare to say that they can continuously obtain test data from the most popular websites in the world. These websites have more than visits each day?

YUI is stripped out of Yahoo to truly deprive it of its strategic advantages. When YUI focuses on these high-end projects and some private projects, it cannot take into account those open-source communities at the same time. In Yahoo, we can work with the YUI team to break the balance, and all YUI users also benefit from this. The hard work of all Yahoo engineers gathered here to inject energy into YUI over time.

Some people say that Yahoo should not "manipulate" the fate of Yui, which I cannot agree. Similarly, Yahoo makes Yui flash. Any open-source project has a core development team. In addition to maintaining the project source code, they are responsible for cultivating developers and providing them with a learning roadmap. Yahoo pays salaries for Yui developers, which cannot change the nature of the project. Let's take a look at Mozilla, which is so successful under similar mechanisms. Mozilla's core R & D team controls the release of Firefox, and Mozilla pays them salaries, it doesn't mean how bad their products should be. Their product Firefox is the second largest browser in the world, and it is these dedicated engineers who are enthusiastic about this product. They are indeed eager to create the best product. This is easy to implement when your job is supporting this project. Who said big companies cannot support open-source projects? The formation of the open-source community ecosystem is ultimately determined by the spirit of communication, collaboration and constant transcendence, rather than the so-called "non-profit ".

Looking back at Yui, The Yui development team has been developing third-party component libraries with great care. This is a good option, which cannot avoid growing troubles. Today, Yui has achieved remarkable results. Of course, Yui has not received much attention as jquery, But Yui has been working hard. At last year's Yui Annual Meeting [NOTE 2], Matt Snider (who once worked for Mint.com) introduced a fairly complete yui2-based component library developed by him. I think this is really great, because his behavior conveys a signal that anyone who has his own ideas can move closer to the Yui development team and get the absolute support of the Yui team, and package your components into Yui. Matt has made a lot of work for his Component Library and hopes that Yui can find more developers like him who are willing to spend time contributing high-quality code to Yui. Similarly, Yui gallery is also a pretty good thing: it opens a door for developers and developers can easily publish their components to the gallery list, they can also be pushed to Yahoo's CDN [NOTE 3]. So far, gallery has 227 components, which has benefited non-Yahoo developers.

So can Yui improve the form of the Community and contribute the code pattern? Of course. Does Yui have to disconnect from Yahoo to start these improvements? No. yui3 is a high-quality product with strong vitality in the ever-expanding open-source community. If you want to blame the Yui team for being incompetent, they ignore the importance of marketing and lack of effective promotion methods. These two aspects are the strengths of jquery, which is also the place where Yui needs to learn from jquery.

In short, Yui is not jquery, and any attempt to convert Yui into jquery is wrong. Does that mean that the two of them are square brackets and cannot be used in water or fire? No. jquery has the largest developer group in the world. No open-source project dares to say that you don't want a developer group like jquery. Yui is also one of them, But Yui does not need to become a global developer like jquery, and it is not necessary to open Yahoo!. jquery is just a case study, it gives us a reference sample of how to operate open-source communities. As I often say to my colleagues, there is not only one solution to the problem, the real challenge lies in choosing appropriate policies rather than copying them to solve problems in specific scenarios. If we really follow jquery's step by step, for Yui, this will be a serious decision-making error. After all, they have different approaches and each has its own advantages, each has a specific developer group. Yui will stick to its own path, although it is inseparable from the purple soil that breeds it. However, I believe Yui can do this.

Note 1: Quora.com is a Q & A-based SNS with active user groups. The biggest difference between quora.com and the previous Q & A websites is that auora is based on the real name system.
Note 2: Yuiconf is short for the Yui Developer Conference, once a year. It will be held in July November 8 this year. You can get more information through yuiblog.
Note 3: I believe zakas's original intention is good, but in my personal experience, it is really easy to publish components to gallery, but it is a bit difficult to push them to Yahoo CDN, procedures are a little troublesome.

 

Source: http://ued.taobao.com/blog/2010/11/06/yui3-vs-jquery/