javascript - examples - mootools vs jquery

¿Debo convertir de MooTools a jQuery?

Question

Tengo una base de código bastante grande que depende de MooTools v1.11 y estoy a punto de convertirla a la versión 1.2. Como esta es una revisión bastante importante, he jugado con la idea de convertir a jQuery.

¿Alguien tiene consejos sobre si actualizar a jQuery o simplemente quedarse con MooTools?

Uso principalmente MooTools para Ajax, arrastrar y soltar, y algunos efectos menores.

Answer 1

Depende de qué tan bien conozca jQuery y cuál es su fecha límite. Si lo conoces bien, requiere menos líneas de código, lo que significa menos ancho de banda para tus clientes.

Además, si observa este sitio , puede ver que en el navegador IE líder, jQuery tiene un mejor rendimiento que Mootools.

Dicho eso, si todo está funcionando en Mootools v1.11, ¿por qué estás actualizando los scripts? Como dice el cartel anterior, si no está roto ...

Si no funciona correctamente en Mootools v1.11, ¿cómo sabe que funcionará en Mootools v1.2 o incluso jQuery para ese caso? Sería una pena dedicar un montón de tiempo de desarrollo y tener algunos de los mismos errores, o introducir nuevos errores debido al marco que utiliza.

Answer 2

La única razón convincente que podría dar para tal migración sería si hacer el cambio reduciría la cantidad de código que tiene que mantener y / o simplificará las cosas. Generalmente hay mucho trabajo involucrado en un cambio de este tipo, por lo que le gustaría poder regresar después de que todo el trabajo esté hecho y decir "Sí, valió la pena".

Answer 3

Si no está roto. No lo arregles

jQuery puede tener X o Y, pero si todo depende de MooTools, es posible que tengas mucho trabajo por delante para convertir desde MooTools.

Mantenga MooTools si lo utilizó extensamente en su sitio. Sin embargo, si solo tiene 2-3 páginas con efectos menores ... el cambio podría valer la pena.

Answer 4

¿Por qué hacer el cambio? He convertido bases de código de 1.11 a 1.2, y es bastante rápido y fácil (y lo estoy usando para más que unos pocos efectos).

jQuery puede ser adoptado por MS, de acuerdo con un sitio se desempeña mejor en IE, pero no se trata de qué tan bien lo hace con IE, se trata de qué tan bien funciona para su sitio (¿IE es un jugador importante en su sitio?).

¿Conoces a jQuery? Si no lo hace, debe volver a escribir el código desde cero y estará reescribiendo su código por completo.

¿O solo está tratando de encontrar razones para decirle a su gerente que "deberíamos hacer esto en jQuery" porque quiere aprenderlo?

En cuanto a "el único marco verdadero", es una afirmación ridícula que solo hacen los usuarios, no los desarrolladores.

Answer 5

JQuery es una base de código más pequeña con un soporte más amplio. Si cumple con sus necesidades, podría ser un buen cambio. Diría que la compensación que debe decidir es si vale la pena el esfuerzo de migración y la curva de aprendizaje en comparación con el conjunto de características más amplio, el tamaño de código más pequeño y la popularidad y el soporte para JQuery.

Si el cambio entre versiones de MooTools es realmente tan pronunciado, entonces la migración bien podría estar justificada.

Answer 6

Si está actualizando de todos modos , puede valer la pena investigarlo.

jQuery parece estar en camino de convertirse en la biblioteca de One True JavaScript (dado que MS y otros han decidido abrazarlo), así que si este es el código que intentas trabajar por un tiempo, entonces probablemente sea una buena idea cambiar en algún momento (aunque solo sea porque habrá más lugares para obtener ayuda y un código de complemento, ya que es muy probable que continúe siendo popular por un tiempo, lo que ayudará a garantizar la flexibilidad y el mantenimiento a largo plazo de su código). Entonces, dado que tienes que convertirlo de todos modos, ahora podría ser el mejor momento para hacerlo.

Creo que jQuery convertirse en el marco para usar es algo bueno. No habría sido mi elección (me gusta MooTools también), pero ciertamente es un código excelente y definitivamente se ajusta al objetivo con al menos la competencia de su competencia. Me complace ver cualquier tipo de coherencia, y moveré mi código a jQuery en algún momento.

Answer 7

Asses si tienes el programador horas para hacer over the haul.
Hacerlo significará que va a reescribir el código desde cero. Esto nuevamente implica que tendrá que pasar por el ciclo de funcionalidad, revisión y prueba, corregir errores, etc. Dicho esto, uno de los programadores de problemas más importantes que no son tan competentes con JavaScript es que la mayoría de los códigos de acceso a los elementos DOM tienden a crear pérdidas de memoria (que es el caso de la carretera para la mayoría de los desarrolladores web). jQuery por naturaleza hace mucho para mitigar esto. O más bien jQuery le quita el JavaScript de JavaScript.
2do. Una de las razones más convincentes para pasar a jquery es que el peso de su código JavaScript disminuirá drásticamente. Esto tiene sentido para una página intensiva de código del lado del cliente. La naturaleza concisa de jquery le permitirá revisar fácilmente el código también.
La compañía con la que trabajo (support.com) tenía toneladas de código Mootools. Durante el comienzo de 2008 (después de horas de debate intensas -por las cuales estaba en contra de cambiar a jQuery) comenzamos a migrar a jQuery de forma gradual. No me he arrepentido hasta la fecha.

Answer 8

El cambio de MooTools 1.1.1 a 1.2.1 no es tan importante. http://github.com/mootools/mootools-core/wikis/conversion-from-1-11-to-1-2

Incluso hay una capa de compatibilidad que hace que el código de MooTools 1.1.1 funcione en 1.2.x. Puede que tenga que arreglar manualmente algunas cosas aquí y allá, pero es relativamente menor.

Cambiar a jQuery, o YUI o DOJO, o cualquier otra cosa requeriría descartar por completo todo el código que tiene y volver a marcar. Ningún cliente mío permitiría ese tipo de desperdicio.

Además, si está acostumbrado a la codificación con las clases de MooTools adecuadas, entonces jQuery puede ser una gran sorpresa para su sistema. No es que jQuery te obligue a escribir código ilegible e inmanejable; sin duda es posible codificar código legible y fácil de mantener en cualquier idioma. Pero jQuery no tiene un sistema de clase incorporado para ayudarte.

Especialmente con una gran base de código, es importante mantener su código bien organizado.

Soy bastante parcial, por supuesto.

Answer 9

Debe tomar esta decisión según el propósito de su aplicación.

jQuery es asombrosamente genial para animaciones, sin embargo, creo que Mootools es más sofisticado, así que si lo importante es la aplicación y no las animaciones se adhieren a Mootools

La velocidad también es un tema en esto. A partir de hoy Mootools tiene un rendimiento un poco más lento, pero prefiero no prestarle atención hasta que se libere Mootools 1.3.

Comprobación del rendimiento de los últimos marcos en http://slicktest.perrohunter.com

Answer 10

En este punto, Slickspeed se está volviendo totalmente sin importancia, los selectores son demasiado rápidos de todos modos. También para que lo sepan, Sly, de Herald Kirschner, miembro del equipo de desarrollo de Mootools acaba de lanzar Sly, un motor de selección que supera a Sizzle. El hecho de que las animaciones sean el factor determinante para NO elegir las mootools que dejó uno de los carteles fue básicamente un retroceso, Mootools ha sido el rey de las animaciones desde hace años. Lo que sea que elijas, todo funcionará. Mootools tiene una sensación más clásica que creo que me mantiene organizado, jQuery está más basado en funciones y no se aventura tanto en las clases. Uno aumenta los tipos nativos y el otro no, una estrategia diferente, pero eso es todo.

• Daniel

Answer 11

Hay un sitio al respecto que describe las diferencias en la filosofía jqueryvsmootools.com

Creo que eso es a lo que se reduce al final. Un enfoque centrado en DOM funcional o un enfoque de JavaScript orientado a objetos.

Answer 12

Estoy bastante contento con Mootools. He tenido la tentación de probar jQuery varias veces porque cada vez más personas lo usan en estos días, pero de alguna manera todavía no obtengo la característica de OO como Mootools. Otra cosa que realmente no me gusta de jQuery es obtener una identificación con la función dólar al agregar el hashkey (#). Esto puede ser problemático si desea crear identificadores html utilizando el marco. Si yo fuera tú, simplemente actualiza a la última versión de Mootools. Mootools no es una mala biblioteca en absoluto.

Answer 13

Este argumento es aburrido, Mootools es OO para que las personas que forman un fondo OO apropiado aprecien su inteligencia más que las personas de un fondo PHP4 o HTML.

Answer 14

En tu pregunta mencionaste que estás usando MooTools para "Ajax, arrastra y suelta, y algunos efectos menores". Si bien Mootools puede hacerlo bien (y es posible que me critiquen por decir esto), en mi opinión, en realidad no está usando Mootools por el buen motivo. Usamos Mootools en nuestras aplicaciones, y realmente no podemos pensar en sustituirlo por JQuery. Si el objetivo es escribir código mantenible a largo plazo orientado a objetos que otras aplicaciones en su organización puedan aprovechar, Mootools gana sin problemas.

Y solo la velocidad del selector es un criterio equivocado para juzgar (aunque creo que Mootools está ahí ahora). La mayoría de los lugares en nuestro código ya tenemos referencias a los elementos que queremos cambiar. Dedicamos la mayor parte del tiempo a manipular el DOM una vez que tenemos el elemento, y en nuestras pruebas internas (intentaremos publicarlas) Mootools es mucho más rápido que JQuery en el tipo habitual de operaciones que realizamos. Nuestras aplicaciones son del tipo en que confiamos en los controles Mootools creados previamente (creados por nosotros o por otros) para crear pantallas de aplicaciones utilizando datos provenientes de los servicios web.

Answer 15

Como otros han señalado, jQuery es una biblioteca (para jugar con DOM en su mayoría), Mootools (1.2) es un framework javascript completo que le permite organizar su código de una manera orientada a objetos y así mantenerlo fácil de mantener.

Te recomiendo que leas esto para saber realmente qué es realmente cada uno (jqueryvsmootools.com)

Y este otro enlace, para que sepa cómo obtener lo mejor de ambos mundos;):

http://ryanflorence.com/object-oriented-jquery-with-mootools-pigs-take-flight/

Al final todo se reduce a lo que necesitas. Mi recomendación general: si necesitas tomar algunos fragmentos rápidos y fancificar tu aplicación web, jQuery solo es bueno; si vas a centrar tu desarrollo en javascript, deberías probar mootools: el código se escalará y será mejor que estés listo.

Para actualizar su código de Mootools 1.1, puede usar el asistente de actualización, que lo ayudará a identificar el código en conflicto a través de la consola de javascript (mootools.net/blog/2009/12/31/mootools-1-1-upgrade-layer- beta/)

[Perdón por publicar solo 1 enlace activo, esta es mi primera respuesta]

Answer 16

El artículo al que se hace referencia en el sitio web de jqueryvsmootools lo describe bastante bien:

Si jQuery hace del DOM tu patio de recreo, MooTools pretende hacer de JavaScript tu área de juegos

Por lo tanto, junto con la respuesta aquí "Si no está roto, no lo arregles", diría que se dirigen a tus necesidades y no a la opinión pública.

Dado que su sitio ya está en Mootools, debe evaluar si jQuery ofrece todo lo que necesita y que MooTools no ofrece; y si la molestia de la conversión es menor que la molestia de escribir la extensión.

Parece que jQuery tiene la capacidad de permitirle jugar rápidamente con el DOM, pero todas las cosas extra de lujo y otras áreas de trabajo (como fechas) requieren un complemento.

¡Esto también me ayudó a responder mi propia pregunta!

Hay algunas áreas donde no se superponen, lo cual es una pena. Las GUI son fáciles de juntar en jQuery, con hermosos widgets y animaciones. Me parece que las MooTools tienen conjuntos con muy pocas funciones o son demasiado pesadas para el uso general de la web.