Un gran debate sobre YUI3/jQuery

Nota del traductor: a menudo vemos varias comparaciones entre diferentes bibliotecas/marcos de JavaScript, pero esta conversación directa entre el arquitecto YUI3 y el padre de jQuery es muy rara y también es tan emocionante que no puedo evitarlo. De todos los lectores, espero que inspire a los colegas interesados ​​en desarrollar "bibliotecas/marcos".

El padre de jQuery responde "¿Cómo aumenta YUI3 su influencia?"

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

Pregunta: En comparación con jQuery y Mootools, ¿cómo mejora YUI3 su influencia?

Autor: John Resin (padre de jQuery)

Traductor: Bachi

YUI3 ha superado a YUI2 y está a la par de jQuery . Entonces, ¿cómo puede YUI3 mejorar su influencia? Con respecto a esta pregunta, algunas respuestas parecen estar un poco fuera de tema. La pregunta es "cómo mejorar la influencia de YUI" (una buena pregunta), pero la mayoría de las respuestas atacan a jQuery.

Respondo a esta pregunta desde dos aspectos:

1. ¿Cómo se debería mejorar YUI para que más personas puedan utilizarlo?
2. ¿Cómo puede YUI mejorar su competitividad con jQuery?

Debo admitir que, en comparación con otras bibliotecas JS, YUI es realmente excelente, ya sea que se trate de trabajo a nivel de código, mucha documentación excelente, demostraciones , artículos de blog , tutoriales en video , etc., es realmente sobresaliente. Otras bibliotecas JS no prestan mucha atención a estos aspectos, y creo que estos contenidos son los componentes más importantes de un proyecto de código abierto exitoso. Sin embargo, YUI no ha tenido más éxito en ocupar el mercado, lo que siempre me ha desconcertado. .

Aquí, para facilitar su comprensión, haré algunas suposiciones:

1. La versión actual de YUI3 es "suficientemente buena"
2. La documentación y los foros de YUI también son lo suficientemente completos como para atraer a más usuarios a usar YUI3.

En base a esto haré algunos breves comentarios:

1. Los nombres de dominio dispersos deben consolidarse en uno solo; como otros han señalado, mantener demasiados sitios suele ser contraproducente e ingrato.
2. Se deben fusionar varias bases de código en una base de código. Sí, la gente todavía usa YUI2, pero la API de YUI3 es muy diferente de YUI2, y YUI solo tendrá éxito en YUI3 en el futuro (el equipo de YUI sostiene obstinadamente que YUI2 no ayudará). YUI "más exitoso")
3. Hay tantas formas de introducir YUI que conviene limitarlas a una. Las personas deberían comenzar con YUI().use (suponiendo que realmente quieran usar YUI en profundidad). Solo mantenga un punto importante en la página de inicio: YUI debería presentarse así, <script src="http://yuilibrary.com/yui-min.js"></script>, lo que lo hace mucho más claro.

En pocas palabras, el proyecto YUI debe mantener una dirección general. Si el enfoque está demasiado disperso, será contraproducente.

Hoy en día, si YUI compitiera directamente con jQuery, la forma en que operan YUI y sus subproyectos tendría que cambiar. Porque la forma actual en que opera el proyecto YUI es contraria a los métodos de trabajo de YAHOO . Dada la extremadamente pobre operatividad del enfoque de gestión actual, el proyecto YUI es una desgracia lamentable.

Originalmente, deberíamos usar SimpleYUI para iniciar nuestro programa YUI. Eche un vistazo a jQuery. Su API es simple y práctica, y la gente crea la mayoría de los sitios con estas encantadoras funciones. Entonces, cuando visitamos yuilibrary.com , debemos esperar que solo haya una forma de usar YUI, que es simpleYUI (el nombre debería cambiarse a algo más conciso y natural).

Fuente: taobaoued