Como según mi entender, Mootools no se considera una forma preferida de escribir JavaScript porque imita al OO convencional con respecto al lenguaje de OO basado en prototipos predeterminado.
¿De dónde sacas eso? Lo mejor de javascript es que está tan vagamente tipeado (mira lo que hice allí): puedes escribir lo mismo en un montón de formas. También hay muchas formas de abstraerlo y volver a empaquetarlo, y esto se aplica desde un simple new Array() frente a [] a la forma de estructurar su aplicación.
Si adoras JavaScript (o simplemente lo conoces y lo odias en secreto), estarás bien con MooTools. La API es principalmente js nativa o especificación ES5 o, rara vez, una utilidad adicional que también se siente "natural". La excepción notable que se destaca es Class. Y el hecho de que puede abstraer tener que lidiar con herencia prototípica pasando un objeto a una función especial de constructor Type que devuelve su instancia es ... oh, espera. Se ve diferente, pero lo que hace suena bastante normal javascript. Sólo más fácil: ¿por qué no sería que prefiera?
Mucho se está haciendo en estos días del boom MVC cliente y esta 'nueva forma de desarrollar aplicaciones'. De repente, a la gente de jQuery se les dio el lujo del agua del grifo. He hablado con mucho de los desarrolladores de MooTools sobre esto y (sorprendentemente) descubrí que la mayoría piensa que MooTools rara vez necesita algo así. Tiendo a estar de acuerdo con ellos. El único agujero abierto es un controlador de vista con plantillas, pero hay pocas soluciones justas.
La cosa es, no se puede comparar directamente un marco MVC con MooTools, no es lo mismo. En absoluto. Puede comparar los llamados constructores de modelos vs clases.
Ahora he pasado un tiempo investigando varias soluciones y patrones de framework MVC para ver si nuestra nueva aplicación se puede moldear en una forma de "mejores prácticas".
Básicamente, probé backbone.js (con y sin un adaptador mootools) y me pareció incómodo usarlo después de MooTools, me sentí como un paso atrás. Cuando digo uso No me refiero a que no puedo usarlo pero me parece incómodo ampliar y compilar. Sin embargo, estoy seguro de que es solo cuestión de experiencia, todavía tengo que leer todos los ejemplos de patrones principales que existen.
Problema típico que encuentro - quería tener una propiedad especial del Modelo que le indicara que use localStorage para buscar/guardar. No es obvio cómo: los ejemplos tienden a mostrar que puede enrutar Backbone.sync a uno u otro, pero no a ambos al mismo tiempo. De hecho, tuve que decorar la función y ampliarla, manteniendo el original referenciado en caso de que el modelo no requiriera localStorage. NO es el patrón mejor/más obvio para mantener y me deja dependiente de sus cambios sin romper mi código.
En MooTools, simplemente habría extendido mi clase de modelo y podría haber definido una propiedad de Mutator de clase personalizada (como Binds o Implements). Hecho. Escriba lo que sabe, dicen, y no por nada ...
Otro problema: está estrechamente relacionado con los datos y no puede reutilizar modelos como clases. Por ejemplo, un modelo de usuario carga un usuario y lo renderiza a través de una vista de edición de usuario . A continuación, desea crear un nuevo cliente y, de repente, no puede reutilizar el objeto antiguo fácilmente y simplemente renderizar la misma vista pero con valores vacíos. Creo que también será responsabilidad de la inexperiencia de mi parte o mala arquitectura.
Ember.js Aunque encontré un poco más moo-ish como una interfaz, tampoco hizo clic. Francamente, la red troncal fue menos problemática para la configuración.
Hay otros intentos. Composer es uno - una vez más para mootools pero se esfuerza demasiado para ser una columna vertebral y está escrito por personas que son relativamente nuevas en el framework, así que no lo llamaría maduro. Knockout, etc. Hay uno nuevo todos los días, literalmente.
Garrick Cheung lanzó un marco llamado Neuro que tiene un gran potencial.
Escribí Epitome - una implementación completa de MVP basada en clases y eventos y envuelta en módulos AMD, no dude en consultarla. También viene con un constructor, un creador de documentación y muchos pequeños extras para que comiences.
SeanMonstar lanzó Shipyard, que es utilizado por Mozilla Flight Deck - http://seanmonstar.github.com/Shipyard/. Mientras que no son mootools nativos, es mootools-ish con clase mootools, etc., solo que no se extienden los nativos, por lo que es una gran alternativa.
Por cierto, intente irc.freenode.net #mootools o la lista de correo y siempre obtendrá una buena respuesta.
De todos modos, suficiente en MVC. Los puntos sobre MooTools se han realizado innumerables veces. Los enemigos serán enemigos. Aquellos que lo aman no miran hacia atrás. Si usted es un programador de un fondo OOP o está buscando algo que se adapta bien a los patrones, hágase un favor y quédese con él. Tiempos emocionantes están por venir. Hoja de ruta para 1.5: AMD, para 2.0 (aka, Prime) Creación de prototipos de objeto host opcional. Estos han sido los dos puntos de mayor rechazo a los ojos de los críticos. No más prototipos "sucios" para que la gente pueda seguir usando los bucles de ... incorrectamente en los no objetos y sin las verificaciones hasOwnProperty. De todas formas...
Otras cosas de las que preocuparse pueden ser de importancia. Como, el tamaño de la 'comunidad'. Creo que tener una comunidad saludable es una gran cosa, pero incluso si se mira a jquery, la cantidad de contribuyentes reales vs usuarios es baja. La proporción de CODE de calidad frente a buenos efectos es mala. Los complementos que puede usar: muchos no están bien escritos o están muertos y sin soporte. ¡Cuando trazas la línea, es mucho menos glamorosa de lo que piensas!
No estoy diciendo que las mootools u otros frameworks no tengan estos problemas. Es justo decir que la gente de MooTools y especialmente los desarrolladores centrales son bastante privados y menos expresivos sobre lo que hacen. Puede enviar impresiones equivocadas, no sé. Ciertamente no es jQuery. En última instancia, si tiene los recursos y el know-how, use lo que funciona mejor y lo que se escalará. Incluso hay estos que usan coffeescript y lo juran. ¿Quién soy yo para juzgar ...
En aras de la revelación completa, le resultará MUCHO más difícil encontrar un desarrollador mootools decente cuando recluta. No se puede ignorar ...
er. Mootools no está equivocado por un largo margen. Trabajo con un equipo de desarrolladores de Java que lo eligió exactamente por el patrón oo clásico. Hay una comunidad más pequeña pero próspera a su alrededor con algunas personas muy conocedoras de hecho. Aunque mootools ha tenido herencia, eventos, etc., no es una solución exacta de mvc para el cliente en sí misma. Publicaré más cuando tenga tiempo. –
o no. Tu otra publicación, titulada 'moootools against the world', establece el tono equivocado. Sin embargo, Gl. –
@title changed .. – Nachiket