Un grand débat sur YUI3/jQuery

Note du traducteur : Nous voyons souvent diverses comparaisons entre différentes bibliothèques/frameworks JavaScript, mais cette conversation directe entre l'architecte YUI3 et le père de jQuery est très rare, et elle est aussi tellement excitante que je ne peux pas m'en empêcher. de tous les lecteurs, j'espère que cela inspirera les collègues intéressés par le développement de « bibliothèques/frameworks ».

Le père de jQuery répond "Comment YUI3 augmente-t-il son influence ?"

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

Question : Par rapport à jQuery et Mootools, comment YUI3 améliore-t-il son influence ?

Auteur : John Resin (père de jQuery)

Traducteur : Bachi

YUI3 a dépassé YUI2 et est à égalité avec jQuery . Alors, comment YUI3 peut-il améliorer son influence ? Concernant cette question, certaines réponses semblent un peu hors sujet. La question est "comment améliorer l'influence de YUI" (une bonne question), mais la plupart des réponses attaquent jQuery.

Je réponds à cette question sous deux aspects :

1. Comment YUI devrait-il être amélioré pour que davantage de personnes puissent l’utiliser ?
2. Comment YUI peut-il améliorer sa compétitivité avec jQuery ?

Je dois admettre que par rapport aux autres bibliothèques JS, YUI est vraiment géniale. Qu'il s'agisse de travail au niveau du code, de nombreuses excellentes documentations , de démos , d'articles de blog , de didacticiels vidéo , etc., c'est vraiment exceptionnel. Les autres bibliothèques JS ne prêtent pas beaucoup d'attention à ces aspects, et je pense que ces contenus sont les éléments les plus importants d'un projet open source réussi. Cependant, YUI n'a pas mieux réussi à occuper le marché, ce qui m'a toujours intrigué. .

Ici, afin de faciliter votre compréhension, je ferai quelques hypothèses :

1. La version actuelle de YUI3 est "assez bonne"
2. La documentation et les forums de YUI sont également suffisamment complets pour inciter davantage d'utilisateurs à utiliser YUI3.

Sur cette base, je ferai quelques brefs commentaires :

1. Les noms de domaine dispersés devraient être regroupés en un seul, comme d'autres l'ont souligné, maintenir trop de sites est souvent contre-productif et ingrat.
2. Plusieurs bases de code doivent être fusionnées en une seule base de code. Oui, les gens utilisent toujours YUI2, mais l'API de YUI3 est très différente de YUI2, et YUI ne réussira que sur YUI3 à l'avenir (l'équipe YUI maintient obstinément que YUI2 n'aidera pas. YUI "plus de succès")
3. Il y a tellement de façons d’introduire YUI qu’il faudrait se limiter à une seule. Les gens devraient commencer par YUI().use (en supposant qu'ils souhaitent vraiment utiliser YUI en profondeur). Gardez simplement un point important sur la page d'accueil : YUI doit être présenté comme ceci, <script src="http://yuilibrary.com/yui-min.js"></script>, ce qui le rend beaucoup plus clair.

En termes simples, le projet YUI doit conserver une direction générale. Si l’accent est trop dispersé, il se retournera contre lui.

Aujourd’hui, si YUI devait concurrencer directement jQuery, la façon dont YUI et ses sous-projets fonctionnent devrait changer. Car le fonctionnement actuel du projet YUI est contraire aux méthodes de travail de YAHOO . Compte tenu de l’opérabilité extrêmement médiocre de l’approche de gestion actuelle, le projet YUI est une malheureuse victime.

À l'origine, nous devrions utiliser SimpleYUI pour démarrer notre programme YUI. Jetez un œil à jQuery. Son API est simple et pratique, et les gens créent la plupart des sites pour ces fonctionnalités charmantes. Ainsi, lorsque nous visitons yuilibrary.com , nous devons nous attendre à ce qu'il n'y ait qu'une seule façon d'utiliser YUI, qui est simpleYUI (le nom devrait être changé pour quelque chose de plus concis et naturel).

Source : taobaoued