Pregunta

Tengo un código base bastante grande que depende de MooTools v1.11 y estoy a punto de convertirlo a la versión 1.2. Dado que 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 seguir con MooTools?

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

¿Fue útil?

Solución

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

jQuery parece estar en camino de convertirse en la biblioteca One True Javascript (dado que MS y otros han decidido adoptarla), por lo que si este es un código en el que piensa trabajar por un tiempo, entonces probablemente sea un buen idea de cambiar en algún momento (aunque solo sea porque habrá más lugares para obtener ayuda y 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 la capacidad de mantenimiento a largo plazo de su código) . Entonces, dado que tiene que convertirlo de todos modos, ahora podría ser el mejor momento para hacerlo.

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

Otros consejos

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 de MooTools.

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

¿Por qué hacer el cambio? He convertido las 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 que funciona mejor en IE, pero no se trata de lo bien que lo hace con IE, se trata de lo bien que funciona para su sitio (es IE un jugador importante en su sitio ?).

¿Conoces jQuery? Si no lo haces, entonces tienes que volver a escribir el código desde cero y estarás reescribiendo tu código por completo.

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

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

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 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 desechar por completo todo el código que tiene y establecerlo. Ningún cliente mío permitiría ese tipo de desperdicio.

Además, si está acostumbrado a codificar utilizando 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 imposible de mantener, ciertamente es posible codificar código muy legible y mantenible en cualquier idioma. Pero jQuery no tiene un sistema de clase incorporado para ayudarte.

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

Estoy bastante sesgado, por supuesto.

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

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

Como han señalado otros, jQuery es una biblioteca (para jugar con DOM principalmente), Mootools (1.2) es un marco javascript completo que le permite organizar su código de forma orientada a objetos y, por lo tanto, mantenerlo fácil de mantener. .

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

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

http://ryanflorence.com/object- orientado-jquery-con-mootools-pigs-take-flight /

Al final, se reduce a lo que usted necesita. Mi recomendación general: si necesita capturar algunos fragmentos rápidos y fantasear con su aplicación web, jQuery solo es bueno; si va a centrar su desarrollo en javascript, debería probar los mootools: el código escalará y será mejor que esté listo.

Para actualizar su código de Mootools 1.1 puede usar el asistente de actualización, le 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]

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

También si mira este sitio puede ver que en el navegador IE líder, jQuery tiene un mejor rendimiento que Mootools.

Dicho esto, si todo funciona 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? Sería una pena invertir mucho tiempo en el desarrollo y tener algunos de los mismos errores o introducir nuevos errores debido al marco que utiliza.

En este punto, Slickspeed ya no es tan importante, los selectores son demasiado rápidos de todos modos. También para que lo sepan, Sly de Herald Kirschner, un miembro del equipo de desarrollo de Mootools, acaba de lanzar Sly, un motor selector que supera a Sizzle. El hecho de que las animaciones sean el factor determinante para NO elegir los mootools que dejó uno de los carteles fue básicamente un revés, Mootools ha sido el rey de las animaciones desde hace años. Lo 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 mucho en las clases. Un uno aumenta los tipos nativos y el otro no, una estrategia diferente, pero eso es todo.

  • Daniel

Estoy bastante contento con Mootools. He tenido la tentación varias veces de probar jQuery porque más y más personas lo están usando en estos días, pero de alguna manera todavía no tengo la buena 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 agregando la tecla hash (#). Esto puede ser problemático si desea crear identificadores html usando el marco. Si yo fuera usted, simplemente actualice a la última versión de Mootools. Mootools no es una mala biblioteca en absoluto.

En su pregunta, mencionó que está utilizando MooTools para "Ajax, arrastrar y soltar, y algunos efectos menores". Si bien Mootools puede hacerlo bien, (y puede que me critiquen por decir esto) en mi opinión, en realidad no estás usando Mootools por la razón correcta. 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 de su organización puedan aprovechar, Mootools gana sin dudas.

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

Evalúa si tienes las horas del programador para hacer el over 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 problemas más importantes que los programadores no tan competentes con JavaScript hacen es que la mayoría de las piezas de código acceden a elementos DOM tienden a crear fugas de memoria (que es el caso de la autopista para la mayoría de los desarrolladores web). jQuery por naturaleza hace mucho para mitigar esto. O más bien jQuery 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 te permitirá revisar fácilmente el código.
    La compañía con la que trabajo (support.com) tenía toneladas de código Mootools. Durante el inicio de 2008 (después de horas de debate acaloradas, por las cuales estaba en contra de mudarme a jQuery), comenzamos a migrar a jQuery de manera gradual. No he lamentado hasta la fecha.

Este argumento es aburrido, Mootools es O-O para que las personas formen un fondo O-O adecuado aprecien su inteligencia más que las personas de PHP4 o HTML.

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. Por lo general, hay un montón de trabajo involucrado en dicho cambio, por lo que querría poder regresar después de que se haya realizado todo ese trabajo y decir "Sí, valió la pena".

Debe elegir esta opción según el propósito de su aplicación.

jQuery es asombrosamente genial para las animaciones, sin embargo, siento 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 al respecto. A partir de hoy, Mootools tiene un rendimiento ligeramente más lento, pero prefiero no prestarle atención hasta que se lance Mootools 1.3.

El rendimiento de Checkout de los últimos marcos en http://slicktest.perrohunter.com

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

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

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

  

Si jQuery hace del DOM su patio de recreo, MooTools tiene como objetivo hacer de JavaScript su patio de recreo

Entonces, junto con la respuesta aquí '' Si no está roto, no lo arregles '', diría que responde 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 que MooTools no ofrece; y si la molestia de convertir es menor que la molestia de escribir la extensión.

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

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

Hay algunas áreas donde no se superponen, lo cual es una pena. Las GUI son fáciles de armar en jQuery, con adorables widgets y animaciones. Me parece que MooTools tiene conjuntos con muy pocas características o son demasiado pesados ??para el uso general de la web.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top