que tienen una bastante grande base de código que depende de MooTools v1.11 y estoy a punto de convertir a la versión 1.2. Como esta es una revisión bastante importante, he jugado con la idea de convertir a jQuery.¿Debo convertir de MooTools a jQuery?
¿Alguien tiene consejos sobre si actualizar a jQuery o simplemente seguir con MooTools?
Uso principalmente MooTools para Ajax, arrastrar y soltar, y algunos efectos menores.
Si está actualizando de todos modos, entonces puede valer la pena investigar.
jQuery parece estar en camino de convertirse en la biblioteca One True Javascript (dado que MS y otros han decidido abrazarlo), así que si este es el código que intentas trabajar durante un tiempo, entonces es probable que Es 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 de su código a largo plazo).) Entonces, dado que tienes que convertirlo de todos modos, ahora podría ser el mejor momento para hacerlo.
creo jQuery convirtiendo en el marco a utilizar es una buena cosa. 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.
¿Quiénes son 'los otros'? – AnthonyWJones
jQuery nunca ha sido Framework de JavaScript y difícilmente se convertirá en él. Es una biblioteca. Y se quedará en la biblioteca. Y es por eso que es agradable y atractivo. –
Anthony: Nokia hasta ahora, pero sospecho que seguirán muchos más ahora que MS ha clavado su bandera en el polo jQuery. – Dan
Si no está roto. No lo arregles
jQuery puede tener X o Y, pero si todo depende de MooTools, es posible que tenga mucho trabajo por delante para convertir desde MooTools.
Guarde MooTools si lo usó extensamente en su sitio. Sin embargo, si solo tiene 2-3 páginas con efectos menores ... el cambio podría valer la pena.
acepto que a menos que tenga algunos planes para las próximas fases del proyecto que requerirían una biblioteca diferente, entonces ahora sería el momento de hacerlo. Después de haber realizado un par de refactores marco, sé que nunca es tan fácil como parece – PurplePilot
La única razón de peso que podría dar para una migración así 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".
Depende de qué tan bien conoce jQuery y cuál es su fecha límite es. Si lo conoces bien, requiere menos líneas de código, lo que significa menos ancho de banda para tus clientes.
También, si mira this site, puede ver que en el navegador IE líder, jQuery tiene mejor rendimiento que Mootools.
Dicho esto, si todo funciona en Mootools v1.11, ¿por qué está actualizando las secuencias de comandos? 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.
asnos si tiene las horas programador para hacer el recorrido de nuevo.
Si lo hace, significa que usted va a volver a escribir el código desde cero. De nuevo, esto implica que tendrá que pasar por el ciclo de funcionamiento, revisión y prueba, corregir los errores etc. Dicho uno de los problemas más importantes programadores no tan competentes con JavaScript hacer es que la mayoría de las piezas de código que acceden los elementos DOM tienden a crear pérdidas 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 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 empresa 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.
¿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 (es IE un jugador importante en su ¿sitio?).
¿Conoces jQuery? Si no lo hace, debe volver a escribir el código desde cero y estará reescribiendo su código por completo.
o sólo tratando de encontrar razones para decirle a su gerente que "debemos hacer esto en jQuery" porque quiere aprenderlo?
Por lo que "el verdadero marco" - que es una afirmación ridícula que sólo los usuarios hacen, no los desarrolladores.
+1 y respecto al punto que MS lo adoptó, es otro punto que me hace tratar de evitar el uso de jQuery lo más lejos que pude. –
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 las versiones de MooTools es realmente tan empinada entonces la migración podría estar bien justificada.
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 la función de MooTools 1.1.1 código en 1.2.x. Puede que tenga que arreglar manualmente algunas cosas aquí y allá, pero es relativamente menor.
El cambio a jQuery o YUI o DOJO, o cualquier otra cosa sería necesario tirar por completo todo el código que tiene y declarando terminado. Ningún cliente mío permitiría ese tipo de desperdicio.
Además, si estás acostumbrado a usar la codificación de las clases adecuadas de MooTools, a continuación, jQuery puede venir como un gran shock para el 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.
Sobre todo con una gran base de código, es importante mantener su código muy bien organizado.
Soy bastante parcial, por supuesto.
Debe tomar esta decisión según el propósito de su aplicación.
jQuery es increíblemente fresco para animaciones, sin embargo me siento Mootools es más sofisticado, así que si lo importante es la aplicación y no se adhieren a las animaciones Mootools
velocidad es también un tema sobre 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.
Pedido desempeño de los últimos marcos en http://slicktest.perrohunter.com
En este punto Slickspeed se está convirtiendo en ninguna importancia, selectores son demasiado rápido 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.
Hay un sitio en torno a ella que describe las diferencias en la filosofía jqueryvsmootools.com
Creo que eso es lo que se reduce a la final. Un enfoque centrado en DOM funcional o un enfoque de JavaScript orientado a objetos.
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.
Este argumento es aburrido, Mootools es O-O para que las personas que forman un fondo O-O apropiado aprecien su inteligencia más que las personas de un fondo PHP4 o HTML.
En su pregunta mencionó que está utilizando MooTools para "Ajax, arrastre y suelte, 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 a juzgar por (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.
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 una manera orientada a objetos y así mantenerlo fácil de mantener.
le recomiendo que lea esto para saber realmente lo que realmente es cada uno (jqueryvsmootools.com)
Y este otro enlace, para que sepa cómo conseguir el mejor de ambos mundos;):
http://ryanflorence.com/object-oriented-jquery-with-mootools-pigs-take-flight/
Al final se reduce a lo que necesita. 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 será y deberías estar listo.
Para actualizar su código de Mootools 1.1 puede usar el asistente de actualización, 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- actualizar capas-beta /)
[lo siento por publicar sólo un 1 enlace activo, esta es mi primera respuesta]
bien puesto de todos modos. –
el artículo mencionado en la página web jqueryvsmootools pone bastante bien:
Si jQuery hace del DOM tu patio de recreo, MooTools pretende hacer de JavaScript tu patio de recreo
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, necesita 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 lástima. 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.
Actualización: no hemos convertido y todavía utilizamos MooTools. – Aldie